How I Know You Are Flailing at Agile

As a consultant I try my best to keep abreast of industry trends in technology and software development. Often one of the best ways to observe trends is to check out job boards to see what positions are being posted. For example, job postings can show trends in programming languages. You can see which companies are trying to make Agile transformations (How many big financial companies can hire multiple coaches in Foster City?). You can see which companies have caught the “DevOps” bug and you can tell which companies are flailing and failing their Agile transformations.

How can I tell which companies are failing? When you see multiple posts for the same position over time is a good indicator. For example, you see a post for an Agile Coach that goes unfilled for months. While good ones can be hard to find and take some time, a position open for months can be telling that good coaches are avoiding the company. Most good coaches can very quickly size up a company’s commitment to Agile and avoid those situations where they are likely to fail no matter how good a coach they are. They can sense the fundamental dysfunction. Sometimes you will see a posting one day and the same posting a few short months later. Chances are whoever was chosen didn’t last and that certainly raises red flags.

Sometimes the title that is advertised will show a company’s inherent failure to grasp Agile. You will see a ton of advertisements for Scrum Master or Project Manager. I personally love these as they serve the same purpose as someone wearing a “Stupid” sign in that we know to avoid both. Advertising for a Scrum Master or Project Manager indicates that the company searching understands neither position. The good thing is that if one is only interested in doing Agile then one can save time by avoiding these.

Once I drove nearly two hours for an interview with a company that does only “Agile” projects. During one of the many lengthy interviews, I was asked, “What would happen if we gave you a waterfall project?” “Well for one thing you would not be 100 percent Agile anymore.”

The interview went downhill from there – a waste of a lot of people’s time. Advertising for a Scrum Project Manager would have saved everyone!

Lately I have been seeing another title that gives me pause – Technical Project Manager, especially in the context of Agile companies. I have been a part of and witnessed many abject failures of software development projects (maybe why Project Management should be replaced by Product Management). On none of these have I ever thought that maybe, just maybe, if we had a Project Manager that had more technical knowledge we would have snatched victory tron the jaws of defeat. And the colleagues I talk to agree.

Project Managers have the least amount of authority in making projects successful. A Technical Project Manager is kind of like blaming the weatherman for the rain. It is a silly tactic by management to deflect blame from them. Agile transformation is difficult because it needs change from management and change of culture. Hiring Technical Project Managers is a red herring that distracts an organization from the real work to be done, pushing the transformation finish line even farther away. And finding the kind of person who can successfully straddle tech and management is a tall order, especially when people who know what Agile transformations are all about and who will see through you and realize you are merely flailing at Agile.

Larry Apke

Managers from Hell and Agile Transformation

larry apke, whiteboard, agile

larry apke, whiteboard, agile

“Here’s something they’ll probably never teach you in business school: The single biggest decision you make in your job — bigger than all of the rest — is who you name manager. When you name the wrong person manager, nothing fixes that bad decision. Not compensation, not benefits — nothing.”

Jim Clifton, Chairman and CEO, Gallup – State of the American Workplace

A few months back I stumbled onto some research done by Gallup on employee engagement quoted from above. I would like to say that their findings were shocking, but having been an Agile Coach at many large organizations, I find the statistics (and conclusions based on the statistics) to track quite close to my own experiences.

For example, Gallup found that only 30% of all employees in the United States are “engaged and inspired at work” and about 20% are what have been defined as “actively disengaged” employees who “aren’t just unhappy at work; they’re busy acting out their unhappiness. Every day, these workers undermine what their engaged coworkers accomplish.” The remaining 1 out 2 workers are defined as “not engaged” and “essentially ‘checked out.’ They’re sleepwalking through their workday, putting time — but not energy or passion — into their work.”

And take a wild guess what the number one indicator of employee engagement is. You got it – their manager. In another article, Gallup estimates that “companies fail to choose the candidate with the right talent for the job 82% of the time” (Why Great Managers Are So Rare). In other words, next time you are in a meeting with five managers, it is safe to assume that only one (maybe two) were the result of good hiring decisions. If you are a good manager meeting with other managers chances are good that everyone you are speaking with was the result of a poor hiring decision!

The fact that management hiring decisions are so poor should be of some comfort to you the next time you are passed over for the management job you know you can do well, but is little comfort to active agile coaches like myself who are actively trying to help a company get agile and stay agile. On the other hand, knowing this goes a long way in explaining why most companies have so much trouble with the transformation.

Without the support of managers, lasting agile transformation will not occur. The fact that the bulk of your managers are poor leaders just makes it that much harder. Gallup estimates that only 1 in 5 current managers have the abilities to “naturally engage team members and customers, retain top performers, and sustain a culture of high productivity.” Agile is all about engagement. It demands leaders who can engage developers.

So you say you want to be agile? Why don’t you start with hiring better managers? Stop relying on third-party vendors to find your talent. Grow your talent. Recruit your own talent. Find CIOs, VPs, Directors, Managers, Coaches who understand agile, can truly lead agile teams and engage developers.

Go ahead. I’ll be waiting for your call. Of course, it may be a long wait.

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.

How Would You Rate Your Organization?

larry apke, devops, cultural shift, agile doctor, software development

larry apke, devops, cultural shift, agile doctor, software development

While browsing the 2014 State of DevOps Report, the authors referred to a study by a Professor Westrum of Eastern Michigan University called A Typology of Organizational Cultures. In this article, Westrum studied the flow of safety information within hospitals, how that flow could be classified into an organizational typology and what effect that typology had on organizational safety. His conclusion was that:

“Because information flow is both influential and also indicative of other aspects of culture, it can be used to predict how organizations or parts of them will behave when signs of trouble arise. From case studies and some systematic research it appears that information culture is indeed associated with error reporting and with performance, including safety.”

The table below summarizes Westrums types:

Pathological

Bureaucratic

Generative

Power Oriented

Rule Oriented

Performance Oriented

Low cooperation

Modest cooperation

High cooperation

Messengers shot

Messengers neglected

Messengers trained

Responsibilities shirked

Narrow responsibilities

Risks are shared

Bridging discouraged

Bridging tolerated

Bridging encouraged

Failure leads to scapegoating

Failure leads to justice

Failure leads to inquiry

Novelty crushed

Novelty leads to problems

Novelty implemented

In the DevOps Report, they tracked the ability to be successful with DevOps to the three organizational types Westrum mentions: Pathological, Bureaucratic and Generative.

They found, unsurprisingly I might add, that the ability to successfully transition to a DevOps culture was tied to the organizational culture, with the most success seen by Generative organizations.

 “DevOps” is now the new buzzword, but the 2014 State of DevOps Report (and Westrum’s typology) reinforce that DevOps is clearly a cultural shift and that large organizations, which tend to be pathological as a rule (with some of the more noble ones merely bureaucratic) will only implement “DevOps” in name only or as a repackaging of the existing operational silo.

While the authors of the DevOps Report tied Westrum’s typology to DevOps implementation, the relationship between culture and a larger organizational adoption of Agile are crystal (pun intended) clear. I would go so far to say that in my extensive experience with organizational transitions to Agile that until the issues of culture are addressed by upper management (by a C-Level Executive – perhaps a CAO) then even attempting to make an Agile transition is not only destined to fail, but more than likely, fail in spectacular fashion.

At issue is not whether you can get some short term gains at the team level, but that without cultural support, whatever gains made will be unsustainable.

In my experience there are a few things likely to happen:

  • First, you will optimize the team at the expense of the system. There is little benefit to creating code faster if it cannot be deployed (hence the new DevOps push).
  • Second, you will optimize team speed at the expense of quality. In Pathological and Bureaucratic organizations the shift to quality is unlikely to be embraced so creating features faster only increases technical debt faster.
  • Third, as the novelty of the Agile implementation fades (think Hawthorne effect), what you are left with is a group of individuals who are increasingly disgruntled by the consistent failure of the larger organization and upper management to remove even the most fundamental impediments. What’s the point of showing people a better way to create software and then not allowing those people to actually do it? It is at best incompetent and at worst borderline criminal.

I suspect that a great deal of the backlash Agile has received of late is directly tied to Pathological and Bureaucratic late adopters flailing at a transition to Agile.

My advice? Ask yourself, or, better yet, ask your employees to honestly rate your organization with regards to Westrum’s typology

If you are identified as Pathological or Bureaucratic, address your culture issues first before embarking on Agile transformation.

Agile coaches can help if they are allowed to work directly with upper management to help them to change the culture, but having them work directly with teams (without addressing culture) is like sowing seeds on a footpath.

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”

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”