When agile gets dangerous

If you’re selling your teams on some form of agile but the reality they work in is completely different, you are damaging and demotivating your teams through confusion and an impossible to achieve vision. If you’ve adopted ‘agile’ do yourself a favour and check the health of the adoption right now.

Every organisation has a custom agile adoption. That’s the point, being reactive to what works for you, having less process and more awesome product in your customer’s hands. However this flexibility can cause problems.

The damage occurs when you sell yourself as a particular agile-way-of-working to your delivery teams and you bring in the agile consultants and experts to inspire. But then senior leaders never attend these sessions. Your agile practitioners and advocates go back to their teams bursting with new ideas and they are faced with rejection from middle managers, deadlines on everything and solutions to implement.

This cycle of raising hopes and talking about implementing change but not doing anything meaningful is catastrophic to morale.

Modern agile

What the hell is agile these days anyways? The four principles of modern agile are

Make People Awesome – This includes the people who use, make, buy, sell or fund our products or services Make Safety a Prerequisite – protect those people’s time, information, reputation, money, health and relationships Experiment and Learn Rapidly – We learn rapidly by experimenting frequently Deliver Value Continuously – “How could valuable work be delivered faster?” (while maintaining the above values) Have your teams matured beyond your current implementation but they’ve been prevented from adapting due to process and lack of confidence or freedom?

Or has the adoption of agile principles hit a wall at some level of management and top-down decision making is crippling your team’s velocity?

Are the agile practices you preach really how your organisation operates?

Shitty products are a choice

You say – We are customer focused

The reality is your focus is on pumping out barely finished MVPs where being on-time is critical. These products or features tick the box in some OKR as “completed” but they are not awesome, they don’t make the customers using them feel awesome and they definitely don’t make the team building them feel proud of the work.

The work is focused on short term time-boxed projects which prevent the team from ever deeply understanding the problem or the customer they are working for.

There is no time provided to work on improvements that can’t be related to short-term, immediate business needs. Bug fixing work is someone else’s problem. The team’s deadlines are so tight that they are encouraged to take shortcuts and deploy sloppy code. The inevitable bugs build up and slow down overall delivery across the product.

All features and UX design are decided and approved upfront and handed over to an implementation team. Projects are shipped only when fully completed. No learning takes place because the scope is set and the deadline is set for that scope. No learning takes place because the implementation team don’t see or ship to a single customer in the months they are building the product.

The team never gets the opportunity to iterate on their learnings after deploy because the time-box has ended and they are told to move on to the next product or feature. Success is measured as the completion of the feature, not the value it provided. Are you rushing it out to satisfy your board, your bonus or your customer?

Rushing out product with no iterations results in shitty products. Shitty products make the people who made them feel uninspired, especially when they get feedback and can’t act on it because they have rushed on to the next feature. Try to be honest about why you need to get stuff out and can’t make it better based on feedback, it probably isn’t to satisfy your customers.

Managers burn out too

You say – We have cross-functional, autonomous teams

You have autonomous teams but there’s massive stress present for the managers who don’t trust their ‘agile’ teams to have autonomy. These managers psychologically own the outcome of the work rather than the implementation team.

The manager can’t spend their time on the bigger picture supporting the teams and creating an environment where the teams can flourish. They focus instead on project management, making sure every story is moving along to the agreed deadline. There is enormous pressure on the manager to take over the team, decide on priorities and this tension spreads to the team.

Now that these managers are incredibly busy project managing they have no time to spend informing the implementation team about the vision, the customer need and the success criteria. They get bombarded with questions like “How do you want us to build X” and “Should we make this X or Y”. The team has gotten lazy – they know that they will have to ask for permission anyway, so why bother thinking of solutions?

You have cross-functional teams but they can’t do anything without getting approval from external dependencies. That could be a central technical function or an architecture committee, a product council or the stakeholders. Their feedback loop is to their business stakeholders, not their customer. The teams are missing dedicated resources because they are shared among many other teams. This slows them down because they have to book time with the resource. They never get the opportunity to become fully cross-functional because these experts don’t have the time to ensure their expertise is spread across the teams.

Take the time to give enough information to the team and let them make their own decisions. Delegate, take back your time and your sanity. The team can’t grow if you do everything for them. They may make mistakes but they will always get some valuable learning from it. If you have short iterations you can recover.

Think about the feedback loops the team is using, do they go up the hierarchy for decisions or do they go to the data and ultimately the customer? Do they get training in the things that your organisation controls centrally? Knowledge gives them confidence and allows them to do more of this decision making correctly as an autonomous team and ultimately, MOVE FASTER.

Destroying rapid value delivery

You say – We are a flat organisation

You say your teams are agile and day to day they work in a way that seems to look the part but the processes that surround them are rigidly enforced.

The work is decided for them and handed down, the length of time to spend on an item is decided for them and fixed in a roadmap. The problem is that when the team feels like there are no more decisions to be made they are demotivated. The retrospectives are meaningless because there is a wall of management and process where any significant suggested changes are blocked or deflected.

There is no safety from failure. This causes the managers to place structures and processes to ensure there is documentation of the rigor applied to decisions. Work longer than three days requires pages of proposal documentation and multiple levels of approval. There is no space for rapid innovation. By the time the work is approved the opportunity is lost and the momentum is gone from the team.

Let the team decide how much and what processes and documentation are needed to produce value for the customer. Use the retrospective to adjust and correct course and try again. Don’t stifle innovation and entrepreneurship in hierarchy.

If you don’t have confidence in the team to step back think about why that is? Do they not have the same information you have? Are the priorities you are working to the same as the ones they are working to? There may be a significant disconnect between their priorities and yours, their expectations and yours. Figure it out.

Learning and iteration applies to your agile too

These are just a few examples. Whatever brand of agile you’re doing make sure that what you say you’re doing is really what you’re doing. Be honest about how you work so your teams know the norms and expectations. The confusion and disappointment from reality not matching the rhetoric will result in unhappy teams and it will affect your products and customers too.

Try new things. Let your team’s try new things from their retros. They will grow and may have already grown out of what your original definition of ‘agile’ was. Guide them to ensure they make the best decisions for their customers and their products, but get out of their way and let them grow. It will eventually give you more free time to work on the important stuff.