Seven deadly sins of Agile

In theology, a deadly sin is believed to destroy the life of grace and charity within a person and thus creates the threat of eternal damnation. The "seven deadly sins" are not discrete from other sins, but are considered to be the origin of others.

There are a lot of things you can do wrong as an agile organization.
Many impediments are easy to resolve once you are aware. Some, however, may brickwall your team and will sooner or later kill your project - or maybe even your company!

Here is a list of seven potential agile "deadly sins" which can become the root cause of an insurmountable pile of impediments:

1 - Not having any problems

Every organization has problems. In fact, every person has problems: Nobody is perfect.
Not having a keen view for improvement potential will cause the team's velocity to stagnate. Once you stagnate, the first big hitter will devastate your output capacity.
Hyperproductive teams don't get to this stage because they are able to avoid all problems, but because they spot them early and deal with them effectively.

2 - Not tolerting failure

It is nice to work in an environment where everything can be anticipated well in advance. In this case, agile really isn't the best way to go. Reality usually looks different: work includes uncertainty and there is always a looming risk of missing vital information.
Catching such failures fast makes adjustment easy. Hiding small failures will result in big failures.

3 - Lack of trust

If I make a mistake, I can be sure that you will not use it to report my weakness to management, but you will simply correct it - preferably with feedback, so that I may learn for the future.
Unless we are a mutual safety net, catching each other fast and smooth, failure will be painful. And unless we can rely on painless failure, we can't take the risks we must take in order to deliver high value at high velocity.

4 - Pride

Agile thrives when every team member contributes to the best of their ability.
It is OK to have someone who has more ability than the rest, but it should be made that person's primary responsibility to get the rest of the team up to speed. Tolerating any form of primadonna antics will stifle the growth of the team. It will also pose the project at tremendous risk if this person becomes unavailable.

5 - Lack of automation

Doing simple things is often quicker manually than automated.  Unfortunately, a million simple things are still a lot.
Time saved by not automating often comes at the price of decreasing sustainability and future velocity!

6 - Lack of ownership

Agile products become great when everyone on the team cares. A team developing a product "for the product owner" with a low level of engagement will damage or even kill the product in the long term!

7 - Lack of focus

Agile projects become legends when the entire team is focused on delivering one product with maximum value.
It is very easy to lose this focus, for example by diluting the product vision, by overemphasizing internal practices, by having too much turnover in the team. In any case, the result will be a dissatisfied customer.

Agile Cargoism

In the South Seas there is a cargo cult of people. During the war, they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land.

From a Westerner's perspective, the actions of the Cargo Cult are ludicrous, but ask the practitioners - they feel entirely different about the matter!


But - what is Cargoism?
Cargoism is the firm belief that by imitating hard enough, you will produce the same results as other practitioners. If you're not successful, it's because you didn't imitate well enough. A cargoist doesn't realize that they are missing something, that the big picture is different from their perception.

James Shore wrote a good article on Agile Cargo Cult teams back in 2008. It's worth the read.
But an entire organization can become an Agile Cargo Cult!
I've heard many times when people said "Google is successful with Agile, Spotify is successful ... so we can also be!". Then, they spend big money to send their Managers to CSPO or CSM training and establish Scrum. Of course, the executives hope that projects will run faster and more successful once practices are adopted.
They hear about Agile, they see all those successful projects and they firmly believe: "Let's do Agile, and we'll be much more competitive."
So, team managers are renamed to Scrum Masters, project managers become Product Owners - the Releases are renamed to "Sprints", each of which is started with a Sprint Planning Meeting. Every day there's a Standup. At the end of a Sprint, there's a Review and a Retrospective.
Now, we're set up. The world is just waiting for our greatness to become manifest! We'll be a successful Agile Organization in no time - and our stock will skyrocket far beyond Apple, Google and Microsoft!

Oh wait - I've described the typical organization that will stop "Agile" after maybe 2 or 3 years, shelving the concept for good. Disillusioned employees will say "Agile is just a different name for the same old wine" and managers will say "We've tried Agile. It doesn't work, it's just a fad".

Blinded by the promise of easy success, fast, high quality results at a low cost, thy adopt the practice in hopes of valuable returns: Cargoism at it's finest! Someone did make a good sale to them, probably earning good money on all the training and coaching. Ask deeper.

1. Do managers loosen the reigns?
   Agile means giving power to those who need the power to succeed. A Command+Control structure is not only inherently inefficient, but it prohibits success. Maybe people can't do what is right because they still need management approval. In this case, management may proclaim a million times "We're Agile" - but at the same time, they're agility's biggest impediment!
2. Do people understand that Agile methods like Scrum don't solve any problems?
   Scrum, for instance, just makes problems visible. Did a real, genuine problem solving process get established? Are fundamental organizational issues resolved - or accepted?
3. Who really owns the products?
   Are people aware that Product Owners champion the product - but that the product really belongs to the team? Do developers take personal ownership of their work, are they proud of their contribution to the product, or are they delivering products just because it's their job? Do the teams even have what it takes to own their product, or do they rely on external patronage to deliver anything?
4. Who defines the development process?
   Do developers follow corporate governance or are they empowered to do what is right? Do they really care to do what is right - or do they prefer to have someone tell them? Do they not only care to do their job, but to do it well? Do they improve their working process because they see the need - or because the Scrum Master pushes them?
5. Do people realize Scrum Ceremonies are actually the wrong idea? Do they realize teams should not have to have:
1. Standups, as mentioned by Jame Shore. If everyone knows what we're doing, and the PO is continuously involved - the Standup will add no value.
2. Reviews. If the team were directly engaged with the customer either with direct collaboration or techniques like A/B testing, they wouldn't need to batch up for a week or two before getting things signed off. 
3. Retrospectives. If something is going wrong, why wait until the end of the sprint before bringing the issue up for improvement? That's insane! When you see that something is wrong, go fix it!

If you hold the firm belief that by rigorously applying the practices, you will become more Agile, you have already failed. Behind Agile, there is a spirit. This spirit is not visible, but it may be manifest in agile teams. If you do not lay hold of this spirit, all your efforts are doomed. You will not be successful.
"Copy the spirit, not the form", said Yoji Akao - and that is as true for Agile as it is for Quality Function Deployment.

Without the agile spirit, you'll be weaving Agile landing strips and donning Agile coconut headsets until your organization falters, but you won't receive the precious agile cargo, no matter how devotedly you worship Agile Cargoism.

Power to the Product Owner

We call the Product Owner "single wringable neck" of any agile project.
It's a good thing to have one person who is responsible for leading the product to success.

But what happens when you don't let the Product Owner lead the product to success?

The situation has been explored by many agilists, such as in this blog or in this presentation.

My team was tasked to deliver B2B Interface platform.
The team did the coding and got the solution tested. Then, we hit a brick wall: IT Operations.
The department was making issues with topics like firewall clearance, hardware, maintenance windows, capacity management and ... don't even ask. It wouldn't even be right to say that they were wrong with their reservations.
Anyways - we had a delivery date, we had potentially shippable software, but no server connected to the other side.

Long story short, when the CTO realized that this was endangering the product launch, he simply declared "Use whatever resources you need, you have complete control over the department's processes and priorities".
It didn't even take 2 days and the server was up and running!

Lesson Learned

It's not enough to have a PO who understands the product and grooms the backlog. The PO needs to have the full power to make the product successful.
If your organization brickwalls the success of the product with politics, structures or anything else, then don't strangle the PO for not delivering. You need to have a PO who can make the calls whenever necessary, whereever necessary.

Waterfall Kanban

Kanban is a very lean, efficient process for getting work done.
Since Kanban minimized Work in Progress and makes bottlenecks visible, I thought it would be a great way to increase the flexibility of our software development.
Years back in 2008, when I just went through Lean Six Sigma training, I saw Kanban and the first thing that came to my mind, "Let's try this!"

Setting up a Kanban board is easy.
Explaining the concept of Kanban is also easy.
So, we started.

Initially, we did really well:

• Breaking down the work into bite-sized portions made analysis, development and test significantly easier.
• The high visibility of which topic was currently at which stage of the development process made managing the product easier as well.
• Working on a pull principle significantly reduced the stress associated with large projects.
• Seeing multiple cards fly through the board from left to right, getting things done at a rapid pace, significantly improved team morale

So, Kanban was a big success.

However, a couple weeks down the line, problems did start to set in.

What went wrong?

We did Kanban in a classical Waterfall approach.

The swimlanes we had were no "toDo, Doing, Done", but rather:

"Open, Analysis, Development, Test, Done"

Intitially, this approach was fine. Until the stories got more complicated. Then, test simply bounced back defective stories to Development. Some stories even came back to Analysis, because underlying assumptions were disproven in test.

We ended up with a whole mumbojumbo where the Development swimlane was plastered with post-it's and analysis and test were idling.

Lesson Learned

You can only prevent a clutter of stories in an unfinished position if people don't have to idle while other stories are being processed by other people. If anyone needs to wait for someone else to finish, your Kanban setup is doomed!

If you want to be successful with Kanban, you must make sure that you have "T-Shaped People", so that the team can support each other as backlog items move through.

Ideally, you do Pair Programming and the same pair is responsible for the story end-to-end, eliminating unnecessary handovers. Make sure that everything required to successfully complete the story is available in the team: skills, tools, information, ownership.

Just get it done quickly - whatever "done" means ...

Imagine the following:

You go to a restaurant, order a Chicken Wings with fries ... and then wait.
When you finally ask the waiter, he says "Oh, your meal is ready. The cook already went home".

Bewildered, you go into the kitchen to find out that yes, indeed, your order has been processed. Somewhat. There are unspiced, half-baked chicken wings without spices in the oven - and some mash potatoes in the pot.

Which brings me to topic.

I was working for a client who had one developer working offshore. Because he wasn't part of the core team, he only had specific tasks assigned that could be completed stand-alone.

So, this one glorious Friday, he dropped an E-mail "Done. I'm off for 2 weeks of vacation" - and boarded an airplane right away to a different continent.
He had an assignment with customer impact and a clear deadline.
To our dismay, we discovered that there was no code commit. Maybe his mind was already on vacation, but still: we had an issue.
So, we called him as soon as his plane landed to discover he had simply forgotten to commit his code to the central repository.
He had to call a friend to come over to his house who, with detailed phone instructions, managed to commit the code after many hours.
And that's when things started to get funny. We couldn't even build the software successfully: He had taken the liberty of adjusting the core engine to suit his implementation of the solution!

Needless to say, there went the deadline.

Lessons Learned

There were so many things that went wrong here, I don't even know where to start.
And don't even get me started about hiring a single developer offshore to assist an onsite team: that was a business decision made by someone else.

First things first, it is a mindset thing: "Commit early, commit often". It should be habitual for every developer to commit more often than drinking coffee. We sometimes commit as often as 100 times per day in a small team of 3. If you see that someone isn't even committing daily, seriously - you have a process problem and risk losing work!

We didn't have any automated test coverage, so he thought he was doing fine. Especially when working in distributed teams, it is essential to have good unit and regression coverage, it creates a safety net for developers. We didn't have that, so we essentially created the environment where his mistake was possible!

Of course, offshore communication is difficult, but the problem here wasn't that he forgot to commit. The problem was that although we had some form of CI, he considered it "nothing out of the ordinary" to build the software locally to verify his implementation. Especially offshore teams, but every team, is well advised to have one single central Integration system, as the single point of truth by everyone on the team: If it doesn't integrate, it's not done. Regardless of how nicely it works on your own machine!