The Agile Manifesto is often criticized being too much a vague set of principles, not a strict methodology, nor a how-to guide to use in your day to day practices.
At a Leadership retreat hosted by Co-Learning this month, I discovered how to use the manifesto as an analysis tool.
The topic for the retreat was “Team Gelling”. Through a variation on the Fearless Journey game, Jurgen and Johan helped the participants find problem-solution fits for specific team gelling issues.
At the end of the retreat, it became clear that by combining root-cause analysis techniques such as 5 Whys with the Agile Manifesto as a Forcefield Analysis tool, you can increase the ease of finding problem-solution fits.
Where are the problems?
When you look at the manifesto, the right column tends to cover the area where most issues arise:
Problem example: team members are always late on meetings.
Where are the solutions?
If you want to use the manifesto as a tool to solve problems, try looking for solutions in the left column.
Solution example: don’t have scheduled recurring meetings, but encourage people to talk to each other on an informal basis. Try to place them next to each other for example.
By focussing your team’s activities on the left column, you minimize problems and maximize efficiency.
In practice
I admit, this still is pretty vague. That’s why after the retreat I immediately put this into practice in a middle sized project we had just kicked off. Not explicitly, but more as a sheep in wolf skin.
For the experiment, I focussed the team on Individuals and interactions over processes and tools and Customer collaboration over contract negotiation.
How?
- Normally we are pretty over the top that EVERYTHING has to be in the bug tracker. Not now. Important bugs were detected and resolved face to face and instantly.
- We tried to eliminate as much email clutter around scope discussions as possible. As development, Product Owner and PM are only 30 feet away from each other, I facilitated the team so they would do as much face to face conversations as possible.
- Only the bare minimum was documented in the project management tool. Only things that explicitly needed archiving were documented.
The results?
The results were great and instant:
- Input for development was delivered early on every (!) occasion.
- The site was ready 6 days earlier than necessary, which is a lot in a project lifespan of 2 weeks.
- There were no bugs, issues or feature requests after go live.
- Everybody happy!
Do you have similar results or other examples? Don’t hesitate to comment!
P.S. You can read a report about the retreat on the Co-Learning blog.
