As any team begins to inculcate a new methodology or way of working within themselves, there is the usual theory surrounding it, along with their observance of a few teams that have already done it. In any organisation there are teams who have already adopted a way of work or people in teams learn from resources online or by speaking and hearing from friends who have done the same within their companies.
The core issue
As you would anticipate if you are mature enough, the core issue surrounding these approaches is the lack of amount of depth of knowledge anyone in the team has to be intuitive about the direction these ways of working will take them through and to some extent possible outcomes. By this I do not mean teams do not know anything about Agile. In fact teams may know more than they need to. They may have seen their peers implement Agile and heard lots of success/failure stories about the same.
However teams migrating to Agile themselves need to understand one thing fundamentally.
Whether or not Agile works for you is dependent entirely on you – the TEAM!
Execution success factors
As with any new methodology, and specifically so with Agile – the way of working provides for teams to make decisions about what works for them or what does not. And this is an easy yardstick by which teams can quickly decide that the methodology does not work for them to crave to go back to something they were fundamentally comfortable with.
In order for any plan to succeed, the whole team has to work in unison to execute a plan made for that success. This means the way of working is adjusted by the team in such a manner that Agile core principles are honoured but teams still have their way to enable these adjustments towards success of iterations.
I cannot stress enough on this point. It is extremely easy to get carried away by theory, or distractions in execution, or pointless arguments floating around the team. As I have noticed with teams executing Agile, the tendency to thrash the methodology is far higher than the tendency to aim to make the methodology deliver successful results. And I can imagine the pain behind why this happens. Its simple – to make anything work teams have to be nimble enough to overcome initial quirks quickly and move swiftly towards becoming more and more mature using the learnings they get exposed to.
But in reality team members have different interpretations of Agile and propose/counter propose suggestions on everything everyone does in a particular way.
Keep things simple during execution
Start with doing things in a simple manner. It maybe any of the following in consideration for that exercise:
- How to visualise information?
- Decision on what information is enough to visualise for the current moment
- Who plays what role within the team?
- What constitutes definition of done for a story?
- Up to what level will stories need to be detailed?
- How much work (stories) defines WIP (work in progress)
- How do we conduct the standup meetings?
- What should we discuss in different ceremonies?
- How should the demo be conducted? How much content should be shown in the demo?
- Which of the agile principles can team actually adhere to in reality?
- How does team raise the bar in a linear fashion each iteration?
- What is the plan to improve iteration over iteration?
- and many more …..
Discussion, Agreement & Conclusions
Perhaps the single best behavioural asset any team can possess is that of agreement on decisions. This apparently has nothing to do with Agile as a methodology. But if there are team members who largely agree (or agree to disagree) after a reasonable amount of discussion, and decide to move forward towards implementing the discussed topics, this generates enough impetus on the focus towards execution.
Disagreements and specifically constant disagreements delay outcomes on iterations, bring about severe conflicts within teams that are not mature enough and fail sprint goals more often than not. The point here is not about “never to disagree” – it is rather to provide a logical conclusion to conflicts in the easiest way possible.
For example there can be a disagreement on whether a word document should be created for documentation or a wiki – team can try both approaches in two different iterations and then decide which one worked for them.
Another example is a case where there may be too many items as part of Definition of Done which is not achievable in reality. So teams can agree to reduce some items of lesser importance to see if generates more productivity. When more and more iterations are executed, teams can decide to bring back incremental updates to such DoD clauses.
The most important thing about all these discussions is to conclude on what teams take and what they drop.
Inspect and Adapt
Yet another crucial element about aiming for success is to be able to be nimble about inspect and adapt process. In short list out the things that did not work for the teams, choose the top three items which teams wants to change for the better and get it rolling in the next iteration. Most people think Agile is a Bible. The very reason the inspect and adapt mechanism is there in Agile is to basically do that very thing –
INSPECT AND ADAPT!
I will talk more about simplicity in future posts, but for now I will leave you with a thought on teamwork. What kind of team would you like to be? A winning team or a squabbling team?