Agile Transformation: How to tell that you are failing…

“So being a geek at heart I present to you my list of anti-patterns regarding agile transformation.”

Behold the agile transformation wizard, here to save the day!

I present to you my list of wizardly anti-patterns regarding agile transformation…

I recently did an article about ‘why corporate companies suck at agile‘. Since writing that post I have had a gnawing urge to supplement the post with something a little more tangible and pragmatic.

So being a geek at heart I present to you my list of anti-patterns regarding agile transformation. For the less technically minded among us an anti-pattern is typically a documented recurring software problem that is usually ineffective and risks being highly counterproductive. They serve as a vocabulary to shape discussions about design based on past industry experience. Since Andrew Koenig coined the term in 1995 it has been adopted in fields other than software design, so I feel its a great succinct format to present my views with.

Anti Pattern: “Not my gig”

If your executive or management layer views “agile transformation” as something that is exclusively the domain of tech teams and if none of the other supporting functions are involved you might have a problem. Agile is a culture not a process or activity. If you only optimize the delivery function and not the supporting business functions all you are doing is over optimizing one aspect of your organization making it incompatible with the others. Agile transformation has to be an organization-wide activity including the executive layer or you are wasting your time.

Anti Pattern: “Don’t worry we’re experts”

If your army of agile experts and trainers only talk about methodologies and process then you have been duped and should strongly consider firing every single one of those expensive consultants on the spot. Agile coaching and scrum mastery are incredible difficult skill-sets to source for. The reason for this is because these roles are geared toward intangibles that are inherently hard to track and measure. Instead of parroting process or methodology the agile experts you are looking are individuals that continually cultivating the understanding that agility is a mindset and culture. The sad truth is that many agile experts are not experts at all. They are former project managers that need to stay relevant and subsequently went on scrum training (typically given by equally inexperienced agile experts). With the blind leading the blind all focus ends up on the tangible part of the role being process and methodology. Unless your agile expert has actually run a real agile project (at scale) and proven it to be a success in from the perspective of the (proper) agile community, you are missing the point.

Anti Pattern: “Madame Secretary”

Related to the “don’t worry we’re experts” anti pattern, the “madame secretary” can be spotted when a great majority of your scrum masters are merely acting as agile secretaries to their squads. Instead of doing any real coaching (or driving any changes) these individuals spend most of their time simply following the ordained agile events in a kind of weird check-boxing exercise. This happens a lot for scrum masters sourced from other roles or people that have been trained by one of these snake oil training merchants. Your agility team members should be students of the human psyche. They should be passionate about understanding human personality theory and should continually be coming up with experiments to improve the psychologically safe work environment of their teams. They should be obsessed by tracking every metric of team happiness. They should be an undeniable expert in their field. If a developer knows more about agile development than your scrum masters, you should be afraid, be very afraid.

Anti Pattern: “Waterscrumfalls hiding”

The waterscrumfall is already a known term but this anti-pattern takes the concept a bit further suggesting the intent behind it. Waterscrumfall refers to when your development teams are doing everything in their powers to run in an agile way, but all the other phases of the project don’t operate in the same way. This typically results in an over optimization of the development phase but unchanged slow moving cycles everywhere else resulting in sub optimal results. Now for the new bit. Agile is rough, it makes everything transparent for everyone to see. Developers embrace this since it beats having nobody else understanding what on earth they are up to. But this level of transparency might not sit well with some of the other more traditional functions in your organization. Waterfall was a great way to obfuscate many of the daily duties and tasks due to its inefficiencies. If you see signs of localized agile adoption it might be the unfortunate truth that there are some in your organization that prefer to hide from view.

Anti Pattern: “Functional Culture”

When cultural concepts get functionalized (and frequently centralized) you’re doing it wrong. Devops is a great example. Devops is a culture, it is a way to describe development and operations coming closer to one another. How do organizations respond? By hiring dedicated devops competencies and raving about them every opportunity. Operations personnel that fear for their future re-brand themselves and start singing from the devops hymn book. Team level devops activities get centralized to fancy new committees tasked with solving holistic problems establishing fancy new standards everywhere for everyone to use. If you are spinning up working groups, committees or new functions left, right and center around culture based concepts, you are doing it wrong.

Anti Pattern: “Just because”

Agile adoption should be tied to a tangible and inspirational goal. Unless there is a compelling ‘why’ as to why you are doing this transformation you will not succeed. Talking only about the ‘what’ benefits (like cost reductions or greater efficiency etc) is not going to get people to embrace a new culture shift. If you are getting a lackluster response from your people you should probably watch this excellent video by Simon Sinek, and reconsider your approach to leadership.