“We don’t do documentation, because that’s not Agile”
“Plan? We don’t have a plan, we’re doing Agile”
“Requirements? Design specifications? No time for that, we’re doing Agile!”
Have you ever heard statements like the ones above? Let me say up front, you should hear alarm bells ringing when you get told things like that. There are still too many projects and individuals who take “Agile” as a licence to throw out all discipline and good practice, and basically do what feels good (at least until Karma bites).
Have such project teams ever read the Agile Manifesto? Key to the manifesto is that the authors did not throw out all of the traditional disciplines, but they did shift the focus heavily in favour of less bureaucracy and more productivity and better communication. To this end, one of the Agile principles is Simplicity: “Simplicity–the art of maximizing the amount of work not done–is essential”.
What does the Agile Manifesto say? Here it is:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
To me, that last paragraph is critical to gaining the benefits and spirit of Agile, without dooming ourselves to a level of immaturity in software process that does more harm than good.
Take planning: creating plans, following plans, tracking against plans. Does the Agile Manifesto endorse such practices – absolutely. Does the Agile Manifesto advocate changing a plan in the face of changing circumstances and/or requirements – absolutely. Agile values responding to change (let’s refer to this as “reality”) over sticking to a rigid plan (let’s call this “our temporary model of reality” – aka “fantasy”). Without a plan though, you cannot even plot an original course or know when you are modifying it.
If anyone tries to tell you that Agile projects do not do planning, have plans, or follow plans, just point them to the Agile Manifesto. Such projects may not be “doing Waterfall”, but they are definitely NOT doing Agile.
The danger of such practices and projects, is that by claiming to be doing Agile, while practising undisciplined chaotic software delivery, they tarnish the name and reputation of Agile methodologies, and decrease business appetite to engage with Agile methodologies as serious approaches to delivering quality software, which is a great loss for business, and for the technology teams involved.
How can an Agile Business Analyst assist a team to realise the benefits of Agile without falling into the “Cowboy” mentality trap?
- Think big picture
- I love the house building analogy. Step 1 – “I want a house”. There you go, that is the beginning of your plan, your vision, your architecture, design and requirements. With that one statement, you can tell a lot about how long things will take, rough order of magnitude costs, skill-sets and team size. Sure there are plenty of unknown variables, but because of that one statement, you have a starting point.
- Likewise with a software project. “I want a web-based content management system”, or “I want a SaaS CRM”. With those brief statements, as industry experienced professionals, we already know 60%-80% of everything we need to know about the project.
- Refine it
- Step 2 – Lets get more specific. Location? Single or multi-story? Square metres (or feet) under roof? Standard of fixtures and fittings? Number of bedrooms and bathrooms? Preferred construction (steel or timber frame? Brick or timber exterior? Roofing materials). All of these “next level” requirements allow us to refine estimates of time and cost and plan our team.
- In the software world, this will involve next level drill down on requirements, architecture, design and understanding constraints. I’m not talking months of work. I’m talking about what can be discovered in a week or two, to frame the solution, allow us to conceptualise an initial architecture, and get our initial backlog of prioritised user stories set up.
- Break it down
- Step 3 – Break it down. How are you going to attack this project? Generally you prepare and implement the foundations first. Starting with the roof is generally not a great idea. Again, like a method in baking a cake, this level of planning is critical to ensure the team can implement the solution in a logical, efficient and effective manner. And again, this level of planning can be achieved in hours or days, and provides rails on which the implementation can run smoothly.
- A key role for the Agile Analyst is to understand the customer objectives deeply, so that the solution and the project which implements it, can be the simplest one possible, and therefore the most cost-efficient and effective.
- The Agile Analyst should challenge complexity in design, implementation and execution at every step of the way, both in the interests of the client, and also so the team can always be delivering the highest possible business value, and reaping the rewards and satisfaction for doing so.
There are books that could be written on the above topic, however I think 2 key principles will keep you on the right track:
- Keep clear on the Agile Manifesto – if your approach is not lining up with that, you’re not “doing Agile”
- Avoid extremism – don’t throw the baby out with the bathwater as they say. Embrace Agility, but keep a “right-weight” level of planning and documentation to keep your project on track.