Agile Principles in Practice

After many years as a project and program manager, I got the chance to do two projects during the last year, using Agile. One project was the implementation of a new process into an ERP system. The other project dealt with the hypercare phase of an ERP implementation. In this blogpost I want to share a few of my findings in relation to Agile SCRUM and discuss with you what worked well and what was working less during the projects.

Context
First let me give you an idea of the context: the organization I worked for uses Agile SCRUM and I had the role of product owner. This means I was representing the end-customer and had to make sure the team delivered value to the business. My job was to deliver user stories, add them to the product backlog and prioritize them according to criteria I had to negotiate with the business stakeholders.

The cross-functional SCRUM team consisted of four core functional analysts and two developers. During a few sprints the capacity was expanded with more functional analysts and developers, when required and when available. The team consisted of Irish, Italian, Russian, Indian, Belgian and Dutch natives that were spread over physical locations in Belgium, Italy and Ireland.

We worked with sprints of two weeks and in a few occasions the duration was extended to 3 weeks, when the team thought this was necessary given the specific user stories that were added to the sprint. Every two weeks, a backlog refinement meeting was planned, where user stories were reviewed for their readiness for the next sprint. In the beginning, backlog refinement meetings were held without the business stakeholders, but later on the business stakeholders were invited as well, what proved to be more efficient and ensured more commitment from both IT and the business. After a while backlog refinement meeting were also held every week, which seemed to work better than every two weeks. Every sprint was planned during a sprint planning session, where the SCRUM team members attributed story points to the prioritized user stories up to the point that the available capacity was filled. After every sprint, the following ceremonies were organized: a sprint review with the business stakeholders, where the final products were presented with or without a demo and a sprint retrospective, which was a lessons learned from the last sprint. Finally, we had a daily SCRUM meeting that was timeboxed to half an hour.

Overall, I found Agile SCRUM quite well suited for these specific projects. In the case of the implementation project, every user story represented and equaled more or less to a single process step in the new process. For the hypercare project, every system issue or change was translated into a single user story. In the beginning, the team struggled a little with the more complex user stories. Later on, this was solved by either using a “spike” to do the (preliminary) analysis in one sprint and do the actual development and testing in the next sprint. Another solution was to cut the original user story in two separate user stories and develop these user stories in two consecutive sprints.

Discussion
Looking at the Agile principles, there are a few I would like to discuss briefly. First of all “Welcome changing requirements, even late in development”. As with all projects, requirements tend to change over time. Advancing insight, even in a relatively short period of time of two weeks, cannot be avoided. An Agile way of working responds quite well and I never received any (open) complaints from the team about changing requirements. Nevertheless, this has its limits: at times we had a user story well analyzed and developed and close to the end of the sprint, new or changed requirements suddenly appeared. Even in an Agile way of working, this resulted in considerable rework having to throw away part of the work already being done and start over, missing the end of the sprint.

The same applies for changing priorities: smaller changes to priorities were not a problem at all, but when the criteria for prioritizing the backlog of user stories changed considerably a few times, this disrupted the flow of preparing the top user stories during backlog refinement and consequently planning them for the next sprint. User stories way down the backlog were suddenly at the top, which resulted in a lot of preliminary analysis work before the user stories could actually be developed. Embracing changing requirement and priorities is fine, but moving targets are hard to aim for at a certain point. This is why priorities for user stories were temporarily frozen at a certain moment, allowing the SCRUM team to work without interruption, building on the analysis work that was performed during the previous sprint and not having to start all over again every sprint.

Another Agile principle is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. I can certainly agree to that principle, although one never gets to choose the perfect team. I am not saying I had a bad team: every team member was a specialist in his or her domain, but the international aspect was a given. This means we had to do most of the meetings via conference calls and mail. This worked quite well, but it worked even better when these meetings were held with video conferencing, where you could actually see each other. The best sprint from the project happened when the Ireland- and Italy-based team members travelled to Belgium to meet each other and the business stakeholders face-to-face and do a backlog refinement meeting in the same room.

The last Agile principle I want to discuss is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. For this principle, the sprint retrospective meetings are a key aspect. At the end of every sprint, valuable feedback was gathered from the team on how to perform better in the next sprint. This feedback was translated into specific action points that were actually implemented in the next sprint. For example: having good user stories and acceptance criteria for every development is crucial for avoiding discussions over the final product. Trying to speed up the process not properly documenting this, has led to discussions and rework in a number of occasions. Another example is to preserve the necessary amount of time during a sprint to analyze items in the backlog that are not part of the current sprint. By doing so, more user stories are ready to be taken into the next sprint.

Conclusion
My conclusion is that Agile was well-suited for delivering the two specific projects I guided in my role as a product owner. This doesn’t mean that it is the silver bullet for every project and certainly, the Agile framework has to be tailored to the specific project environment: a lot of times the rules of the game were changed when the team thought something didn’t work or could work better. Agile was flexible enough to cope with this. Finally, I found out that many of the dos and don’ts you learn during non-Agile projects can be equally applied to Agile projects.
 

Sign up and we'll keep you posted