"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?

Continuous Integration: What is it Really?

Why practice Continuous Integration? What is the Business goal behind improving engineering practices? What if we were to make this into a user story? What would it look like?  

“As a business, I want the ability to introduce features and functionality to my customers with very little risk, so that more people will buy and use our products.”

How would we accomplish this goal? You might start with a shift to a leaner process. One that would shorten the feedback loop between customers and the developers, on features and products. This would help ensure you are building what they actually want. You might design your teams around products instead of subdividing the company by “IT” and “Business” and then further subdividing technical teams around technological silos and businesses around domain silos. Those would be great steps to take. 

So how then do we deliver the product? We probably create product teams comprised of business people and technical people. These team members collectively have all the knowledge needed to create the product. So how do we get it, and subsequent changes, to market in a world that wants everything right now? Without exposing the company to the huge risks associated with big-bang software releases? 

The silver bullet seems to be “CI/CD”. It is on everybody’s lips. But do they understand it? Most people think CI/CD is a hardware/software pipeline where things get checked into a version control system and are "automagically" deployed to production. But is it just software and hardware with some automation mixed in? When I ask people if they need help with engineering practices such as continuous integration, they often respond with:

“We are already doing it. We have Jenkins. We use git.”

“Hmmmm. So ‘having Jenkins’ and a repo means you are practicing Continuous Integration?”, I ask.

“Well… we check into git and then Jenkins runs a build.”

“Ah! Cool! So all your code is integrated together and then you execute a test of all your functionality automatically through an automated test suite?”

“Well, no. Not all our functionality. Actually, we don’t really have a lot of automated tests.”

“So you are just verifying the compile??”

“Um… yeah.”

The bottom line is that when we start probing we find that the practice of Continuous Integration is not being followed. So… They have the hardware. They have the software to kick off a build. But they are lacking in test automation or at least lacking in “good tests”.

Side note: assertNotNull(Object) does not qualify as a good test.

“Continuous integration is a practice–it is about what people do, not about what tools they use. As a project starts to scale, it is easy to be deceived into thinking that the team is practicing continuous integration just because all of the tools are set up and running. If developers do not have the discipline to integrate their changes on a regular basis or to maintain the integration environment in a good working order they are not practicing continuous integration.”  - https://less.works/less/technical-excellence/continuous-integration.html

Giving CI to dev teams without teaching them how to practice it, is like giving a hammer to a six-year-old. Just because the six-year-old is able to lift the hammer, doesn’t mean he should. To use a hammer properly one must know its purpose, the right applications for its use, and develop the proper motor skills and coordination to use it effectively. Without that knowledge in place, things just get smashed. CI is no different. It is a tool used by developers. Developers must know how to employ it as it is a practice. They must change the way they work and change their habits. This is hard enough to do for a small team without coaching. Attempting to implement it at scale without technical coaching is pretty near impossible.

The six-year-old may be able to pick up the hammer, but that doesn’t make him or her a carpenter. It just makes them dangerous.

We can talk about Continous Deployment on another day. Teams should concentrate on learning Continuous Integration first.  

Sprint Zero - some just can't let go of the Waterfall Mindset

Sprint Zero is NOT a part of Scrum. You will not find it in the Scrum Guide or any Scrum Certification Course. Sprint Zero is an anti-pattern.

So where did it come from? People that have little understanding of Scrum but LOTS of Waterfall experience must have come up with this term.

A “Sprint 0” clearly does not deliver a potentially releasable product. In fact it perpetuates the Waterfall mindset of Big Up Front Analysis and Planning. It is almost identical to what most of us remember as “gathering requirements” before a project.  I cannot emphasize enough how “anti-agile” this concept is.  Does that mean we don’t put together a Product Vision and a backlog before we start Sprinting? No. Of course not. But we do it BEFORE we start Sprinting. If we want to eliminate the waterfall mindset, we need to start by eliminating the concept of a “planning Sprint” or a Sprint 0. Plan all you want. Just don’t call it a “Sprint”. Clearly, it is not. Don’t just take my word for it, you can consult Mike Cohn, the Scrum Alliance,  Alex Ballarin Latre, and the Scrum Guide.

“The heart of Scrum is a Sprint, a time-box of one month or less during which a 'Done', usable, and potentially releasable product Increment is created.” - Scrum Guide 

“A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release… that activity does not meet the definition of a Sprint in Scrum, so it is better not to call it so.” - Alex Ballarin Latre

https://www.scrum.org/resources/blog/scrum-myths-it-ok-have-sprint-0-design-sprint-hardening-sprint

“Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero.

One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product?” – Mike Cohn, https://www.mountaingoatsoftware.com/blog/sprint-zero-a-good-idea-or-not


Some "Reasons" given to justify a Sprint Zero:

[we need some upfront] "planning, product backlog setup, and design. This is my favorite, as it clearly indicates two things:

1. Someone is finding it hard to move away from Waterfall.
2. The organization is finding it difficult to give up control and empower the team.

Introducing a long Sprint Zero at the start and a long validation at the end helps keep the love for Waterfall alive. In addition, it hinders the effectiveness of Scrum.

If Waterfall works for you, then by all means, you should use Waterfall. This article focuses on teams that follow the Scrum rituals but keep the Waterfall soul…

planning, product backlog setup, and design is a proxy for "big design up front" (BDF). In Agile we try to stay away from that. Often, an associated symptom will be a very hierarchical organization, thus preventing the Scrum team from being really empowered.

Personnel who are most active in Sprint Zero may be different from those most active in other sprints.

The Sprint Zero leaders will "guide" the team through sprints but may not feel bound by the time and other constraints that the rest of the team has.

This creates a two-level organization instead of the flat one that Scrum promotes. A two-level organization tends to follow a task-assignment and status-reporting culture, instead of a mind-set of ownership and delivering value.

Scrum believes that every sprint should deliver potentially usable value. None of the above Sprint Zero items produce any value for the customer. They cannot be demoed.”

- https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero

In other words, there is no valid reason for a Scrum Team to have a Sprint 0. It is for people who cannot let go of the Waterfall mentality and/or do not fully understand Scrum. As a coach that has been practicing Scrum since 2004, I can tell you there is no need – and plenty of reasons against – creating a “Sprint 0” and calling it Scrum.

You Just Might Be Waterfall...

• If you have a "Sprint Zero" that lasts 12 weeks to get a "jump on planning"... You just might be Waterfall.
• If you have a test team that works a "sprint behind"...
• If you have a test team that performs all of your regression tests. Manually...
• If you have an "Agile Project Manager" who drives you to "increase your velocity"...
• If you have a partially allocated resource on your team...
• If you have a Technical Lead on your team who is responsible for all decisions regarding software...
• If your team and the people around your team often use the phrases "but we’re not true agile" or "but we’re not pure agile"...
• If you plan on completing System, Integration, and Performance Testing in your last four Sprints...
• If your leadership complains that they need more Status Reporting and they have to know what the "Gap to Green" is...
• If your daily standup consists of going through all the tickets on your board and giving a progress report on each of them...
• If your Scrum Master has more than three letters behind his or her name (SPC4, CSP, ICP-ACC, SA4, CSPO, PMPO, PSPO-I, CSM, SASM, PSM-I, PMI-ACP, SSM, TKP, PMP)...
• If your Release Plan looks like this: Sprint 1-4 Analysis, Sprint 5-8 Design, Sprint 9-15 Coding, Sprint 16 and 17 Test... You just might be Waterfall.
• If you have a pre-planning meeting to prepare for your planning meeting...  
• If at any time, anyone ever utters the phrase "steering committee"...  
• If your teams spends a “Sprint” on estimation...
• If your “Agile Project Manager” tells you that your estimation (which you wasted a whole "Sprint" developing) “won’t work”...
• If your dev team members tell you that their stories are done “except for JUNITs”...
• If your dev team members feel that assertNotNull(someObject) is a comprehensive test...
• If your testers “have nothing to do” because they are “waiting for the coders to finish” ...
• If your Product Backlog consists of a long list of technical tasks...
• If your Product Owner insists on the team performing Release Planning every two weeks...
• If your “Agile Manager” starts to “grade” individual team members on the number of stories they finish each Sprint...
• *If your stakeholders start deriding you as a “purist” because you insist they AND the Product Owner attend the Sprint Review...
• If your PMO…  Wait? You STILL have a PMO..?  You just might be waterfall.
• But seriously, If your PMO starts looking for “metrics like velocity” to measure teams’ success...
• If your Enterprise declares that all story points must be normalized... You just might be Waterfall. Or SAFe Certified. (But what’s the difference, really?)
• Finally, if you think that developing a Big up Front Design, Fixing Scope, Fixing Delivery Date, AND Fixing Dollar cost, to create a software application built by partially allocated resources conducting a series of hand-offs to different teams comprised of geographically dispersed contractors across the globe, and then throwing it all together at the end and believing that it will all work, (pause to breathe here) is a better way of building software... You just might be Waterfall. And live in an alternate reality.

Why Adopt Agile?

On a recent discussion board, a fellow LinkedIn member asked the question,
"Why Adopt Agile?" 

Here's his complete question:

"Hey all,
I figure we often get asked the question by executives and engineering teams "Why should we adopt agile?" I wanted to better articulate my argument to my team, and hope that a few of you may bring insight into reasons to adopt Agile that I haven't thought of before."
http://www.linkedin.com/groups/Why-Adopt-Agile-81065.S.5842362499172704258?view=&srchtype=discussedNews&gid=81065&item=5842362499172704258&type=member&trk=eml-anet_dig-b_pd-ttl-cn&fromEmail=&ut=1XBI14jvlLxm81

Since I believe he is probably not the only one with this question, I have decided to share my response here:

Communication.  Communication. Communication.  Everything we do boils down to communicating. In Software development we get requirements from the business and attempt to turn them into software.  In the waterfall world you gather all the requirements in front with the assumption that all the requirements can be gathered and they won't change over time.  If you can get a comprehensive list of requirements and spend enough time up front figuring out how you will build it, if the business approves the design, you'll be set.  The problem is those assumptions are simply wrong.  Requirements will change. The team’s understanding of requirements will change. Problems that could not be foreseen in development will arise and they will impact the design.  These are the main reasons Waterfall projects fail.  Sure they try to manage things like scope and make it very hard to change scope. But if you don't allow the scope to change, you will deliver a product that is no longer what the business wants or needs.  On the other hand we all know that allowing scope to change in a world of Big Up Front Design (BUFD) is extremely expensive.

Agile addresses these issues through effective and frequent communication with the product owners (the business). Short Sprints give short feedback loops.  Constant discussions about changing priorities and requirements can be addressed, entered into a backlog, and tackled with very low cost in the very next Sprint.  Requirements are gathered via user stories.  The reason for having user stories is to facilitate discussions between the developers and the business about what it is they think they need. The requirement itself is captured on a 3x5 card that can be discarded on a moment’s notice if a "story" (requirement) changes.  At the end of a Sprint, the business can see functioning software and can tell immediately if what was delivered by the team, was the thing they intended to be built or something different. Feedback is shared and corrections can be applied in the next Sprint. 

Agile does all the same things as waterfall: requirements gathering, design and release planning, construction and testing. But it mitigates risk in several ways.  First, it shortens the cycle for feedback to the length of your Sprint (usually 2-3 weeks, instead of months) Second, it involves the business intimately with the design, development, and construction through each process rather than at the end of each process making it easier to accommodate change. Third, it delivers function software at the end of each Sprint.  So the business has something that works.  If you halt a waterfall project before the construction phase is completed, you have piles of documentation that can't DO anything. 

Agile is the way to go because it minimizes risk to the business by emphasizing communication and constant feedback while delivering functional software.  This is something the business cannot duplicate with weekly Status Reports.

Agile software development eliminates the unnecessary artifacts that are often required to give some architect or business person a warm fuzzy and replaces it with intimate involvement in the project.  It moves quickly and embraces change. 

In a business world that has become almost wholly dependent on technology and technology that changes at incredible speeds, Agile is simply the safest thing for a business to do.