Laura Seiler - AgileBusinessAnalysis/01_TEAM GitHub Wiki

What was my role in the project?

Project goal

In essence, the goal of the project was to develop something in the area of business process management, strategic planning, business architecture, business intelligence or software development in an agile manner, analysing, designing, implementing and testing in three sprints. Based on these specifications defined by the lecturers, our team has decided to build a high-level application prototype in the area of relationships and dating during these three sprints. Such an undertaking requires various roles and responsibilities.

My Role

Early in the project, the team has decided not to assign set roles so that every team member can experience different roles during the project and thus take away greater learnings. As a result, the roles have been formally defined but not assigned. To build a prototype in an agile manner, following roles were required: scrum master, product owner, customer representative, designer/developer, and content creator. As anticipated, I could gain experience in all the roles that were defined at the beginning. However, when looking at the three sprints, I do feel that I have spent most of my time in the roles of scrum master. This, as such, does not come as a surprise to me. During my studies I have often stepped into the role of the “project manager”, trying to keep on top as well as on track of the project. Over the years, this role has become rather natural to me. During this project I feel as though I have stepped into a similar role. However, this time, I shared these responsibilities with David, my team colleague. As he is very experienced in applying agile methods as well as conducting business analysis, and I have gained some experience in working with Scrum and Kanban, I felt that we were able to manage the project team well. In the role of the scrum master, I have made sure that we would meet our sprint deadline in order to present our results at the sprint review sessions with our supervisors. Furthermore, I ensured that we stuck to our pre-defined processes and “rules”, as described in the sections “methodology” and “team space”. Furthermore, I have conducted some sprint retros, recorded notes during sprint reviews and made sure the documentation was up to date. When comparing this project to others, I must say that the task of managing the team was much less “burdensome”, meaning that tasks were most often clearly defined, timed and assigned. By doing some, there was a sense of clarity and responsibility each team member felt. Thus, I did not have to check in as much or put pressure on team members to complete their tasks. I really enjoyed stepping into this role and I have taken away valuable insights, such as clearly assigning and timing tasks, that I will implement at my current position.

Possible improvements

If I had to define the roles for the project again, I would add the role of the business owner as I feel as though this important aspect got lost during our sprints. Although we have set the goal of building an application prototype, which is rather focused on technical aspects, it is extremely important to never lose sight of the business and its objectives.

What was my contribution?

Overall achievement

The result of the project was a minimum viable product, or MVP, of our application that should support couples in leading a happy and healthy long-term relationship. We have achieved this MVP by deeply analysing customer needs, prototyping the UI as well as the recommendation logic, and validating all these components.

My contribution

Before starting the sprints, we had to decide which methodology to follow. As David and I both have some experience in agile environments, we decided to follow a Scrum methodology, however heavily focusing on the lean principles of the Google Design Sprint framework. We both felt that we could, through our own experience, add most value in this set-up by sharing our knowledge with the team and supporting them in their agile way of working. In sprint 1, I feel as though I could contribute most through assuming customer needs. As I myself am in a long-term relationship, I was able to come up with certain challenges that couples face in such situations. This was helpful for us in that we could “map the challenge”. This was the basis on which we sketched different solutions and how we arrived at our idea for a prototype.
In sprint 2, I could mainly add value through my experience in start-up investing. In sprint 1 we received the feedback to focus a bit more on our stakeholders. By defining the most important ones, we have realised the integral role of a possible project sponsor. Thus, I have spent some time on the elaboration of the section on “project sponsoring”. In most start-ups’ journeys there comes a time where external financing, or venture capital, is required. Through my experience in capital venturing, I was able to shed some light on this topic and develop a possible approach for seeking external financing. Furthermore, in sprint 2, I conducted the sprint review, explaining to our supervisor what we have achieved in this sprint, as well as the sprint retro. To make the retro somewhat fun and interactive, I have gathered ideas from following website Agile Strides. The retro was split into “set the stage”, “gather the data” and “decide what to do”. In sprint 3, I was heavily involved in the set-up of the new recommendation logic. After developing the recommendation logic in a team workshop, I set up a questionnaire framework on the Interact platform. This was the basis for testing the recommendation logic with test users and gather valuable results. Furthermore, I stepped into the role of the scrum master again, following up on documentation and taking notes during our sprint review and retro.

Possible improvements

If I were to repeat this project again, I would try to engage more on the technical aspects. As mentioned in the section before, I feel as though I often step into the role of the “supervisor” or in this case “scrum master”, focusing more on aspects of organisation or the “business side” rather than engaging on the aspects of the “technical side”. In doing so, I would be able to accumulate more new knowledge rather than intensifying already gained knowledge. However, I feel my contribution was valuable to the team as it supported us in keeping on track through meeting our overall goals, finish all of the tasks in Trello, and meeting our deadlines.

What were my learnings?

When examining our project and looking at it from the perspective of the BABOK guide’s knowledge areas, we have mainly conducted tasks in the areas of planning and monitoring, elicitation and collaboration, requirements lifecycle management, requirements analysis and design definition and solution evaluation. The tasks in planning and monitoring were not actually conducted during the sprints but as a preparation. This involved defining our BA approach (or methodology), stakeholders and subsequent communication, and setting up our IT like GitHub and Trello. In terms of elicitation and collaboration, our main activity was conversing with potential users of the application. We let test users test the features we have developed as well as asked them for feedback and improvements. For this, special feedback forms were prepared and the results were added to our Wiki. In addition, our supervisors represented additional stakeholders that provided us with valuable inputs. Our backlog, regarding requirements lifecycle management, was managed in Trello and tasks were prioritised at the start of each sprint in the team. The requirements, displayed as tasks, were also maintained and traced in Trello. They were also documented in our Wiki. The before-mentioned feedback forms, as well as our own research, represented the basis for the requirements analysis and design. Requirements were specified based on the received feedback from the previous sprint, they were then modelled by the project team, and verified by the test users. In terms of the solution evaluation, as mentioned before, the intermediate solutions were mainly assessed by our test users. Summaries of the results of these evaluations were then presented to our supervisors during sprint reviews. During this agile business analysis project, I have learned one key thing: the importance of total customer-centricity. Almost everything that we have done during this project has been matched to the needs of the customer. By gathering feedback at the end of every sprint, we could create a valuable basis for the next sprint. Based on this feedback we would then try to adapt the prototype accordingly, gaining new knowledge along the way. Furthermore, I think that the agile mindset has made us faster and has helped us in focusing on the important things. There were no dependencies regarding decision-making or objections from stakeholders that slowed us down. It was extremely helpful to define the decision-making as well as the communication approach beforehand. This has also taught me the value of documentation. Documenting not only issues like decision-making or communication approaches but results in one shared space makes working in a team much for efficient and simple. Especially the use of Trello has, in my opinion, made the collaboration within the team much more outcome-driven, as tasks are clearly defined, assigned and timed. Team members learn to become personally responsible for their work and I find that, in our team, we were not afraid to ask each other for support or inputs. I think that has greatly contributed to the success of our project. All in all, it was amazing to see how each and every team member has adapted an agile mindset in a short amount of time and consistently delivered valuable input to the project. Going forward, I will definitely implement my own agile way of working.