Posted on

Hit Rock Bottom? Maybe Now You’re Ready for Agile

Despair

Despair One of the things I enjoy most about my work is meeting other Agile practitioners and coaches and sharing war stories. Recently I was at an Agile Coffee with people who had various experience with Agile, ranging from complete neophytes to folks with many years of experience. The topic chosen was “What are the preconditions for a large company to be successful implementing Agile?” – a very pointed, yet valid, question to be sure. All of the answers were ones that one might expect; support from upper management, learning culture, etc. except for one. The lone unobvious answer was provided by someone whose opinion I respect. I was somewhat surprised at the time and it has reverberated in my mind ever since, “one precondition for a company to be successful in an Agile transformation is they have failed miserably and have hit rock bottom.”

The term “rock bottom” is most commonly used by folks in NA and AA (Narcotics Anonymous and Alcoholics Anonymous). I found the following definition of rock bottom on a website for alcohol addiction:

… often used to describe a point … when they are finally willing to seek help. Things are now so bad for them that it is impossible to deny their problem anymore. Hitting rock bottom may result due to a particular event, or it can be a slow decline over time. This is a subjective term because some … will be willing to suffer a lot more … than others.

I first came in contact with Anonymous groups through my work in healthcare (nearly a lifetime ago when I was a licensed Health Care Administrator) and have more than one commented on how Agile transformations remind me of some of the twelve steps – with the first step being to admit one has a problem.

So when my friend mentioned that a good indicator for agile transformation success was a company had hit rock bottom I knew exactly what he was referring to. In this particular case he used the examples of the FBI Sentinel Project and Healthcare.gov website debacle. In both cases, it wasn’t until each was a total disaster that Agile was actually tried with any seriousness and rigor and in both cases the results were amazing.

The total spend of these [two] failed [Waterfall] attempts to replace the ACS system was $597m and wasted 10 years. The Agile project, which is now delivering a solution, will only cost $114m for a three-year long project.

DespairIn another recent talk I went to on Agile a gentleman explained how Agile helped with an ad agency. He was only brought in AFTER the agency blew millions on a website that never made it to production. After losing millions I would guess this agency hit “rock bottom”. The good news was that Agile was able to help them to change and allowed them to produce high quality software with a much better time to market (than never).

In my agile coaching practice I have had more than one conversation with enlightened management that has acknowledged our Agile transformation wasn’t working as good as hoped and, barring a complete meltdown, most folks were happy to continue along a non-optimal path. In fact, relative success is a particularly sticky barrier to change as people often confuse the ability to get something done with the ability to get something done optimally. Bill Gates has often remarked, “Success is a lousy teacher. It seduces smart people into thinking they can’t lose.” Sometimes what we mistakenly call “failure” is a much better teacher. Sometimes the lesson is more important than the perception of relative success or failure.

Just this morning I was listening to my local NPR station as they were having a fund drive. Like many others, I couldn’t wait for the drive to be over so I could no longer had to feel the shame and guilt of being a “free rider”. Fortunately, it was the last day of the pledge drive and my mind was only half listening to the chatter of the announcers when they introduced Shankar Vedantam who does segments on the Hidden Brain (which I enjoy immensely). His topic was why people donate (or don’t donate) to pledge drives. He talked about humans’ tendency to pay more attention to emergencies and crisis than what is important. Being the last day of the pledge he hoped what was merely important (donating) would now also be given the status of an emergency because time was running out.

DespairMy mind went immediately back to the concept of “rock bottom” and why this is one good indicator of where Agile can be successful. Sometimes it is only when we hit rock bottom that the importance of being Agile begins to align with the immediate crisis of having to be Agile. It is then, and unfortunately for some, only then when Agile gets the attention and focus it deserves. It is my hope companies realize becoming an Agile organization is essential to their long term survival (at least in organizations that rely heavily on software development), seek the help they need to transition and actually carry out the transition before they hit rock bottom. In the meantime, if you have hit rock bottom (are you listening Yahoo!?), please seek out Agile help.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

Real World Agile Q&A

question

One of the joys of being an Agile Coach is that it is a passion and a calling that doesn’t end at 5pm. Frequently I have the pleasure of staying in contact with individuals who I have worked with via phone and email. With the permission of a good friend, and changing a few details to render our exchange more generic, I present our latest exchange in hopes that people will find it helpful or at least interesting.

 Larry,

I keep reading your articles and really enjoy the insight you continue to bring to the Agile world. I’m particularly stuck with a situation here at my current employer.

questionWe’ve organized a scrum team that has done a fantastic job pushing out working, quality software since we started 10 weeks ago. However, this team primarily has worked on our website, but as I see it, we are bringing all of our development work to the team. Consequently, we are about to kick off work for redesigning our Intranet. This too falls into the team’s backlog, but now my business contact is pushing back, saying her backlog for Internet is separate and she doesn’t want to have to prioritize her work including the Intranet. I don’t have the luxury of just adding more developers to an additional team.

What tactics would you use to approach solving this? It’s a fragile situation. Your thoughts?

 

My response:

Thanks for the kind words. My first thought is a question – how many people are on the team? If you have enough, I would float the idea of splitting the team. The rule of thumb is one or more teams per backlog. What your proxy PO is doing is to (perhaps arbitrarily) split one backlog into two. One team cannot really service multiple POs or multiple backlogs. This way you can give the PO a choice – work with me to understand resources are limited, work with me to value all of the work for the team (not just your work) and then sequence the work so that the entire company is getting the benefit of a stable, focused agile scrum team.

question marksThat said, the real root of your problem might be that you really don’t have a product owner in the classic sense. Perhaps you would be well served to find someone who could represent a full backlog, especially if your team is too small to split as outlined above. I would suggest that all stories on your backlog should have both effort (in points) and value. Perhaps the best way to achieve your story value is to have your people compute the cost of delay (COD) for each item. You can then show all the work of the team with respect to value/effort to get an idea of which items to sequence first. If you find stories too granular to perform COD, group them (call them Epics, Themes, etc). Though I don’t recommend wholesale use of SAFe in your case, I would recommend that you have your folks look into concepts like COD and WSJF (Weighted Shortest Job First) that SAFe describes fairly well. Donald G. Reinertsen further elucidates these ideas in the book The Principles of Product Development Flow.

If you cannot get a different PO who can oversee more than just their parochial concerns and you cannot split the team in a way to service the two different products you are working on then your options become even more limited. My next question would be to ask who is in charge of your Agile effort? One of the reasons I have proposed the concept of CAO (Chief Agile Officer) is for situations such as these where someone at the top level of the organization can arbitrate using the entire organizational as a lens to determine best courses of action. It sounds like you are both on the same organizational level so it would help to appeal to a higher management level in instances where two of the same level cannot come to a satisfactory conclusion. Obviously this is a last resort in that people involved tend to react negatively to people “going over their heads.”

I wish you all the best, hope that you are able to resolve this situation and that my advice will prove valuable, and if not so, will at least not result in a negative outcome.

In the end, my friend decided to split the team into two smaller teams. Maybe in a later blog I can follow up to see how well this tactic worked.

Posted on

Too Many Bright Shiny Objects (BSOs)

 

As an Agile Coach who has worked at his fair share of large companies, I spend a lot of time researching what can go wrong with an Agile transition. One of the things that I don’t recall being mentioned is the sheer number of projects that some companies try to run concurrently. I have actually worked at more than one company that bragged about how many projects they were able to juggle at one time. These organizations are great at starting work, but very poor at delivering work as if there were some kind of incentive for the number of projects started versus the number delivered. Unfortunately, this is often the case with companies measuring and paying bonuses based on the number of projects they are working on as opposed to how many actually deliver any value.

The problem is huge and is a confluence of some very bad management decisions and assumptions – management deciding there is value in chasing every opportunity (every bright shiny object – BSO), management assuming that people can effectively work multiple projects (for instance, someone on four projects can be 25% effective on each one) and management obsessively making sure that everyone is 100% busy 100% of the time.

The truth of the situation is that most BSOs are not very valuable. Studies have shown that 64% of software features are “rarely or never used”. This would seem to me to open up the opportunity to slim down the number of concurrent projects to just those that would be used and would provide the most “bang for the buck.” This is something that truly Agile organizations understand, but doesn’t get much press. Perhaps if we stop trying to be everything to everybody then we could focus our efforts on those things truly important. What is the point of instituting the discipline necessary for agile software development if we don’t exhibit the same discipline when choosing what to develop? In other words, building the wrong things right is almost as bad as building the right things wrong.

The next problem is that people are treated like widgets. I had one VP once mention in a meeting that “developers are a commodity that I can snap my fingers and replace at a moment’s notice anywhere in the world.” Not true. People are not widgets or commodities, especially in software development where the productivity of a single developer can be as much as 10x higher than another (even when adjusted for education and experience). Try to get that with a factory worker or brick layer. The truth is that when you pull people in too many directions that their productivity decreases due to increased communication overhead and context shifting. It is even more pronounced in an “Agile” transformation. It doesn’t take a rocket scientist to note that a person on three projects (and three project teams) would need to attend three times as many standups, reviews, retrospectives, etc.

Lastly, organizations seem obsessed with making sure that everyone is 100% billable to projects. In order to be 100% billable this means that someone must take on more work and projects than they can concentrate effectively on. The number of people who literally brag about how busy they are is astounding, as if there were some value in not being able to effectively plan one’s time to be effective as opposed to just busy. It is not the individuals fault; they are merely following the lead of the organization that tracks hours. God forbid someone is not 100% busy because they could be next on the chopping block. And mark my words; companies that track such things will always be going through some kind of employment convulsion from time to time if for no other reason than companies that are not effective are more vulnerable to market changes (why they thirst for agile in the first place, but they never make the changes that would allow them to drink). 100% busyness results in queues, in work waiting. We brag about keeping someone 100% busy – why not brag about keeping our computer CPUs at 100%? Because it is ludicrous. As Demarco aptly points out in his book Slack, efficiency is the enemy of effectiveness and it is about availability not busyness.

As I have stated many times before, the problem of chasing BSOs is that the people in charge of making decisions about software development simply have no clue what software development is all about and what works. Running too many projects concurrently is a sure way to never deliver anything. If you want to be effective delivering, instead of just looking busy, cut down the absolute number of projects you are currently implanting. The results will astound.

In “Getting the Most out of Your Product Development Process”, Adler studied a dozen companies over 8 years, including Raychem, Motorola, Harley-Davidson, Hewlett-Packard, General Electric, AT&T, Ford, General Motors and NEC. Their conclusions:

First, projects get done faster if the organization takes on fewer at a time. Second, investments to relieve bottlenecks yield disproportionately large time-to-market benefits. Third, eliminating unnecessary variation in workloads and work processes eliminates distractions and delays, thereby freeing up the organization to focus on the creative parts of the task. The result: Business units that embraced this approach reduced their average development times by 30% to 50%.

 Ever wonder why coaches always harp on small, co-located, dedicated and stable team? Now you know. They do it because it simply works better.

Want to be Agile? Reduce your number of concurrent projects and replace this approach with small, co-located, dedicated team and see a reduction in development times by 30-50%. More importantly, when people are able to focus the quality of the work increases tremendously, allowing for better and faster delivery in the future.

Posted on

Apke’s Law

Most of my 7+ years of Agile coaching and scrum mastering has been working with existing waterfall organizations and helping them become more agile. During this period I have seen a wide range of companies and a wide range of successful adoption, but I have noticed one thing that is constant. This was brought home recently as I reflect on my most recent agile presentation/discussion given at Geekdom in San Antonio last week.

In this Agile open forum the majority of the questions dealt with transitioning from waterfall to agile. This is where I first publicly broached Apke’s law which states:

Your transition to agile will only go as far as the highest ranking manager who understands and supports it.

Continue reading “Apke’s Law”

Posted on

The Reason Your Agile Implementation will Fail

I have had the good fortune of managing Agile (scrum) implementations at a number of different companies over the years. I have had some great success and some implementations that were not so great. While not unique, my experience is such that I have enough data points to start seeing patterns, especially patterns of failure. That is, while I cannot confidently tell you what will most certainly work in your particular situation, I am eminently qualified to tell you what will not work.

Continue reading “The Reason Your Agile Implementation will Fail”

Posted on

Trust and Agile

I had the wonderful opportunity to have a panel discussion recently regarding Agile. In my warped world, there is no greater pleasure than getting grilled on how Agile can be implemented in the real world. As such conversations are wont to do, a consistent theme emerged. In this particular conversation it was all about Trust.

If someone asked me to pick one word that could be used to describe a low functional Agile team versus a high functioning team, there are two words that come to mind – Discipline and Trust. Of these trust is probably the most important in that it can be hard to acquire, difficult to keep and easy to lose. As a scrum master, my team has to trust that I have their best interests in mind at all times, that the metrics I compile will never be used to punish them. They need to trust each other to be able to commit to a body of work for any particular sprint, etc.

Continue reading “Trust and Agile”