Bad Agile Management Burns Scrum Teams

Last month Giles Bowkett wrote a scathing blog post about scrum called: Why Scrum Should Basically Just Die in a Fire. It’s a provocative article that shows how damaging bad agile and scrum can be to a team.

Ms. Glaze | Flame | Flickr

Ms. Glaze | Flame | Flickr

I’m not going to go point by point and argue with Mr. Bowkett about his experiences with scrum. They are his experiences, and they are truly awful. I have sympathy for him and those who have been burned by a botched agile transformation.

With waterfall, teams know what they are signing up for at the start of a project. They know there will be problems and that a death march is likely. They also know that the date set at the beginning of the project is likely wrong, but still they soldier on.

But with agile and scrum it’s supposed to be different. The agile manifesto is a developer play aimed at making the lives of engineers better. Scrum specifically puts the team in control of how they accomplish their work. Everything should be great.

But often, it isn’t.

Mr. Bowkett makes this point by calling out many common scrum anti-patterns that he has experienced:

These are all valid – and unfortunately common – problems on scrum teams. However, the conclusion that he draws from the existence of these problems misses the mark.

In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.

Rather than cover up individual inabilities, scrum exposes the bad practices of organizations. Quickly. Work becomes transparent, impediments become obvious, and old practices become extra painful.

The culprit here are manager who thought they were getting hyper-productivity for free. They want the benefits of scrum, without having to change.

Mr. Bowkett’s problem is with lousy managers, not scrum.

The agile community is also partially to blame. The tendency is to focus coaching and training on the scrum team. But it is the management team members that we need to be working on the most. Bad scrum cannot take root in an organization that embraces the scrum values from the top down.

Part of embracing the scrum values is accepting the twelve principles of agile from the agile manifesto, which Mr. Bowkett also railed against.

I don’t think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: “business people and developers must work together.” Why are we supposed to think developers are not business people?

We’re not. The intent of this agile principle is the end the “us vs them” mentality between IT and “the business”. With Scrum, the expectation is that the product owner is co-located with the development team and available to answer questions about the product backlog items.

This isn’t a slight against the business acumen of developers. It’s a call for close collaboration between stakeholders and engineers. How else can the development team know if they are working on the most valuable features for the business?

Question: Have you been a part of a poor agile transformation? What went wrong? How could things have gone better? You can leave a comment by clicking here.

Kindness is the Missing Agile Value

The agile community is vibrant and passionate – full of people with great ideas on how to deliver valuable work. It can also be a difficult place to visit. We need to fix that.

Quinn Dombrowski | Hey Listen! | Flickr

Quinn Dombrowski | Hey Listen! | Flickr

To change the heart and mind of another person you first have to understand where they are coming from. You learn their story by listening. I don’t mean the kind of listening where you wait for your opportunity to drop your agile knowledge on the someone.

I’m talking about actively listening to the person and asking clarifying questions. As you gain knowledge about the person you can begin to make suggestions that are relevant to their present situation.

This does not mean that there will not be resistance to your scrum or agile suggestions. People not used to “just in time” planning or “self-organization” will likely not understand the concepts on the first pass. They will probably reject the ideas immediately.

This happens for a number of reasons:

  1. Fear:  Change is scary. It makes your problems transparent and places you in a vulnerable situation. Change means you are taking on something that is new to you. What if you look stupid? What if you fail?
  2. Success:  Management and project leaders have built careers on waterfall practices. Many have found success and promotions by adhering to predictive processes and practices. Convincing these people that agility is a more productive path is challenging.
  3. Culture:  Even if the results are not perfect – half of all waterfall projects struggle to deliver – people like the comfort of a culture they know and understand. In an agile world many traditional project behaviors do not play well. The rules change.

What this all boils down to is a user story that we are all working against when promoting agile in our organizations:  AS A PERSON I WANT PREDICTABILITY IN ORDER TO FEEL SAFE.

It is a tough nut to crack. But this user story is our reality. Where do we begin?

Be kind.

Do you remember when you were first introduced to agile? For me it was reading Kent Beck’s Extreme Programming Explained. I loved that book. It just made sense to me. And over the past 12 years since reading it, I’ve worked on my agile game. Guess what? I still struggle.

The truth is we all struggle. So be kind!

Agile is nuanced. And it is hard. If it wasn’t hard, agile coaches would be out of work and you wouldn’t be reading this blog. “It depends” is a common answer in our world, we work hard to push new ideas, and the agile space changes constantly. So be kind.

Being kind means that we accept that the first sprint of a new scrum team isn’t going to be perfect. It means that when answering a question online we do not belittle or berate people who are honestly seeking insights and feedback. It means we listen first, then speak.

Kindness is also shown when we are patient with those who still cling to their predictive processes, waterfall tendencies, and command and control mindsets. The path to agility is a marathon, not a sprint. It takes time to create new habits and practices. So be kind.

People do not show up to work with the intention of ruining your day. They have many of the same pressures that you do: spouse, kids, bills, and bosses. I believe that most people want to do the right thing. Let’s be the humble servant leaders that the agile principles call us to be and help them come around to the agile way of thinking. Listen, learn, and lead.

And yes, let’s be kind.

Question: Do you have a story about someone taking the time to help you learn agile? How did someone in the community make an impression on you? You can leave a comment by clicking here.