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.

One More Big Reason for Adopting BDD

picjumbo, larry apke, joel software, larry apke bdd, bdd adoption, agile, agile scrum

picjumbo, larry apke, joel software, larry apke bdd, bdd adoption, agile, agile scrum

I have always considered Joel on Software as one of the best bloggers on software development that exists.

I absolutely love his approach to software development and should he ever open an office west of the Mississippi I would be the first to send my resume!

While doing research on another blog topic, I came across his famous blog on the Netscape rewrite. As happens from time to time, a universal truth crashes into our consciousness causing a virtual cascade of neural connections to fire, providing in the instant the “Aha!” moment. It came to me as I read the profound truth that is “It’s harder to read code than to write it..”

I was blown away because while my post, 10 Reasons Why BDD Changes Everything, has some great reasons to adopt BDD, after reading Joel’s blog again (which I had done before and did not explicitly make the connection), I think I might have missed perhaps the most important reason for BDD.

So here’s one more reason, inspired by Joel, for adopting BDD, namely: If it is harder to read code than to write it, BDD provides a simple and concise method for making the code that we write frighteningly easy to read (especially when compared with how most code is currently written).

Over the last three plus years I have coached adoption of BDD at all of the companies I have consulted and have constantly asserted that a team (and the larger organization) cannot be agile over time (anyone can be agile over a short period) without adoption of some form of ATDD (my choice being BDD) and continuous integration / delivery.

I challenge anyone to change my mind with solid proof. So far only one inexperienced scrum master has even tried!

Conversely, the more I read from software development professionals whom I admire and trust (like Joel) the more I become convinced that my position is correct.

Tell me your thoughts.

Larry Apke

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”

Recommended Reading

Since I am often asked (and often offer without being asked) what books I have read that have helped me to better understand and implement Agile, I have created a page for recommended reading. This (and posting a new blog update) has been something I have wanted to do for some time so I wanted to make sure I got something up.

I will update this list from time to time as I find more books that I think are worth the effort.

Software Development is Like 30 Rock – A New Software Development Metaphor Part 2

Back in January I stressed the need to come up with some new metaphors regarding software development because our old metaphors were causing some problems. I still believe this to be true more than ever. Developers are not just cogs, but are individuals. Research has shown that the most productive developers are up to 10 times more productive than others (see Peopleware for more). You cannot just plug any developer into a product team and expect them to perform at the average level for that team. Domain knowledge counts as well.

However, one thing that I did not do a great job of was suggesting a replacement metaphor. The one I used was the film industry. While I was correct that development is a creative art, it has recently been pointed out to me that making motion pictures usually takes a great deal of upfront planning and design – not a good analogy for an Agile advocate. This misstatement showed that I knew less about the film industry than I do software development.

Continue reading “Software Development is Like 30 Rock – A New Software Development Metaphor Part 2”

Philosophy Versus Practice

When trying to get waterfall teams and organizations to move to a more Agile development methodology there are two training strategies – philosophy and practice.

The philosophical approach relies on teaching the history of software development and the philosophy behind Agile – the manifesto and principles. This approach assumes that as long as one is equipped with the proper overriding principles then one will be able to make the correct decisions as challenges occur.

The practice strategy relies heavily on training the ceremonies, especially scrum ceremonies like standups, retrospectives, reviews, etc. This approach assumes that if you do the rights things that overtime the reasons for the practices will become apparent.

Continue reading “Philosophy Versus Practice”