Blog

Irrespective of whether you call them Anti-Patterns or just “common problems” they’re to be avoided if you want your agile project to be success. In the first of this three part series we’re going to concentrate on the wider organization that agile projects operate within. By avoiding the issues in this post you’ll be providing the best possible environment for your teams and projects to flourish.

The other articles in this series are Part 2 – Culture and Behaviour and Part 3 – Delivery.

#1 No fundamental value proposition

The symptoms: Also known as building in a vacuum – you don’t know why you’re building what you’re building it. You don’t know who’d use what you’re building. You have a Product Owner but you don’t know what that means.

The problem: Agile and Lean methods are great for getting work done quickly but without a strong fundamental goal, it can be easy to fall into a pattern of “busy work”. We tend to see this one more in start-ups than in established businesses.

Our solution: The Product Owner role is appropriate when you’ve good a decent idea of what you’re building. If you don’t, figure out quickly whose problems you’re trying to solve – using techniques such as ghetto testing and early customer engagement (via interview, or split-tested landing pages).

#2 Adoption is top down only

The symptoms: All of the CxO-levels in the organisation are Six Sigma Black Belts but no one else knows what Six Sigma, let alone what it means to be a Black Belt in it. Consequently, the change process isn’t inclusive and it self-implodes. Team leads feel that there is a lack of trust in them and their team. Self-organisation and continual improvement is inhibited, and day-to-day life is replaced with command-and-control masquerading as something new.

Our solution: Get more people bought in at all levels of the organisation. Education is a great way to get this buy-in. Understand why changes are looming on the horizon. More often than not they will be founded on good intentions. These good intentions are the key to getting everyone to understand the reason for the changes and benefits they are expected to bring.

#3 Educate (only) the managers

Symptoms: A project manager is certified as a Scrum Master. Agile sounds like an excellent tool in the toolbox, so they jump at it. Then they realise that Gantt charts and big upfront planning is no longer the order of the day. With a lack of support from above and below the project manager franticly back peddles to “the way did things before”.

The problem: One of the key benefits of Lean and Agile methodologies is that they harness the intelligence and creativity of every person in the organisation. It’s truly amazing how much a committed, self organising team can achieve in a short space of time. Unfortunately, many organisations scupper their chances of getting the right level of commitment during the initial stages of an agile rollout. The common pattern we see is that middle managers are sent on a “certified” training course and then expected to roll out a new way of working to their team, having had only 24 hours exposure to it themselves. This leaves the team with a weak understanding of what the changes are, how they work and what benefits they are supposed to deliver. Consequently the level of buy in is well below what it could be and managers are left unsupported, increasing the chance that they will revert to their old way of working.

Our solution: Middle managers can be the most powerful champions or the most destructive force in an organisation. Rapidly discover intentions. If good, work with them to understand and support the change they could deliver. Encourage cooperation with those above, and below. If negative intentions are the immovable fact, look to move this person to a more appropriate area of the business. Either way, the rest of the team must be part of what’s happening – above, and below.

#4 Grassroots only adoption

The symptoms: A team has adopted Lean working practises internally. They believe they are doing the right thing for them, but their new way of working may not be aligned with the rest of the project and organisation. Disruption occurs, the team start working to their own agenda, and their outperformance is seen as damaging.

The problem: Agile and Lean methods can work wonders at the delivery end of the business, irrespective of whether you are delivering products or services. We’ve seen delivery teams become more productive and customer focussed as a result of adopting agile methods. That said, your organisation will be missing out on a good 50% of the benefits if the upper tiers of organisation don’t understand the method of delivery.

Our solution: Education is the key here. The people who established the grassroots effort will make ambassadors for Lean and Agile in the wider organisation. Look out for them, and support them, but be wary of this situation getting out of control. Without buy-in from other teams and above this grassroots effort ultimately will only improve the original team – and there is a real risk of a team-within-a-team culture.

#5 Big Bang adoptions

The symptoms: CxO-level managers announce a massive overhaul of working practice. It’s called Agile. It’ll take 2 years. Everyone better get on board.

The problem: We’re big believers that change doesn’t have to be risky. But, this only holds true if your programme for making changes isn’t inherently risk laden. What could be more risky than a “big bang” adoption of new way of working? Every change we make has a cost associated with it. Whether you know its name or not, you’ve probably come across Virginia Satir’s Change Model. It is this model that describes the stages we go through whenever we make change. The diagram below shows how team performance tends to fluctuate throughout a programme of change. The area under to curve is the cost of change.

In a big bang adoption this cost of change can be large and if you haven’t trialled your changes beforehand you are effectively jumping off a big cliff into a sea of unknown cost.

Our solution: Like most change initiatives, the overhaul is probably being driven by good intentions, but ultimately, this kind of overhaul will result in the company being where it should be now, in 2 years. Better to make baby step improvements frequently, than huge overhauls every 2-3 years.

Comments?

That’s it for the first part of this post, we’d love to hear your comments on the anti-patterns we’ve identified and our suggested solutions. Perhaps you’ve encountered some of the anti-patterns described above?

In parts two and three we’ll look at the team level anti-patterns that can occur once your agile rollout is underway.