Here is a common case – the management realizes the entire software industry is moving to Agile, and now even the clients have started demanding Agile teams for their projects. Finally, they sign up for an Agile transition. So far so good. The problem starts when – despite their good intentions – the management itself becomes a roadblock in the team’s Agile journey. Below are five common ways in which the traditional management thinking and behaviour can compromise a team’s agility.
1. Believing Agile is ‘One size fits all’
With their deep-rooted belief in traditional management that ‘if something cannot be planned it cannot be executed’, and consequently, a bigger change necessitates bigger planning. Needless to say the management favours a big-bang change approach over an evolutionary change approach.
The first step in their planning is to find a ‘fool proof recipe’ for Agile success. They consult some Agile experts who give them exactly what they want… a ‘fool proof recipe’! The only catch is that this recipe looks fool proof only on paper; the reality is yet to unfold. Such Agile recipe is usually full of assumptions like:
- Agile = Scrum
- 2 week sprints for the entire organization. The thinking is… if the rest of the world is using 2-week sprints successfully, why can’t we?
- 1 story point = 1 ideal day
- The ratio of developers to testers should be ‘X’
- All project managers should take up the role of Scrum Master/Product Owner
- And so on…
While some of the above assumptions could be valid in some cases, the dysfunction here is that a ‘planning-based’ approach is being favoured over an ‘evidence based’ one. The Agile recipe is often standardized so strictly that it does not matter how big the team is, what are the current challenges for the team, is the team distributed or co-located, how does the Demand flow, and what kinds of resistance is expected from team leaders or the team.
Please allow me to share an example. Few months back, I came across a training participant who looked utterly dissatisfied with Agile and Scrum. When I explored he shared that their management had mandated all to follow Scrum with two week sprints. The problem was that he was working on a BI project where each report would go through a long workflow of analysis, data modelling, data population, report design, report creation and validation, taking a total of 5-6 weeks. The management’s mantra of ‘2-week sprints for all’ forced them to split a single unit of work (report) into multiple small chunks even though value could be delivered only once all parts had been completed.
2. Believing Agile is a Localized Change
The management behaviour in this case can be summarized in one single statement: "In our Agile transition, everyone is expected to change their ways… EXCEPT US!"
While the management expects the teams to completely switch to new roles and new ways of doing things, they show extreme resistance in changing their old ways. Below are some examples of management behaviour:
- Continuing with the old ‘fixed bid’ contract model. Not even attempting to change it.
- Continuing with the old performance review process that tunes individual behaviour for competition rather than collaboration.
- Asking the team for old reports irrespective of their relevance. Sometimes, even asking the team to prepare and share MoM (minutes of meeting) for all ceremonies.
- Not accepting the idea of disconnecting story points from time estimates.
- Trying to control the variance between estimates and actuals.
In agile, the leader's role is to coordinate, not command.
3. Believing Agile Transition means Instant Results
The thinking here is “A perfect plan delivers perfect results, instantaneously”. Combine this with the belief that “we have a perfect recipe for success” and you will have 100% chance of a panic situation within 3-6 months of the start of your Agile journey where management will take some critical decisions that may compromise the quality of your team’s agility forever, or at least until the next transition effort.
As an Agile Coach, it is important to set realistic expectations with the management. Introduce them to the J-curve effect for organizational change. They need to understand that the bigger the change, the longer they must be prepared to wait before they can see positive results. While a Scrum transition may take 3-6 months, a SAFe transition can take one full year before one begins to see a return on their investment.
4. Monomaniacal Focus on Productivity
While ‘higher productivity’ is always a worthy goal, adopting it as a single-dimensional evaluation criteria for success is shortsightedness. The management who focuses too much on productivity asks questions like these:
- Why is your team’s velocity less than the other team?
- Why is your team’s velocity not going up by x% every sprint?
- How many story points is each person completing every sprint?
- How many bugs are being raised by each tester?
Such management needs to be asked an important question: "What is more efficient - rushing haphazardly to finish one’s work or working more carefully, correcting mistakes as you go?"
Unfortunately, Agile is being sold by many consultants to customers with that single promise – your productivity will go up by x% if you switch to Agile. One senior leader from a product company shared with me that Agile was sold to them with exactly same promise - higher productivity. While it did not deliver on that promise in the short run, he was happy that Agile helped them reduce the turnaround time and improved the quality significantly.
As a Coach, you could urge the management to shift their focus from one-dimensional performance evaluation criteria (productivity) to a multi-dimensional ‘Capability’ that includes quantitative measures like productivity and turnaround time (cycle time and lead time) as well as qualitative measures like product quality and team’s self-management ability.
5. Failure to Trust and Empower the Team
Often, it is the deep rooted belief in ‘Theory X’ of management (or call it Command and Control culture) that prevents the management from trusting and empowering their teams. They may be used to thinking of their employees as resources or headcount, not necessarily as living human beings who not only want to breathe, smile, laugh and play, but also like to think, analyse problems, discover solutions, innovate new products, and take pride in their work.
While they like the idea of achieving benefits of Agile, they may have completely missed the idea of "self-management" or "building capability in the team". They do not realize that team empowerment is a prerequisite for collaboration. As a result, they continue to:
- Favour control over motivation
- Closely monitor each individual's time spent on the project
- Interfere with team’s local decision making
- Micromanage the task status of team members
As a Coach, you may want to communicate the importance and benefits of team collaboration and self-managing culture. And, share with them the key principles of collaboration – alignment, empowerment, engagement, transparency and accountability. It is important to understand that in agile the leader's role is to coordinate, rather than command.
Thank you for taking time to read this post! Look forward to hear your views and examples of how you have seen management compromise their team’s agility.
[This article was first posted on LinkedIn. Please find the original post here.]
