"Agile Project Management" is an Oxymoron

I hate to be this brutally honest: clearly the authors of Scrum Master job descriptions have no knowledge of what a Scrum Master is or does. This is disheartening for those of us that have practiced agility and Scrum for over a decade. We have seen the incredible successes that an agile team can achieve. 

Let’s get some things straight. A Scrum Master does NOT:

“Drive Maximum Efficiency of Scrum Teams”

“Manage” a Scrum team 

“Document and Hold the Team accountable”

“Instruct the team on how to develop detailed planning and budgeting”

Create “project controls”

Provide “Status Reporting”

Ensure “completion of projects on schedule and within budget and scope” 

Those are all things that Project Managers do. If you want a project manager, stick to Waterfall. They will be sure to deliver an obsolete product 18 months from now that is on time, within budget, and has all kinds of status reports, issue and dependency logs. A project that crosses all the “T”s and dots all the “I”s, while covering everyone’s “A”s.

On the other hand, if you want innovative teams that use changing requirements in a lightning fast marketplace as a competitive advantage, and the ability to realize value early and often through a continuous delivery pipeline to production, then you should probably start with Scrum and a Scrum Master.

What you should look for in a Scrum Master is someone who has been a DEVELOPER on a Scrum Team. If you want someone who has a lot of fancy letters behind their name like “PMP” and “PMI” and is a process “Black Belt”, you probably want to stick with Waterfall because you are barking up the wrong tree. 

The key to agile development is NOT process. The key to agile development is CLEAN CODE and continuous improvement. You get clean code by using automated testing and refactoring mercilessly. You use Scrum, and a Scrum Master, to help your team improve each Sprint. A Scrum Master is a facilitator. 

A mentor. 

A coach.

A remover of impediments. 

An enabler. 

She is not an "Agile Project Manager”. That is an oxymoron. An agile team is “self-organizing. They manage themselves.

A Scrum Master shields the team from outside distractions. She/he helps them become high performers who collaborate and innovate together. A Scrum Master helps a team to realize their potential by quickly identifying problems, analyzing them, and adapting. They keep the team focused on achieving Sprint Goals. They help the team to bake in quality to their products by teaching/encouraging sound TECHNICAL practices and helping the team to establish a sustainable, reliable delivery cadence. 

Asking for the same old Project Management garbage, will get you the same old lousy results. I know, because I have witnessed it time and again over the course of a twenty-year career in Software development as a programmer, dev team member, Technical Lead, Java Architect, Scrum Master, and Agile Transformation Coach. 

But hey, you don’t have to take my word for it. 

I do ask one favor though: When your efforts to “Go Agile” fail because you hired a PM to be a SM, and you have simply repackaged all the same waterfall processes under new agile terms without actually changing how you technically create software, please don’t say you “tried agile and it doesn’t work”. The truth is, you will not have “tried agile” at all.

No longer SAFe...

"Great spirits have always encountered violent opposition from mediocre minds. The mediocre mind is incapable of understanding the man who refuses to bow blindly to conventional prejudices and chooses instead to express his opinions courageously and honestly."
- Albert Einstein

I have noticed a disturbing trend in the industry around agile discussions. This may finally be real proof that agile has been hijacked by the mainstream: silencing dissenting views. 

In the last two weeks I have posted comments on articles pointing out that the emperor is indeed without clothes. (e.g. appropriating agile terms and ceremonies while continuing do work they way you always have, does not make one agile.) 

It is almost a politically correct thing now. I find myself practicing self-censorship rather than speak my mind about a certain scaling framework, or a hyphenated approach to agile, for fear of retribution. 

When did it become a bad thing to have a particular opinion about an approach to building software? Names have been hurled: "Purist!", "idealist!" drinker of the agile "kool-aid". I even had a well respected colleague yell at me when expressing an opinion about said framework that he did not agree with. Could have been the beer talking, but I doubt it.


Then there's those who claim agile can't work in the "real world".


The "real world"? Really? 


Any time I hear someone say, "In the real world..." I think "Where do you think I have been developing software for the last 18 years? Narnia?" I have seen agile work and I have seen what large companies do when they "go agile" by adopting a hybrid approach or that extremely popular scaling framework. Ask yourself this question: if all the Project Managers that have been practicing plan driven project management their entire career love it the minute they see it, do you really think it's agile?

Am I a bad person if I don't jump on a particular bandwagon? Don't I have the right to disagree on an intellectual level without fear of being labeled evil? Since they just keep censoring my comments, perhaps it would be best to just go along with the crowd - where it's SAFe.


Not a chance.

On the Bleeding Edge of Dysfunction

Note to reader: I apologize in advance for my pessimistic view. I am in dire need of a vacation.

"Agile and DevOps are better together in 2018"

This post, and these blogs crack me up. DevOps has been a part of agile for years. In order to have auto deployments, you need automated testing. Without automated testing you do not have agility. It is that simple. Oh you can apply some process framework of course:

“We’re doing Scrum."
"We're doing SAFe."
"We have small teams."
"We must be Agile.”
Wrong. 

What most people mean is that Scrum and DevOps are different. And they would be correct. But scrum does not equal agility. Scrum is simply a framework used to foster agility. Agility comes from strong technical practices, simple design, automated testing, working with the business every day, refactoring code mercilessly, continuously integrating, and continuously deploying the code to production. You can do scrum all day - or year - long but until you deploy the code, there is no agility. There is only code waiting to be deployed that may or may not serve the business needs once it has been released. 

Newsflash: This is NOT new stuff. This is stuff that a lot of us have been doing for over a decade. 

It never ceases to amaze me how slow to understand and adopt is the large enterprise. But once that buzzword becomes mainstream, everyone has to adopt it. Even if they have no clue how to do so, or what the terms they are slinging around actually mean. I have seen multiple large enterprises jump on the Continuous Delivery bandwagon and start building pipelines, all the while producing code that is tested manually. 

Sadly, they have no idea what is wrong with that picture. 

I have seen others adopt BDD as a way to automate "every test scenario" from the UI. That’s right. Let’s take the most brittle component of our software and write tests for all our functionality through it. Even if that functionality exists in another tier. Why? Because Selenium allows them to do so. Where will we get these test scenarios? From the three Amigos? From an excel spreadsheet authored by a separate test organization working in some far off location with almost no interaction with the development team. You know the same way they have done it for the last 30 years. But hey, they have people working around the clock on different continents. So you know it's more productive.

I have seen other organizations demand that everyone adopt Scrum and become a "product team". And they demand that they do so without changing the existing organization or the make up of any of their teams. Of course, these teams were built around technological silos. But hey, they "have a product mindset". Even if none of their teams are building anything that resembles an actual product. (Unless you think an ETL Transformation constitutes a product. And yes. Some of them actually do.)

They adopt all the Scrum Ceremonies but none of the agile principles. They continue to chunk up work in the same way and deliver it in silos. Then they can't understand why everything blows up during integration just like it did before they were "agile". Of course, they fail to realize that they haven't really changed a thing and are still using waterfall for delivery. Just smaller batches of it.

Now they are going to jump on the Agile DevOps bandwagon. Welcome to the party.

Unfortunately, they still don’t understand how agile software teams work and they still aren’t delivering potentially shippable increments of software.

Thanks to SAFe, they now have a way to coordinate all their releases together and commit to hard dates on fixed scope that is predetermined in a giant two-day planning session. A session where they "gain alignment" on all the dependencies between all their organizational and technical silos (never attempting to eliminate any of them) so that everyone can release together.

That sounds familiar for some reason. Can’t quite put my finger on where I have seen that before… 

Oh yeah. Every waterfall project I ever worked on. 

Well then. Nothing to worry about. 

They “are going agile” because they are “doing SAFe”.  Or Dark Scrum. Or building a continuous delivery pipeline that goes through the QA environment for weeks of system and integration testing before it can be deployed.

What could possibly go wrong?