Failing Agile

The theft of agile by the corporate world, mind you with great help from some of signatories of the Manifesto for Agile Software Development, has caused exhaustion for many people attempting to work with any form of agility.

The associated frameworks as well as the bits and pieces of “best practices” that are tightly coupled with agile cause some of the largest dysfunction. This will not be an attack on all things I deem as “not agile”. After all, who the hell am I to call something agile or not agile.

All I ask is that you keep an open mind to the experiences I will share. I in no way am telling you what to do.

Working with Scrum

At this point, I do not believe anyone in software development, project management, and what I believe soon to be the rest of the working world, would have not heard of or worked within Scrum. No matter the usage of this framework, it is by far the most popular. Although SAFe is making this a closer race than it has been in the past. I have had good and bad experiences within Scrum. Most of the good comes from the people doing the work deciding to try and use the Scrum framework to organize their work and expose problems. This is not a bad thought going into Scrum. However, most problems exposed while working within Scrum are not actually problems, they are symptoms of larger problems. And quite often some of the symptoms that are exposed are not within the teams ability to solve, let alone the actual organizational problem causing that symptom. The irony of this comes when Scrum itself becomes the creator of problems and symptoms.

If you notice, I refer to working “within Scrum”. I mean this as it is written. Scrum is a framework. And a rather rigid framework. If you are working “within” a framework, you are beholden to the rules and processes of said framework which has now become your system. The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and honorable mention to the “Backlog Refinement Meeting” (which is not part of Scrum but somehow makes an appearance everywhere I have been) make up your process in your system. When used as intended, these processes can be quite good.

I am not getting into all of the dysfunction within Scrum today. Simply stating that this new system is often at odds with the rest of systems that make up the overall organizational system at play. When these systems come into contact with one another, they do not play nicely. And the organizational system, a.k.a “the way we’ve always done it”, usually wins. It does not remove teams working within Scrum. It mutates even the best teams that have found Scrum to be useful into mirroring the dominant systems process while leaving the terminology from Scrum in-tact. This is where SAFe, LeSS, Nexus and the newly introduced Autoscrum come from. These “scaled frameworks” ultimately include all of the normal organization bureaucracy that now surrounds the newly introduced Scrum framework. These systems consume the newly introduced Scrum and assimilate it. Yes, kind of like the Borg.

I do not have some secret way to avoid this. Or some miracle new fancy framework to sell you that solves for this. This is just a pattern I have noticed working within Scrum at various organizations of varying sizes.

Introducing and implementing new frameworks (systems) to an already existing complex system simply does not work. Never has. Ultimately, to quote Kevin Meadows “The system will assert itself.”

Working with XP (Extreme Programming)

The geek in me immediately liked XP. I found the values, principles and practices to be connected in a way that made sense. Pair-programming, which later led me into Mob Programming, is quite possibly the best way to create software in my opinion. The knowledge sharing and collaboration with these practices are second to none. TDD (Test-Driven Development), again in my experience, has increased my confidence in the software we create together exponentially. Our ability to aggressively refactor our code and work with simple designs and small steps, continuously integrating as we go as to achieve that rapid feedback we need to deliver valuable software to customers left me in awe the first time I experienced it.

The XP teams I have been lucky enough to be a part of benefited from an on-site customer rather than a product owner. Now before anyone attacks me for being anti-product, I am not. I am simply stating that my experience working with the actual customer that is going to use the software we create has provided such greater clarity and allowed us to deliver such a higher quality of useful software then when we worked with a product owner or product manager alone.

I often start to equal what happens with mob programming teams to what happens with XP teams. Mainly, the way we work is much the same. We are creating and supporting a culture that provides for learning. We are not afraid to be wrong or say we don’t know. We collaborate in a way that sends you home from work happy and even excited to return. The diversity of thought that goes into the way we work is built on a very high level of psychological safety. I could go on about XP teams and Mob Programming teams with their similarities, but I fear I would officially reach TL;DR territory.

Working with SAFe

Far too much self inflicted and framework inflicted trauma for me to recount today.

Working with Autoscrum

I have learned my lesson from SAFe. And if you want to tell me I do not have an open mind to try and experiment with new ways of working. You are free to go look at and work within the Autoscrum framework and find the agility. If you do, write a paper to proclaim its excellence in agility. But make sure you obtain the inevitable long list of certifications. This surely will lead to the credibility of your words.

(Yes, that was a bit snarky)

Working with Traditional Project Management (Waterfall)

See “Working with SAFe”.

Working with Kanban

First, I do not think Kanban is a framework. It is a workflow management method. Maybe I am splitting hairs here, but I see a vast difference between the frameworks mentioned above and Kanban. With organizations and teams I have worked in or with that have understood Kanban and decided to use that approach it has worked well. The irony is when combined with a framework, such as Scrum, and it morphs into ScrumBan, it gets rather messy.

I have yet to experience real dysfunctional habits or behaviors with Kanban. Teams struggle to get WIP under control sometimes. But often this is caused by an infringement of the larger organizational system pushing for “more faster”. This in turn causes teams, pushed by poor management decisions, to “divide and conquer” and turn into groups of people tackling tasks individually. Large numbers of dependencies arise. The benefits of Flow are lost. And the Kanban board turns into the nightmare wall with all of those strings looping around and connecting to different tasks or stories.

I personally enjoy Kanban and have found it to be a good sense making way of working.

Working with Agility

I enjoy working in an agile way. My experience with XP, Kanban and Flow have been far and away the most agile way of working. What I mean is best described by a few great thinkers I have had the pleasure to watch give talks or have conversations with.

Dave Thomas describes agile like this:

“Agility – What to Do

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned

Agility – How to Do It

• When faced with two or more alternatives that deliver roughly the same value, take the path that makes future changes easier“

You can see Dave’s talk here.

Woody Zuill, who is a very kind and thoughtful person, not to mention a brilliant thinker, has many great talks about agility and working together that you should take the time to watch, listen and think about. Woody and Kevin Meadows book Mob Programming is a must read. Woody describes agility in a way that makes great sense to me.

“Agile is all about the steering.” – Woody Zuill

And I couldn’t agree more. When Woody said that, something clicked in my brain. Almost like a flip of a switch. I was confronted with asking myself a question.

“How do these frameworks, methods or processes we currently use help us to steer and make good decisions?”

If you look at the way you are working from the perspective of steering and good decision making, so many of the things you are most likely doing will inevitably fall out of your current system. You will find that they do not help you steer or make good decisions. Not only do they not help, they are even the reasons why you are unable to steer or make good decisions. Ironic I think.

My great fortune to have had great dialogue with some brilliant people working with agility has provided me with a visual that I use when asked “What is agile?”

Now I know this image isn’t very pretty, and the circle isn’t perfect. But it is ok to “be sloppy”. Some of you reading this know exactly what I mean.

This image gets the point across, you understand what I am saying, therefor it is good, it works. That and I am not that great at making the arrows into a circle.

You can choose to think of this as an over simplification. And that would be understandable and your choice. Again, I am not telling you how to work or how to build your system. I want to convey that if it doesn’t help you steer, if it doesn’t help you make good decisions, if it doesn’t help you solve real problems, and greater than all of that, if it doesn’t make you happy or causes you pain, or has no positive impact on delivering value to your customer, then why are you doing it?

Of even greater importance is looking at your current system from a human point of view. We quite often hear people stating “we are a people and/or family first organization.” Yet the systems perpetuated are inherently anti-people. Our goal should not be to create the perfect system that cranks out X number of features every hour, day, week, month, quarter etc.. To use one of Woody Zuill’s agile maxims:

“The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable.” – Woody Zuill

To be in this state, to me, means you need to be willing to look at your current relationships, processes, and what you believe with a critical eye. I have found since my realization from when that switch flipped, that all of these needed work and changing in order to achieve what I needed to. Which again leads me to another maxim:

“Question everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.” – Woody Zuill

Remember I told you how brilliant of a thinker Woody is.

Closing

Throughout this post I was thinking of how to summarize what is most important about agile. How to simply state the good and make it stick. At this moment, I do not have any grand earth breaking statement to sum agility up with. There is a sort of value statement to keep in mind if you choose to work with agility.