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

Why Agile is Leadership & Waterfall is Management

larry apke, agile doctor, agile, waterfall

larry apke, agile doctor, agile, waterfall

As an agile coach who has had the wonderful opportunity to work with many diverse companies in many different fields, I can attest that one of the benefits of having a coach is having a wealth of experiences from which to draw upon and over time we are able to notice patterns even among disparate companies. Some are rather obvious, like the inability for organizations to understand the difference between project and product management or that agile is an organizational change, not just an IT change.

Nevertheless, there are some patterns which are sometimes less obvious (or at least I have been more oblivious to) or that seem to take longer to identify.

Recently I had an, “Aha!” moment when looking back on my prior experience which has led me to coin a brand new axiom – agile is about leadership, waterfall is about management.

Like all things obvious after the fact, when this finally dawned on me I felt silly that I had not noticed the distinction before – duh, of course you say! However, the distinction is subtle so, in my defense, please don’t judge me too harshly.

The realization has been fermenting for some time, but it struck home recently when I was discussing issues around organizations transitioning from waterfall to agile with a colleague of mine. The trend I was referring to was the fact that nearly every agile transformation that he and I have worked have been initiatives from the project management office.

While a transition from the PMO can be successful, the very fact that the PMO is more about management (in most organizations), that even having the word “management” right there in the middle presents organizations with inherent challenges. The PMO is about top down, command and control. Should a scrum team actually have self organization, usually in spite of the top down PMO, and find something that works well for their team, the PMO usually pounces on this innovation, desperately solidifying it as a “best practice” for every team in their command.

I remember one innovative coach who used trophies to recognize agile excellence for their team. It was appropriate to that team and worked well for that team. This is an excellent example of leadership (and a self-organizing team). Unfortunately management happened to attend one of these trophy presentation ceremonies.

What was management’s response? “Wow this is great! Let’s buy a bunch of trophies and make every single team do this going forward!”

Unfortunately, this type of top down management is what PMOs are used to and comfortable with. This is one example of why PMO-led agile transformations are so challenged. The urge to manage (waterfall is about management), as opposed to allowing teams to self-manage (agile is about leadership), is in the DNA of most PMOs (and most organizations).

This mentality is easy to find. All you need to do is to gauge the amount of fear in the organization. The more fear, the less leadership. Is CYA the order of the day? Don’t expect your agile transformation to go smoothly, but CYA is the hallmark of management.

Avoidance of failure is not the same thing as success. Avoidance of failure and the concomitant avoidance of blame is the realm of management. Pursuit of excellence and success is the realm of leaders. Is your agile transformation not going well or you are not receiving the benefits you expected?

Stop trying to manage and lead. Stop using managers and start using leaders. Move the transformation from management silo into the realm of organizational leadership. Perhaps you should appoint a Chief Agile Officer.

Remember at all times – agile is about leadership, waterfall is about management.

– Larry Apke

Posted on

The Night Sky and the Tea Koan

As a coach, there are a number of stories that I usually talk about to my new teams to help them understand what my job is all about.

One I like to use with teams that think they already know agile is one I call “the night sky” which I based on my own personal experience. It goes something like this; when I was a kid growing up in the suburbs, I frequently played games outside with my friends at night. Sometimes we would look up at the sky and try to identify those constellations we knew. Most often we found the big and little dipper, but our limited knowledge (and limited view) allowed for little else. Nevertheless, to me this was the night sky.

Continue reading “The Night Sky and the Tea Koan”

Posted on

Thoughts on Agile Coaching

When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.

Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.

Continue reading “Thoughts on Agile Coaching”

Posted on

It’s Time for Companies to Add Agile to C-Level

larry apke agile doctor chief agile officer

larry apke agile doctor chief agile officer

The more companies, teams and C-level employees that I work with (and I have had the good fortune to work with many), the more I am convinced that implementing Agile can only go as far as the highest knowledgeable company officer who is supporting it.

What we need are some Chief Agile Officers – CAOs.

As an example, I had one consulting job to implement Agile within a team using Scrum framework after numerous internal attempts had failed. While I was able to move them closer to agility, it did not take long (as happens during an Agile transformation) to have it dawn on me what, or who, the problem was. It just so happened that this particular team had a Vice President that played the role of Product Owner.

So, in short, this VP had limited understanding and buy in for the scrum process, therefore we hit the ceiling at the VP level. Bringing a team into the Agile methodology is not that simple, so yes, there will be problems if someone does not thoroughly understand the process.

On another transition we had a Director and VP of Software Development who had different viewpoints on Agility (both correct on some points and incorrect on others by my calculation) and continually undermined each other in that no lasting tactical decisions could be made. To add to the confusion was a strong operations department that did not want to play with others in the Agile world. While the Chief Technology Officer gave verbal support to Agile processes, he proved unable to referee his immediate subordinates successfully and the Agile implementation languished.

And what both of these experiences have taught me is that Agile is about a great deal of things, but is primarily about organizational change around a philosophy. In order for it to work, there needs to not only be support from the highest levels, but a deep understanding of what it takes to be Agile. This means that someone needs to be at the C-level to make sure there are sufficient resources and that conflicts can be resolved.

Essentially, everyone needs to be on the Agile train. Otherwise, they are getting left at the station.

Also one of the reasons that Agile works so well with small companies is that the people in power know Agile and how to harness it for effective change. Decisions that need to be made to change systems are done efficiently.

One of the reasons that Agile has floundered at many large organizations is that it runs into resistance at some level in the organization. Once it hits this “glass ceiling” it needs the proper support from the next level of the organization to clear impediments. In many cases some Agility can be achieved but for the most effective change, impediments must be removed for the entire organization. The only folks with that kind of clout are at the C-level.

Therefore, it is my contention that you will begin to see a new position emerge – that of Chief Agile Officer – along with all the power this position needs to ensure better Agile implementations.

And for those organizations ready for this radical change, I am ready to report for duty.

– Larry Apke

Posted on

Drive: The Surprising Truth About What Motivates Us and Why Agile Works

In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”

People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.

As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.

Continue reading “Drive: The Surprising Truth About What Motivates Us and Why Agile Works”