How to make Agile work for you?

How to make ‘Agile’ work for you?

You have decided to jump into the ‘Agile’ bandwagon, convincing your team that the traditional waterfall model is outdated. You lug your team into a week of ‘agile’ training and the team, refreshed by a new set of terminologies to boast, is all geared up with their sleeves rolled. Congratulations! You’ve taken the first step.

However, as you may have already realized, ‘Agile’ is no fool-proof model, if not conceptualized and executed right. Many teams struggle to make agile sustainable for them from initiation to closure. Here are a few tips that should help you to stay on top of your game and not fall into the usual ‘agile’ pitfalls.

1. Agile is not an excuse to stop planning: Most new adaptors are under the myth that agile implies planning can be deferred or it can be done in an ad hoc fashion. As a matter of fact, it is just the opposite. Establishing a solid plan at the beginning is a complete must for the rest of the pieces to fit into the puzzle.

   For e.g., you need to have the right org structure with roles and responsibilities – product owner, product manager, scrum master, etc. – clearly defined. You also need to be able to breakdown the project into ‘epics’ and smaller tasks that can be accommodated into sprints. All this happens only when you start off at the right foot.

2. Accept change, but only sensibly: Typical waterfall models tend to fail because they often treat the requirements document like a holy scripture, which is never bound to change. Agile provides the contra approach, providing the flexibility and framework to cope with changing requirements. But, the pitfall could often be unwanted changes that tend to crawl in. Agile does not mean, any new change can be added at any time! It simply means there is a structure available to deal with the changes. So be wary of change requests that could become pull-backs.

3. ‘Lean’ is the mantra: Lean teams working on lean stories, is the sure way to go in agile.

   With respect to team size, agile can only work well for small teams of about 6-8 in size. The project is approached as smaller product deliveries with each lean team working on a product, which can be independently taken to production. The key here is to streamline in a manner that the dependencies on other products are made redundant with clean interface points supported by test driven development.

   The idea behind lean stories is straightforward. The bulkier a story, it tends to remain unfinished and gets moved to the next sprint or it has less clarity for the developer to execute or even worse, difficult to write a test case for.

4. Invest in the right set of ‘tools’: The agile manifesto spells out, “Individuals and interactions over processes and tools”. While, teamwork and people interaction certainly scores in agile, do not get it confused for not investing in the right tools to make agile work.

   While you may think it’s cool to have sticky notes on whiteboards or excel sheets to track your stories, some great tools are available in the market to support continuous integration (e.g. Jenkins, Cruise Control/Go), collaboration (e.g. JIRA, Version One) and test-driven development (e.g. Mockito, jMock).

5. Is your customer ready to go ‘agile’? Agile is heavily reliant on a ‘Product Owner’ who is 100% staffed for your project. It relies heavily on customer collaboration through all cycles of the project, working hand-in-hand with the technical team. If you end up with a client, who is only partially staffed or who does not have the know-how to provide substantial, candid feedback or who is not decisive enough to assess the pros and cons, you are definitely in for a failure.
6. Make time for ‘Refactoring’: A common pitfall is that while all product teams are busy delivering on their stories, a bunch of refactoring based tasks fall out. This leads to technical debt build-up over the long run, making it messy and sometimes impossible to clean up at the end. Here is when the scrum master plays a crucial role, by consistently adding the refactoring work to the backlog and prioritizing it.
7. Take a break from verbose documentation: When you are in doubt, remember that your documentation needs to be Just Barely Good Enough (JBGE). Agile programmers believe that getting caught up with semantics and working on excessively clear documentation is just an overhead, because things are bound to change anyway at some point. It does not mean creating ‘incorrect or ‘ambiguous’ material. The idea is to communicate the bare essentials in a document and instead focus on writing crystal-clear code that almost reads like a document and hence is easy to maintain.
8. No people management for the scrum master: The scrum master is playing one of the significant roles, keeping the team focused ahead, asking the right questions and ensuring there is the right amount of work delivered across each sprint. While a project manager can afford to have additional people management responsibilities, the scrum master’s single focus has to be delivery.

Ultimately, just remember that agile is not a magic wand. It is a methodology and a bunch of techniques, but more importantly, a culture and a thought process. If you manage to pick a few fancy terms and a couple of quick fix processes and leave out the overall concept, it’s not going to work for you. You have got to adapt it as a whole.