In the past year I have run two large successful agile projects that have delivered software using the Scrum methodology to build a minimum viable product (MVP) and then transitioned to Kanban once they have gone live. The first one was the Metro.co.uk responsive redesign and CMS migration which was delivered on time and under budget. Since going live it has been quickly iterated to deliver solid mobile and overall traffic growth for Metro. The second project is the Metro Play Casino which delivered its MVP as part of a large program of work that required us to get a fully regulated offshore gambling business started. This is now ahead of budgeted expectations and we are currently scoping the next phase of development. During both of these projects there have been some ups and downs but overall it has been a really positive experience. I thought I would share some tips that I have collated whilst managing these projects successfully using agile methodologies.
- Initially just define a few clear high level goals to measure success that allow detail to be filled in at the appropriate time.
- Start prototyping as early as possible, learning by doing is the most effective way to figure out what to do and also what not to do. Being able to actually use something as early as possible is very important. Even if this means releasing something different than your end goal.
- Don’t break down every story in the beginning and add it up to find out how long the project is going to take, this will just leave you with an unmanageable backlog and most of the stories will be out of date by the time you come to develop them. We have found that the best approach is to get a group of experts in the room and play planning poker for the project as Dan North suggests calling it Blink Estimation.
- Don’t be afraid to pivot your MVP or technology choices if the learning that you gather points in slightly different direction than you first thought. Knowing what you don’t want is as important as knowing what you want.
- Clear and consistent goals facilitate quicker decision making. These enable decisions to be made based on logic and this decisioning can be distributed around the team and post validated. Any single point of decision making is going to really slow things down, especially important in the last couple of iterations.
- If you are still developing a lot of new functionality in the last sprint be worried. Also leave a little bit at the end to tie it all together as things always pop up that you didn’t plan for.
- A more traditional Project Management layer can really help with external vendors and internal communication. Keep project plans at the highest possible level for visibility and better decision making especially on dependencies.
- Change your process, change it again. Retrospectives are really key to this process so don’t forget to have them after every sprint. Be agile about your process.
- Quite often order comes from short periods of carefully orchestrated chaos, these can help teams form by giving people common frustrations. Listening to these and then adapting your process to remove them helps the team to feel empowered.
- Get onto your production environment as soon as possible, no matter how similar other environments are they are never the same and issues will come out at this stage.
- Get developers and the business talking directly if at all possible. Learning together through structured conversation delivers the best business value. These can be facilitated by a Business Analyst or Product Owner but they should not always be in the middle as the lack of knowledge transfer will harm the project. This is especially true when dealing with multiple stakeholders.
- Bite off the biggest unknowns first and work on them to make them knowns. The best way to do this is to release something early and get real people to use your product. This doesn’t need to be MVP but a Minimum Learning Product that delivers some value to end users.
- You can assemble a group of people but it takes time and effort to form a team. Setting achievable goals and then ensuring they are delivered with a sprinkling of pressure early is a great way to prepare for the final few sprints.
- Restrictions bring out peoples creativity.
- In my opinion design should be emergent as should architecture, initially go with the most established patterns however you need to give the team time to fix things if they turn out to no longer be the right choice. This allows you to focus on actual problems rather than solving ones you only think you have.
- Automated testing should focus on smoke tests and high level indicators when things are rapidly changing.
- Automate builds and deployments in phase 0 for maximum payback.
- Constantly engage the business to make them define the problems they are trying to solve and then work together on the right solution for the project and the business in iterative steps.
- If you are going to take any risks with the project take those decisions at the latest possible point.
- Celebrate the team and their successes.
- Things will change constantly so learn to embrace it and hopefully get to the place where you enjoy it. If you have problems detailed rather than solutions then these can then be adapted as you learn.
- Simple things you haven’t done before are complicated to execute. Do not under estimate… or fall into the planning fallacy. Build complexity in over time.
Conclusion
Managing successful agile projects is something that can deliver serious business benefit if done with the right approach. The constant feedback that is available allows iterative learning and if your environment is setup to handle this will allow you to be very nimble. Quite often agile is an approach amongst a sea of different project management methodologies and I believe that if adapted properly to your environment can bring real benefits to most projects.
Music to write this Code to
Just Be (Bushwhaka!) delivers some serious house sounds in San Francisco making me wish it was sunny every time I listen.