Unclear on the concept

Management people are funny. They want “agile” development, then they get mad when you focus on early and continuous delivery of valuable software.

At the risk of sounding grumpy here, if you have some competing agenda then your “agile” efforts will fail.

Who doesn’t want early and continuous delivery of valuable software?

Sounds like a trick question, right?

It’s not. Here are some competing agendas I’ve seen up close:

• I need to justify my recent raise.
• I want estimates and deadlines to not have my fingerprints on them, so I can’t be called unreasonable in terms of expectations.
• I want to keep up with the industry, in the sense that “project manager” seems out of date but “scrum master” is hip and current.
• I want a lot more predictability in terms of deadlines and deliverables. (This one is yuge.)
• I want to hold individual developers accountable for meeting sprint goals.
• I need to reassure upper management that my people are actually working hard, so imposing a two-week deadline on everything looks productive.
• Blocking tasks out in detail on MS Project is kind of a lot of work, and it always ends in tears, so I don’t want to do it.
• PMBOK looks like a big commitment and “agile” is really informal, thus easier.

The thing I wish everyone knew…

…is that it’s okay to not want the radical power shifts that are a necessary part of an Agile transformation. If your organization likes hierarchy, and if (for example) software development managers don’t get to push back when their bosses are creating obstacles, then that is what it is and it’s best that you avoid working under a paradigm that’s a lie.

To give you an idea of what I’m talking about,

here’s a thing that came up a year or so ago. My team was developing a thing that relied very heavily on an address validation service that a) was not free; and b) required an access token. We’d reached a point at which that was clearly the next piece to work on: everything leading up to that was working great, and everything after it relied on the output of the address validation.

The development manager, who was also serving as scrum master, said… no! That’s not the next thing you’re working on! The people who approve spending money, and the people who review licenses and contracts, and the people who write his evaluations–they weren’t part of the team and they hadn’t had any urgency about this particular purchase and they simply weren’t ready to move forward with it. So the address validation was on hold.

(Before anyone asks, yes we had a mock service to test with. But a mock isn’t a deliverable.)

We found something else to do for the next few “sprints”

but it wasn’t anything like “early and continuous delivery of valuable software.” It was trying to fill time with tasks that might be important later on. Features that hadn’t been thought through because they were of secondary importance.

The scrum master’s job in this scenario is to remove the obstacle, not to divert the team into doing less valuable work. The organization had a (strongly implied) principle of “shut up and get it done” that trumped the (clearly stated) Agile principle of giving motivated individuals the support they need as well as the (clearly stated) Scrum idea that the scrum master serves the team.

What I’m getting at isn’t so much that this department was doing it wrong. What I’m getting at is that they were not emotionally or culturally ready to apply Agile principles and further that maybe that is okay.

Not being Agile is okay. Force-fitting Agile artifacts and practices into a work environment that doesn’t jibe with Agile principles, however, is going to go really badly.

It depends on what you prioritize. It depends on what you think is important. It depends on your agenda, and your agenda is largely dictated by what senior management is going to reward and penalize.

Epilogue

I’m looking at this post a couple years later and realizing I didn’t share the outcome.

The project I’m talking about here had four full-time developers, and our deliverable was a “contact” page on an ASP.NET platform. It took six months.