Posted on

The Theory of Change & Why I Get In Trouble

organizational antibodies, agile, stock photo

organizational antibodies, agile, stock photo

As an agile coach that has been fortunate to work at a good number of clients over the years, you get an opportunity to experience some interesting similarities among clients. Some are tragic, some are funny and some are just downright intriguing. I recently spoke with another agile coach and I discovered one particular pattern that I have decided to refer to as organizational antibodies.

The talk in question was about the on boarding of coaches and things a coach tends to experience in the first few days on the ion. As we talked together and related our war stories I noticed that both of us had a something happen to both of us early in our engagements with companies. That common denominator was that both of us found ourselves in trouble with management in the new company within the first week or two of our gigs with our coaching ability or competence questioned or tested.

To hear that others shared my knack for getting into hot water early on was a relief to me. Of course, all of these early issues were resolved in short order, but it brought up a very interesting question of why this happened so frequently. As I look back on my personal experiences and after hearing the same from my colleague, a theory began to form in my mind. The end result is my Organizational Antibody Theory of Change.

The theory is this – there are many in any company who benefit from the status quo. Agile is about organizational change and those who prefer the status quo will find the agent of change as a threat to the corpus organizationus and will do their best to protect their system by attacking the agent of change. In other words, there are people in your company that perform the same role that antibodies provide in the human body.

At this point in my career I fully expect to have at least one of these reactions in every gig I start within the first couple of weeks. In the past it was quite disconcerting for me but now that I have experienced it and expect it, I worry less. The problem is always a tempest in a teapot, a minor annoyance that will fade away as my role is better understood and people realize that I am not a threat. Have you ever experienced organizational antibodies before?

Posted on

The Gang of Four – How Optimization Perseveres

room, lights, black and white

room, lights, black and white

It must be the new year that has me waxing nostalgic again. My last post was of rockstars past and while I was working on that on that one I was also reminded of some others I had a great affection for, a group that I was a part of we called the “Gang of Four”. This was a tongue in cheek nod to the Gang of Four who were authors of a book on design patterns.

The impetus for the Gang of Four was the desire of four agilists to try to do the right things with regards to implementing agile and scrum – to do things that were generally acknowledged as good agile practices but things that were not necessarily politically palatable. In other words, we were something of a clandestine organization. In fact, our meetings, while not in a secret location, were held in a location well off the beaten path – so much so that some of us had to literally walk 15 minutes to get to our meeting room. Over time we added another like-minded individual but kept the original name. Hell, we even had a ironic salute we would give to each other when we would pass in the hall. It was in the company of these wonderfully dedicated people that I spent the most enjoyable time I had on this gig.

What is important and pertinent to this blog is not the nostalgia or shout out to my compadres (though it pleases me to think they might read this and reflect with happiness), but that regardless of your office politics, your cronyism, your brown-nosing, your ladder climbing or your sheer incompetence and general ineptness, there will always (or rather you should hope there to always) be those who will have the uncompromising desire to succeed in spite of your inanity.

Like a tree whose roots will break rocks in order to drink of the water that sustains it, there will be individuals and teams in your company that will persevere against the all odds to do what is right, to do what is best for the company. Seek these out and when you find them give them the environment that they need because if they survive on rocky soil just imagine what they can do on a proper plot of earth.

Long live the Gang of Four.

Posted on

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

Posted on

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.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

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