The Eighty Percent Agile Team — Yes, that’s what we need!
I have been a practitioner of Agile and Scrum methodologies for more than a decade now. There are plenty of write-ups available on this topic and I have not found until now reasons to write more along the same lines. However, I have been part of at least three large scale ‘agile transformation’ initiatives and I think it is about time I share my experiences and provoke fresh new thoughts on this whole ‘Agile’ concept from a totally different perspective.
The word Agile has thoroughly confused multiple large-scale organizations in various capacities. This in turn has led them to widely misuse/abuse this concept and create chaos in the overall transformation initiative.
Well, let’s be clear on one thing. Agile has always talked about the good things and they all make a lot of sense. I am in no way condemning any of those principles. It is the interpretation and the implementations during an Agile transformation, which can go in various unwanted directions, and in turn create undesirable results. This is what I’ll be trying to highlight in this article.
You often might have heard the shiny examples of Team creating wonders — winning World Cup, achieving difficult goals, pulling off a great project, etc.!! However, I am yet to find a World Cup winning team which consists of
• 3 great players
• 4 mediocre players
• 4 totally fresh players who have never played the game (have just gone through a bootcamp)
Now, this is the reality of Software Development teams today and these teams are in no way similar to the teams taken as examples in success stories. This unfair comparison creates unrealistic expectations. In my honest opinion, most organizations and transformation initiatives fail to understand this.
If you take a closer look at organizations, almost all of them work with this reality — they have diverse teams consisting of a variety of individuals with different performance levels. Also, you have teams that are getting re-organized quite often as product priorities changes. On top of this, we have existing employees resigning and new recruits joining the company.
If you take all this into consideration, you’ve got yourself a near-impossible task of creating a self-organized team. I question do you really need to aim for this? And at what cost?
Does this mean organizations should totally discard Agile? No, not at all! Agile has a lot of helpful, wonderful, productive principles which need to be incorporated in any good team. I am suggesting go ahead and embrace Agile however create Agile teams that are Eighty Percent Agile.
So, what I mean by Eighty Percent Agile teams?
The moment we are introduced to the flashy ceremonies of Agile — Sprint Planning, Daily Scrum, Sprint Review and Sprint retrospective, we get caught up in these thoughts:
- I must have the most ideal burndown chart.
- I need to measure velocity — should I go with Fibonacci or T-shirt size (none of them work)
- I cannot change my sprint scope once it’s been decided in Sprint planning
- I cannot modify the story points when new challenge arises, etc.
As long as the value is delivered from the Team, I don’t really care whether we had the best Burndown chart or not. Well I care, but only eighty percent. I let the teams NOT follow Agile twenty percent of the time. Team members are free to not be Agile during the twenty percent times and it is perfectly ok. Remember, we trust each other and more importantly the Organization leaders have trusted in the team and team exists to deliver value. They do not exist to follow Agile and ensure someone’s dashboards and reports are looking great.
And the talk about self-organizing team, please, be practical and reasonable. Don’t aim for this unless you are very serious about it.
You have got to have leaders who can lead, without which it just doesn’t work. There may be smart people in the team who can do wonders, but you need to make sure to have someone who can put things together and ensure value is coming out from the Team. And this person is not the Scrum Master!
The ‘T’ pyramid
Yes, TRUST is the most important aspect in Agile based development methodology. And why only Agile? Is it not important when we are following Water fall methodology (or any other development methodology, for that matter)?
Top down. Lead by Example.
Each leader must create the strongest TRUST link with his/her directs. As a leader, if I have 5 people in my team, my most important goal would be to create a strong TRUST link with each team member and then empower them to deliver results. In addition, I ask them to do the same with their directs.
I believe that this is the single most important thing for teams to succeed and deliver great results. If an organization can build this trust pyramid effectively, it could be one of the greatest advantages the organization can have over its competitors.
Yes, trust the people, but…
don’t believe the results without evidence
Not in a negative way but inculcate the culture of teams recording task outcomes!
Creating evidence of your task outcomes forces you to write and when you do it gives yourself clarity. It forces you to think through various scenarios and aspects. The benefit — you do a better job, great outcome — first time right.
Let’s look at some of the scenarios where we need to record outcomes.
➢ Requirements — Write what you want to get done, formats and templates do not matter much. Make less assumptions.
➢ Tasks tracker — It doesn’t matter which tools you use, having a task tracking tool helps to predict if we would meet deadlines or not.
➢ Defect/Story validation — QA Engineers could attach screenshots, recordings in JIRA for future reference.
➢ Story acceptance — Business Analysts could attach screenshots, recordings in JIRA for future reference.
➢ Technical documentation — Developers must document their thought process on technical design and implementation. This’ll make them realize new scenarios, things that would have come up from customers, etc. and broaden their perspective.
In my opinion these are some of the great practices and basic hygiene to be successful — it doesn’t matter what development process you are following.
This needs to become a habit of everyone in the organization. It needs to be Organization habit!
Habit, as defined in dictionary is:
“a settled or regular tendency or practice, especially one that is hard to give up.”
Lead by example is the key. Find bright spots — highlight them, make them spread the practice! People embrace things when they realize the benefits themselves.
This, I also believe, leads to happier people in the organization and happy people create great software. There is enough on internet on this topic already.
I have often heard from individuals — My manager has a lot of trust and confidence in me. This sentence itself makes individuals feel great about themselves and Happy.
Ok, so we now have created the “T” pyramid. What about collaboration?
Well this is one of the other most misused and abused word (after Agile). Have you ever heard organizations harping on strong collaboration within and between teams? All the time, isn’t it? It is, most likely, listed as one of the Culture and Values in most organizations.
The dark side of Collaboration
Collaboration is another concept which has been often misused and abused after Agile. We’ve always witnessed organizations insisting the value of strong collaboration within and between different teams. It is, most likely, listed as one of the cultures, values, or operating principles in most organizations.
There is a very thin line between help and collaboration, and it must be handled by organizations with a lot of sensitivity. Collaboration is great but independent thinking to fuel the innovation is equally important. Isn’t this what most organizations should be aiming for?
It is important to figure out a clear distinction and identify the scenarios when collaboration can be extremely necessary as opposed to the scenarios where collaboration can delay your progress and have adverse effects. This can sometimes be dangerously detrimental to the idea of innovation in the organization. Hence, the context in which Collaboration needs to be talked about is extremely important.
To reiterate, help is definitely not collaboration. They are two different things. It’s not seeking help is wrong, it’s just incorrect to phrase it and categorize it under collaboration. Collaboration in its truest form, would mean two individuals (or teams) of almost equal capabilities, probably in different domains, coming together to deliver shared goals and create great results.
Naresh Jain has delivered a great presentation on this topic in the Agile India Conference 2016. The link can be found at
https://www.youtube.com/watch?v=NEeYfgmCMFM
Bottomline is not to get hung up on Collaboration. It works in certain contexts, but it might not work if you are trying to solve a complex problem that requires independent thinking. Five people cannot think together in a meeting room. It would just be a waste of time.
Role of ‘Eighty Percent Agile’ teams
To conclude, it is not a bad idea to embrace Agile. It’s good to follow all the great things and practices it brings along.
However, it’s necessary to build an environment where teams can focus on what is important — the results. Allowing teams to be not Agile twenty percent of the time can solve several problems that are created due to the adoption of stringent Agile related ceremonies. And most importantly, don’t try to fabricate a burndown chart or any other such charts just because your leadership needs to see it that way. It doesn’t make sense to follow these practices only because there has been high monetary investment by the organization in Agile Transformation.
Acknowledge the Team strengths and weaknesses, strengthen the strengths, work on weaknesses. Do not worry if you are not able to become Self-Organized team. It’s ok.
Don’t judge teams if they didn’t follow Agile in certain situations.
It’s ok to be Eighty Percent Agile.
