Adopting the Agile methodology, a personal retrospective
Having spent more years than I’m prepared to admit working on IT projects, facing up to a challenge of adopting the Agile Scrum methodology filled me with a mixture of excitement and dread!
My whole working life has been spent on software development and support projects. Along the way I’ve worn many hats; developer, business analyst, team lead, project manager and department manager. The projects have ranged from multi-million Pound/Dollar projects spanning many years, adopting various incarnations of waterfall methodologies, through to smaller projects run using the JFDI approach (Just Focus and Do It, is one of many definitions of JFDI, although some of my managers have found blunter substitutes for “Focus”)
18 months ago, I was wearing a couple of hats on a web development project for a client based in the USA. The project was being run using a tried and tested variation of the waterfall methodology. My role encompassed Analysis and Design as well as Development and testing. I’d been out of coding for a few years, and this was my first real web development project of note. Not only was I developing in a new language, I was also doing my best to manage the paradigm shift from procedural programming to true Object Oriented design and development. Thankfully I was working with a seasoned OO professional, who took time to explain concepts, but also gave me enough rope to tie myself in knots and work my way out again. In summary, I was enjoying the challenge, but feeling somewhat vulnerable as I was out of my comfort zone.
In truth, the project was lacking momentum and needed a different approach. Enter, Agile and Scrum. The idea was presented by Stuart, who’d experienced the benefits of Agile development in the past. We discussed what it would mean for us as a team, and us as individuals; daily stand-up meetings, smaller development iterations, commitment to each other about what we would deliver and when.
Outwardly, I embraced the idea and concept, and even muttered that I was excited by it. Internally, the voice of paranoia was telling me that it would expose my coding weaknesses and highlight my unrealistic estimates. In truth, I was curious and keen to try it, “nothing ventured, nothing gained” was how I saw it, and I had to trust that this was being tried for the right reasons.
Before I reflect on how it impacted me and the project delivery, it’s probably worth explaining what we did as well as a simplified overview of the processes adopted.
Agile Scrum Sprint Process Flow
The backlog
To start with, we worked through all outstanding development tasks and estimated the effort required to complete each feature. We broke features down into user stories, to allow us to isolate discrete “potentially shippable” pieces of development. These user stories formed the backlog, the list of deliverables that were outstanding. We then prioritised the backlog based on what we knew to be the client’s priorities and also what made technical sense due to dependencies.
Planning sessions
One of the core elements of the Agile approach is the concept of iterations. We adopted the Scrum Methodology, so our iterations became Sprints. Our early Sprints were based on 20 working days. Before we started the Sprint, we had to agree and commit to what we would deliver at the end of the Sprint. The key difference now being that the developments would have to be potentially shippable, not just unit tested. In the planning session we established our velocity. The velocity was calculated establishing the realistic number of productive hours a day for each person, then multiplying it by the 20 days. We were then able to say than in 20 days, we had the capacity to deliver x hours of development.
Having established our velocity for each Sprint, each one would be different depending on resource, holidays etc., we were then able to select user stories from the backlog that we could commit to during the Sprint. At this stage we expanded the user stories down to task level, and put estimates against each task. This was the first chance we had to measure our story estimates against the sum of the tasks. In effect, we’d planned a 20 day mini project although I’m sure purist Agile practitioners would frown at that description.
Daily Stand-up meetings – the Scrum!
Each morning we would meet at the same time and answer 3 questions each, nothing more, nothing less.
- What did you do yesterday?
- What are you going to do today?
- Are there any obstacles (blockers) that are preventing you from being able to deliver?
In effect, we were making commitments to each other, I will do this today, and tomorrow I will either confirm that I’ve completed what I said I do, or explain why I haven’t been able to. One of the interesting elements of this session was that we were free to choose what we wanted to work on, as long as nobody else had already claimed it. This did lead to some interesting issues which I’ll follow up on in a future blog.
Burn-down Chart from 1st Sprint
The burn-down chart measured where we were against our projected estimates. Key to making the burn-down work, was recording how much time we had spent, and importantly how much time was left. This required both honesty and discipline to make it of any use. If a particular task was estimated at 10 hours, and in a given day I’d spent 6 hours on it, I would have to record the fact that I’d spent 6, and how many hours were outstanding. The temptation of course was to say 4, as that’s what we estimated (10-6), but sometimes it was more, it could actually be another 6 or 8 hours. This was an important lesson learnt. It highlighted where we’d under or overestimated, and it also gave us a better gut feel as to what our true capacity to deliver was.
So how did it impact me?
My fears were unfounded! The process allowed me to feed into the estimating process, with how long I thought it would take me. This meant that the sprint was weighted at an appropriate level. There was no benefit in estimating based on the quickest developer, when there would be more junior people working on the tasks. It’s preferable for a senior to come in under at say 70% of estimated time rather than a less experienced developer constantly coming in over at 130%. Some tasks were by their nature going to fall to certain people, so in those cases, we could be more accurate with our estimating.
My personal productivity and that of the team increased. The use of the Sprint burn-down chart, helped identify early on if we were off target.
When we set out to try the Agile approach, we set ourselves a target of 2 or 3 Sprints to give it a chance to work. After each Sprint, we had a retrospective to reflect and what had worked, what hadn’t and what improvements we could take into the next Sprint. We didn’t need 2 or 3 Sprints to realise that this was the way forward.
We started to deliver output, productivity increased, team communication improved, and we all worked towards the same goal. Agile is definitely here to stay for our team. Over the 18 months, the project has moved through different phases, pre and post go-live. The team has flexed and changed and we have tried refining the process to adjust to those different phases. I will explore these issues in another retrospective blog about our experiences of adopting Spints and Kanban.
Would I go back to waterfall based project methodologies? No!
