Everybody’s Doing Agile--Why Can’t We?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Have you gone Agile? What are you doing this year to become Agile? We must become Agile in the next three months! These days, it is not unusual to hear about executives wanting to do an “Agile Transformation” on the entire company. Who knew that a bunch of relatively obscure techies would create a movement that is now the lingua franca of executives who are attempting to turn around companies! Agile really has “come a long way, baby.”
It’s amazing how things change in ten years. Once considered a methodology preferred by software developers because it “helped them avoid having to do status reports,” Agile has now gone beyond its original remit as a software development method. The word Agile, in many places, has become nearly synonymous with the word Good. As flattering this must be to the original founders, it probably means it would be wise to think, very candidly, whether Agile—as in Agile Software Development, or a broader Agile Enterprise—is really something that your company can achieve.
Can You Handle The Truth?
There are generally two classes of managers. Those who want the truth, and those who say they want the truth, but get mad at anyone who communicates bad news. The less transparency is tolerated in a company, the less traction Agile will get. While there is no formal index to measure how transparent a given company is, there are a number of questions you can ask yourself:
- What happens if you miss the budget number this quarter?
- What happens if you miss the target number of points this iteration?
- What happens if a salesperson misses her quota?
If the answers to these questions are things like mandatory overtime, public scolding, demotions, or firings, you probably are not ready. If a company is really ready for Agile, a response to a miss generally will be to look for root causes. If, on the other hand, the reaction to a miss tends to be knee jerk blame and punishment, the company probably isn’t ready.
What happens when budget estimates of a project exceed what the sponsor wants to pay? In companies that are likely not ready for Agile, the response will be one of the following:
- Find a lower rate vendor who brings the budget inline
- Ask the estimators to just “lower the estimate”
- Ask what can be done with a lower level of quality
- Threaten to put the project out to “the lowest bidder”
Generally, in companies that are well suited to Agile, the answer will involve having adult conversations that involve scope management or some other real trade off. A key prerequisite for being Agile is having the ability to have this adult conversation. On the other hand, an organization that is willing to pit one group estimating in good faith versus another estimating in “price to win” mode (aka lying about price and making up the difference in change orders) is simply not ready to have these kinds of adult conversations.
Are Hubricists Tolerated?
In a prior article, I outlined a creature called the Hubricist. This is a person who seeks to advance his career by demonstrating confidence above all else, regardless of the actual circumstances at hand. The problems of the Hubricist involve lack of transparency, but go further, in that they create the ecosystem where transparency is punished in favor of confidence—above all else.
Hubricists are especially harmful in that, unless rooted out, presence of one spawns more Hubricists because they get involved in a confidence arms race. If manager A promises X in 3 months no matter what, it will not be long until manager B starts making similar kinds of promises, if only to keep up. Those who seek to be transparent become punished because they are unwilling to get involved in the bidding war. Needless to say, transparency suffers when these kinds of people exist in large numbers in an organization.
What Happens in Risk Management Meetings?
A good sign you are not ready for Agile is a lack of stomach when managing risks. In a healthy risk management meeting, a list of risks will be identified, and a strategy for the significant ones will be chosen. Sometimes, the risk will be accepted; other times, it might even be exploited as an opportunity. Risk reduction or mitigation is one of many possible strategies, when the conversation is an adult one.
Contrast that by the response in companies that are not ready for Agile. In such companies, the only reaction to a risk is doing whatever it takes to mitigate the risk. Such organizations tend to be culturally loss averse—despite any upside—and tend to lack the courage to truly do things differently. They will fold into command/control driven management the minute things do not go perfectly to plan.
Transparency Required!
If you want Agile, you must be willing to deal with things as they are, not as you want them to be. If you are in a culture that is averse to transparency, shoots the messenger, and is overly risk averse, you will not make the leap to Agile.
Are You Organized For Failure?
You can be a very transparent organization, but if you are organized badly, you will still have a great deal of difficulty making the leap to Agile. To understand this, we need to go back to the roots of Agile in the context of software development. In software development, we have user stories that represent a single unit of work that has real value to a customer. This enables the software developer to be empowered to bring value to a customer without having to cross an onerous set of organizational boundaries. Ideally, any single person in an organization is empowered to bring value to a customer in a truly Agile enterprise.
So how does the org chart affect this? In software, if you create an operations group who has goals that are too divergent from the goals of the software development group (or vice versa), yet they have to work with each other to get anything done, your organizational structure is working against agility. For example, imagine you have an operations group that has incentives purely around uptime, and a development group that has incentives purely around release frequency. Because more frequent deployment can create a perception of downtime risk (though perhaps not the reality!), you will likely have frequent and continuing conflict. Recognizing—and working to resolve—this common organizational defect is a large reason why the DevOps Movement and Continuous Delivery are gaining so much traction.
But this goes beyond software development. In many organizations, front line people are not empowered to solve even the smallest customer issues. How crazy is it that, when you call a cable company, you have to talk on the phone to a customer service representative’s supervisor to get, say, a five dollar refund on an errant charge? In others, the people who are closest to the work—say, line mechanics—have to ask for permission to some master industrial designer at headquarters to solve obvious problems on a shop floor. In general, if a company is organized in a way where people are designed to be plug-compatible units in some grand plan, you will have a very difficult time “going Agile,” at least without the requisite organization model changes.
Misuse of Metrics
Similar to how a bad organizational model hinders agility, bad metrics can have the same affect. One of the lauded things about metrics is the concept of “what gets measured gets done.” It just so happens, however, that one of the most dangerous things about metrics its evil twin, “what doesn’t get measured gets ignored in favor of what is being measured.”
It would be a mistake to take a position that all metrics are bad. When you boil them down, they are mere facts at our disposal that we can use as points of feedback. If you are a software developer, you want to know how often the build is being broken per day. The problem isn’t metrics; it is the misuse of metrics.
Let’s take a hypothetical example. Say that company X is going to give everyone a bonus if test coverage reaches 80% on a codebase. One might laudably believe that having good coverage is something that is desirable. The problem is if you bonus that metric, and ignore other metrics, you create a system that rewards bad behaviors. For example, it is quite easy to create unit tests that cover code, but do not assert anything around the correctness of that code. Such tests contribute to coverage, but do not contribute to business value. This is why you should not give bonuses to developers based on single metrics, be it coverage, lines of code produced, or any other single thing in isolation.
In the broader business world, we can see this as well. I have seen cases where consulting companies would pay a commission based on revenue, but would charge the project manager with making sure the engagement was profitable. As you would guess, the project managers frequently got assigned to flawed projects, because the salespeople were literally incented to push as much revenue through as possible, even if it resulted in negative margins. The PMs would get the deal, and almost always be fighting a losing battle, which resulted in massive drain of PM talent.
Metrics, when not carefully aligned, create behaviors that work against the creation of business value. They soak up any responsiveness an organization might have to the direction of the metric, rather than in the direction of the customer. Groups may have different metrics, creating reasons for them to work against each other, which works against the collaboration required to make Agile work.
But I Want To Be Agile! Can I Change?
Most of these problems—lack of transparency, misaligned organization model, and perverse metrics—tend to be part of the DNA of a company. I may be able to get contact lenses that change my eye color from blue to green for a day, but changing my DNA to produce a different eye color is an entirely different matter. Similarly, you can do the easy parts of Agile—daily stand-ups, story cards on a wall, and so forth—yet still not ever deliver software because others in the organization lack any incentive to push the new stuff to production. Indeed, changing the culture of a large organization is a very, very hard problem, one of which takes a lot of courage. The CEO who embarks on the effort to change her company to Agile must be willing to take some pretty serious risks, up to and including risking her own position at the top. This is not the kind of thing for the faint of heart!
Yet, ironically, the impetus to change stares us in the face every day. There are few companies that have such a strong competitive position where they can afford not to go Agile. The business landscape is littered with the carcasses of companies that could not change faster than their competitors (think Borders, Circuit City, and Linens n’ Things),. I recently witnessed one company President tell his company, in no uncertain terms, to Change or Die. Such a bold statement may not be true for your business, this year. But rest assured, at some point, unless you have either no customers or no competition, it likely will be!