Join Your Peers at an Agile Governance or Budgeting Event In October

October is normally a heads-down month. In addition to being in the home stretch of meeting our yearly objectives, we must dedicate cycles to shaping, communicating and justifying our plans for next year.

October is also a busy month for information sharing. The thoughts and ideas that have percolated through the year reach their maturity about this time, and we want to share them before everybody goes on their winter holidays. ThoughtWorks has no shortage of events coming up, and I am privileged to be a part of many of them.

If you’re in Chicago on Tuesday October 20, ThoughtWorks is hosting a panel discussion on the Budgeting and Financial Implications of Agile. On the panel are experienced IT leaders who head strategy, portfolio management and application development for their respective businesses. They've come to terms with balancing short-term operational flexibility with long-range budget forecasting. Stop by the Aon Center at noon if you can, but please register before you do.

Our first webinar in the Agile PMO series, Real Time Metrics, was very well received. We’re pleased to present Real Time Governance, a follow-on webinar that extends the concepts to their next stage of evolution. I’ve had the opportunity to present the Governance material with my ThoughtWorks colleagues Jane Robarts and David Leigh-Fellows in Calgary, Toronto (which was recorded and is available on InfoQ) and San Francisco. We’re broadcasting this next as a webinar with a full Q&A session on Thursday, October 22nd. The response has again been very enthusiastic, but with virtual seating at a webinar there are unlimited spaces, so please feel free to register and attend.

Members of the Project Portfolio Management Professionals association attended our Real Time Governance presentation in San Francisco last month and invited us to present it to their membership. I’ll be presenting to the PPMP via webinar on Friday, 23 October. If you are an IT leader with project portfolio management responsibility today, I strongly encourage you to look into this association. Take a look at their website or reach out directly to them for an invitation.

If you’re in Dallas on the 27th, I’m hosting an executive roundtable on Financing and Budgeting Agile projects. ThoughtWorks hosted a similar event in Chicago back in August. The people who attended that event have self-organized a micro-community. We’ve had a follow-on event and lots of peer-to-peer conversations as we mutually educate and collaborate on the unique funding and forecasting challenges and opportunities presented by Agile. Reach out to me directly if you're interested in attending the Dallas roundtable.

Finally, ThoughtWorks is sponsoring Agile East at the end of October in Philadelphia on the 29th and New York on the 30th. We have a powerhouse lineup of experienced, thoughtful practitioners, including Martin Fowler, Graham Brooks, Premanand Chandrasekharan, Carl Ververs, Joe Zenevitch, Shyam Mohan, Greg Reiser, Andy Slocum, Tiffany Lentz, Manu Tandon and Alla Zollers. This is an outstanding group of people and I’m humbled to be a presenter among them. I’ll be giving the noon keynote on Budgeting and Financial implications of Agile. Specifically, I'll be looking at how Lean and Agile allow us to maximize capex but require us to be extraordinarily diligent to prevent the perfect storm that can create an IT liquidity - and potentially IT solvency - crisis. I can’t stress enough what a stacked lineup of people this is. Make plans to be in Philadelphia or New York at the end of the month, just be sure to register.

Restructuring IT: The Detroitification of IT

In previous installments of this series on restructuring IT, we looked at how IT has adopted industrial practices as it has gone in pursuit of scale. As a result, IT bears striking resemblance to Detroit automakers. Let's look at some common characteristics.

Sub-Optimal Quality

Detroit suffers its periodic crises of quality. There was a joke that made the rounds during the 1970s that you know you have an American car when you get the factory recall notice in the mail. In much the same way, industrial IT is notorious for low technical quality of what it produces.

Long Time-to-Market

Detroit has excessively long product development times. It takes years to go from idea to availability. Former Chrysler CEO Lee Iacocca famously went on a tirade when he wanted to see what the LeBaron would look like as a convertible. His design manager told him something to the effect that they first needed to do a scale model, then a wind tunnel, then the prototype, so they’d have it for him in about 6 months. Iacocca’s reply? “Just take a chain saw to the roof!” How many CEOs look at their IT department and ask, “why is it so hard to get anything done in IT?”

Too Much Leverage

Detroit got by for so long because it could “pull demand forward.” Very few people pay cash for their cars. Instead, they finance their purchases. They're buying a car based on future earnings, not on their accumulated savings. Think about what happens in industrial IT, in terms of capability. There’s far less supply of “bankable capability” than there is demand. Instead, the industrial IT model looks for capacity. It puts people new to the IT industry in a position to put code on the line, learning as they go along. In effect, the industrial IT model borrows against future capability development. There’s even a few firms that have bet their entire business on this model.

As my colleague Greg Reiser pointed out recently in a webinar we produced for cio.com:

The extreme case of this are the large IT outsourcers that have rapidly grown over the past 20 or so years. Many firms that have actually bragged about their ability to add over 1,000 new professionals per month! Now while I can comprehend the ability of the US Marine Corps to add new soldiers at that rate, I personally cannot comprehend how a professional services organization can effectively add, develop and assimilate knowledge workers at such a pace. So I am not surprised when clients of these firms complain about the shallow depth of talent assigned to their projects. Remember, although the Marines put all recruits through a rigorous 12-week training program, every single one of those recruits is still just an entry-level soldier at its conclusion. It can take years to train and groom people for more challenging roles. Why should you expect different for software engineers?

Producing Solutions People Don't Want, but Have No Choice But To Use

Finally – and this one is arguably a bit of a stretch – Detroit has suffered eroding market share for many years. In many cases, they’re turning out cars people don’t want to buy, year after year. Increasingly, the people who do buy the cars are the people who have to buy the cars. E.g., they’re people who are in the automotive ecosystem. Sound familiar? IT stands up solutions that business users don’t want but have no choice but to use because they're in the corporate ecosystem.

A Troika of Trouble

There are three factors accelerating the rate of Detroitification of the IT industry.

1. We have a capability shortage. For one thing, we’re not developing “heroes” in sufficient numbers to prop up this system, the folks who can jump among silos to do the unperformed tasks lost in the handoffs that happen in specialization. For another, IT isn’t the destination employer for people that it once was. (And by the way, neither are automakers.)
2. We’re overloading on “situational complexity.” To get something done in most IT shops a developer has to be fluent in an esoteric landscape of existing systems, policies and procedures. Somebody might be the smartest developer in the world, but they'll make no impact unless they invest time in mastering the esoterics. That’s not attractive knowledge for somebody to acquire, because it’s not portable. There's not much value in having “I learned all the weird stuff necessary to get things done in this specific functional area of company x” on a resume. It’s also a frustrating experience, as very often the people alleged to have the right information aren’t really authorities themselves.
3. Quality is assumed. Solutions delivered today are laden with technical debt, but very rarely is anybody looking for it. Apply metrics over just about any codebase in just about any company, and the odds are that you'll find at least one of the following: excessive complexity, excessive duplication, poor encapsulation or excessively long methods.

An increase in situational complexity, plus an increase in technical debt, combined with a decrease in total capability gives us exponential growth of people expending effort but showing little in the way of business results.

We should obsess about results, not scale. Scale is useless if we can’t get stuff done.

We’ve had a look at the problems with industrialization. Next, we'll look at how we can reorganize IT for results.

Restructuring IT: "Too Big to Fail" Doesn't Equal Success

By going in pursuit of scale, we’ve created an IT function that is “too big to fail” in many businesses. Companies depend on IT – many can’t operate without it – yet they don’t really understand it.

The result is moral hazard. Moral hazard is the proverbial “heads I win, tails you lose” scenario: a person takes boneheaded risks knowing that if they turn sour, somebody will come to their financial rescue. There is tremendous concern that we're witnessing this in financial markets today: banks bought high-risk collateralized debt obligations with borrowed capital to juice returns, only to need the US taxpayer to intervene to rescue them when the value of those assets collapsed and the market for them dried up. The moral hazard of the situation is the disincentive for the banks to be prudent risk-takers in the future: if a person knows somebody will bail them out, there's no reason not to take boneheaded risks again.

This describes IT. We stand up massive projects that fail more often than not. When they fail – 6 out of 10 times mind you – the business sponsoring the initiative bails it out. And there’s no downside risk: those people who were bailed-out continue to hold down their jobs because “they’re the only ones who know the system.” They might even get promoted. This creates moral hazard in IT, as it builds in the expectation that success of the project is optional.

This is the result of industrial thinking. IT defines highly specialized roles that assume people perform repetitive tasks. This allows IT to scale by hiring armies of people, each into a very narrow position, making people expert at one very specific piece of the solution chain. Unfortunately, it also makes the success of a project an abstract goal for each person, and success of each person a relative goal. Restated, in the industrial model each person is less responsible for success of the project, and solely responsible to show that they did exactly as they were told.

Think about an IT project a long-jump team, staffed not with one person who can jump nine feet, but nine people who can jump one foot. Clearly, the results aren't going to be the same.

This is why we’ve hit the limit with industrialization. Industrial IT assumes people are automatons performing specialist tasks in a repetitive fashion. That assumption is diametrically opposed to our business partners' perceptions of IT as a source of innovation. An industrial approach that values specialization and repetitiveness implicitly stifles innovation, invention, initiative and leadership. It bleeds out creativity. I had a colleague tell me the other day that two people on a team he was working with would sit and stare at the wall until told exactly what to do. Once done, they'd go back to staring at the wall. That’s industrial IT in action, and it's devoid of innovation.

We've seen this same industrial phenomenon in other professions. For example, when professional sports leagues expand, the quality of play goes down. Consider baseball. When Major League Baseball expanded a little over a decade ago, players posted outrageous offensive statistics. The reason? There were a lot of pitchers in the major leagues who weren't really "major league." They were just people hired to fill the roster, to hold a spot in the rotation. On the days those people would pitch, the team managers would hope only that they wouldn't hurt them, more than they had any hope that they would actually help.

We have this in IT. They’re called “net negative” people. These are people who create more work for people to do than actually solve the problems we need them to solve. Analysts who write requirements that need to be substantially re-analyzed before they can be turned into code, developers who write code that is of such poor quality that it needs to be rewritten before it can be released to QA, or testers who execute test scripts without being able to pass or fail them because they don't really understand what it is they're testing in the first place all create more work for people to do than they contribute. Overall, they're "net negative" to the project.

Businesses will be restructuring for quite some time. That amplifies the risk of a late-stage project failure to IT, because project bailouts are less likely in this business climate. To come to terms with this new environment, IT needs to be less concerned with industrial scale, and more concerned with bottom-line results.

Before we get into the details of how we need to restructure IT, we'll first take a look at the similarities between the state of mature industrials and the characteristcs IT is showing today. We'll also look at the factors that are accelerating IT toward the same fate as the US automakers.

Restructuring IT: A Different Look at the Business-IT Relationship

The relationship between IT and its business partners is notoriously bad. Year after year, surveys by different research organizations report that improving that relationship is a top-10 priority for CIOs. But despite being a high priority for many years running, it hasn’t improved all that much.

Before we can make any headway improving that relationship, we must first understand how IT's pursuit of scale is responsible for a lot of the dysfunction.

Let’s take a look at what the business and what IT each want from the relationship.

First, what does the business want from IT? To put that question in perspective, we need to externalize a bit. Let’s think about what we want from the relationships we have with our key suppliers, such as the place where we go to get our coffee in the morning.

• We want results from our suppliers. In our example, we want our coffee in whatever configuration we ordered (hot or iced, cow/soy/no milk, etc.) within a reasonable amount of time after we order it.
• We want to work with professionals: we don’t want to see people scratching their heads wondering how to grind beans or froth milk. We also don’t want to hear somebody tell us that pouring drip coffee into an insulated cup “isn’t their job.”
• We want a relationship. A couple of months ago, the WSJ ran a story that people are less likely to cut back spending at places where they have a relationship with the firm, even if their household income statement tells them they need to make severe cuts. This certainly rings true in our coffee shop example: we like it when people recognize us, and have our drink ready for us before we order.
• We want innovation. If somebody offered us a cappo-moca-latte we’d probably give it a try. We want to know people are thinking about our needs and our experience as a customer.
• We want to trust the people with whom we do business. Certainly, we want to know that we get a full cup of coffee, with ingredients that aren't spoiled.
• We want value for money. We may very well pay $2.75 for a cup of coffee, but we have to feel that the coffee we're getting is worth that $2.75.

This doesn’t really describe how IT has approached its relationship with its business partners. Historically, it's had a different set of priorities.

• IT has been in pursuit of “big” as opposed to results. To get “big,” we’ve created specialist roles so we can train and staff armies of people.
• IT keeps business partners at arm’s-length: it’s been “you do the business, we’ll do the technology.”
• IT prefers predictability over innovation. In technology, Java is the new Cobol. Also, IT project management is most often an excessively detailed project plan that tries to define every action that people will take far into the future.
• IT doesn’t look to establish trust, as much as we want people to have faith that we'll overcome whatever problems we may encounter.
• People in IT are generally more interested in solving interesting technology problems than they are providing value for money.

What we end up with is a pretty big relationship gap. IT is opaque. IT solutions are laden with technical debt. There aren’t enough cross-trained heroes to bridge the gaps that exist among all those specialists. Each partner in this relationship has an unhealthy dependency on the other: business can't function without IT, and IT reacts more than it leads critical business decisions. The bottom line? IT still has a success rate no better than 4 in 10.

So it really shouldn't be a surprise when we hear a CEO, CFO, COO or even a CIO ask, “why is it so difficult to get anything done in IT?”

The Case for Restructuring IT

Business is tough right now, and it’s going to be so for a while. In tough times, you want to be very good at what you do. The more “fighting fit” you are, the more likely you are to survive a challenge.

Unfortunately, IT isn’t all that good at what it does. In fact, on the whole, it’s pretty bad. That means that IT isn’t very well prepared for this downturn.

How bad is it? The research organizations have historically reported a pretty high failure rate of IT projects: about 30% of all IT projects fail outright, while another 30% disappoint their business sponsor (e.g., excessive cost, wrong functionality).¹ On the whole, an IT investment has, at best, a 4 in 10 chance of success.

Companies are already reticent to invest in this climate. IT doesn't offer scared capital a safe haven.

It also suggests that IT is on a trajectory of self-destruction. If we want to look ahead to where IT is headed, we need look no further than present day Detroit.

Photo credit: Ben Wojdyla, The Ruins of Detroit Industry

How did this happen? Consider some of the forces that have shaped the current IT landscape in the past 20 years. The steady growth of IT that was accelerating slightly with the advent of client/server gave rise to explosive growth driven by the combination of internet and Y2K. By the mid-1990's, demand for IT was dramatically outstripping supply. To satiate this demand, IT went in pursuit of scale. To get scale, IT took professional jobs and codified them into industrial tasks, because it’s easier to staff vast numbers of people in highly specialized roles than it is to develop professional capability to solve business problems using technology.

Today, businesses buy, recruit, staff, govern, gatekeep, develop, analyze and test following a model that puts a priority on “big.”

Unfortunately, all the time we’ve been in pursuit of scale, we’ve not been in pursuit of results. Results are assumed. We assume armies of specialists will follow an explicitly defined project plan to produce a solution that is technically sound, functionally complete, and financially satisfactory, all with minimal risk of impairment.

With a 4 in 10 batting average, results cannot be assumed.

By placing a priority to scale, IT mistakes effort for results. We often see success expressed as a function of hours to be invested. It isn’t that simple. Successfully delivering an IT solution is a function of a lot of factors, such as clear communication, effective collaboration and capability; well-informed decision making about technology, functionality and commercial viability throughout the life of a project; flexibility and responsiveness; and ultimately, producing meaningful things for our business partners. These can’t be captured in task orders and forecasts of work effort. They’re lifestyle decisions of how IT goes about its business.

It is time to restructure IT, to move away from an effort-centric industrial model, towards result-centric professional one.

¹ As an example, the 2009 CHAOS report from The Standish Group shows that things haven't changed all that much, reporting 44% of IT projects were challenged (late, over budget, and / or with less than required features and functions) while another 24% failed.

Are You Ready to Restructure?

Global business faces unprecedented changes. Earlier this year, I wrote in an article for alphaITjournal.com:

Revenue forecasts aren’t materializing, capital structures are proving unsustainable, and operations are being scrutinized for inefficiencies. This, in turn, means that businesses are being completely restructured in how they are capitalized, organized, managed and governed. As businesses restructure, so will IT.

The need to restructure will be with us for a while. The financial economy isn't functioning normally, as capital markets remain on life support. The real economy isn't functioning normally either. We're still in the midst of business bailouts. Bailouts will give rise to bankruptcies, which will give way to restructuring. "Restructuring," says Gilles Moec, economist with Bank of America, "is very much the story of 2009." And business leaders seem to expect to face restructuring for some time: in a recent survey, IBM found that 91% of CEOs believe they need to restructure their businesses.

IT won't escape this phemonenon, and it must also restructure. Procurement, management and execution of IT have traditionally been focused on effort. IT has the opportunity to restructure for results, to be a transparent, efficient, responsive and collaborative participant in the business. There is tremendous upside for doing this, as it will make IT less a captive supplier of technical services, and of more an engaged business partner.

ThoughtWorks recently released a webinar I recorded on restructuring IT. I've also posted articles specific to restructuring IT on alphaITjournal.com. One covers challenge of change management during restructure, the other governing restructure. In the coming months, I'll be posting a blog series on IT restructuring that covers the deficiencies in the "industrial IT" mindset, defines a better future state for IT, and ways to go about remaking an IT organization to achieve that.

IT faces unprecedented challenge today. We have our work cut out for us, but we already have many of the solutions at hand that will allow us to meet those challenges. The opportunity is there for IT to get in front of this, and be at the forefront of corporate leadership. In turbulent times, better to be in a leadership role than relegated to a supporting position.

The Agile PMO: Becoming a Real Time PMO

In the prior installments of this series, we presented a pattern for how PMOs can better bridge the gap between executive and executor:

• First, we discussed the need to define progress in terms of business needs met and not technical tasks performed, so that we measure in terms of results, not effort.
• Next, we showed how we can track and forecast progress in these same terms – e.g., by using burn-up charts – so that we have unambiguous line-of-sight into what a team is actually doing. Again, consider the spiral diagram: we can dive into the details without any “translation” between a status report and day-to-day execution.
• Then we presented how we can measure meaningful attributes on the asset itself so we have strong, clear signals of underlying quality and a more complete picture of what it is we’re creating: harmonious greenfield or toxic brownfield.
• Finally, we saw how we can vastly simplify the burden on our delivery teams by automating metrics collection.

By doing these things, we align team execution with the needs of the PMO. This makes us more effective at governing IT:

• By reconciling actual results with our business cases, we know the in-flight NPV we’re tracking toward. This gives us a continuous assessment of whether we’re getting value for money of our IT investments.
• By exposing the quality of the application itself, we know whether we’re producing IT assets in accordance with expectation.

From the PMO perspective, the instrumentation we have of every project team looks something like this:




A few years ago, the blue boxes in this diagram were disjointed, independent activities. Today, we can automate and integrate collection to a point where in the PMO we can know what’s going on in any given team. If we're using a product like Mingle, our performance reports are updated every time somebody advances status of a story card. If we're using a product such as Cruise, our quality data is updated every time a build is triggered.


This gives us real-time information on what matters the most to us in the PMO. We have visibility into our project situations: scope changes, performance changes, lags, as well as the quality of the asset being created (and by extension, a limited degree of knowing how they’re going about doing it). We have this in near real time. It’s not burdensome: it’s an extension of what people are doing, and it lives within the tools. It’s not conjecture: it’s a reflection of functionality that works and driven right off the asset.

Becoming a Real Time PMO

So, that sounds like a great future state to target, but it won't happen of its own volition. What can we do today that will help us become a “real time PMO?”

If you have no Agile projects in flight now, stand up a couple. There are different adoption patterns, but one very common approach is to start with requirements shaping and “level 1" Agile practice adoption. As you stand up Agile projects, define each of your gatekeepers to be functional, tested, useful and deployable asset. Avoid having any gatekeeper (aside from the project chartering phase) that consists of deliverables that merely describe an asset.

If you have Agile projects, but adoption is inconsistent or you're not seeing the impact from Agile practices that you anticipated, scrutinize the state of Agile adoption in your project teams. Before building out a PMO, it's important for team fundamentals to be in place. Not all change is created equally, and Agile adoption takes time. Perform an Agile Maturity assessment to identify practice gaps and call out actionable items teams can do to bridge those gaps.

If you do have well-running Agile projects, hone in on metrics collection, automation and consolidation. Take a look at Mingle and Cruise from ThoughtWorks Studios. The build pipeline management features in Cruise are pretty impressive. Be aware that there are ramifications to increasing team visibility. Don't assume that this is simply an exercise in implementing tools, and be prepared to iterate to achieve greater degrees of transparency.

If you have well-running Agile projects today with efficient data collection, take your project tracking to the next level. Don’t just report burn-ups, report projected NPV. As things happen in a team - if scope is changing, dates are changing, quality is slipping and needs to be corrected, etc. - report out the business impact of the change in business terms to your business partners.

We do have to be careful not to put too much stock in numbers. We still have to look at code, look at the quality of requirements, run the actual software, and above all else, talk to IT people and businesspeople in the teams. We have to make sure that tasks aren’t masquerading as stories, that unit test coverage isn’t simply being gamed with meaningless tests, that progress isn't being overstated. The numbers are indicators, but they're no substitute for really understanding what’s happening in a project team. Nothing alleviates the need for fundamental project management.

That said, clear line-of-sight into trouble spots and risk areas early in a project allows us to take better decisions about projects, meaning we can avert the spectacular, late-stage blindside. With responsibility for capital investments in a difficult economic environment, we need to win and retain the trust and confidence of our business partners. We need to be on top of our game. We can do that by being an Agile PMO.

The Agile PMO: Automating Metrics Capture

The last piece of the Agile PMO puzzle is to make the data needs of the PMO non-burdensome to delivery teams. It’s all well and good to be able to get quality and performance data, but it has to be easily accessible. If it isn't, we're just taxing the teams that much more. That means we won't get this data timely or efficiently, if at all.

Automating Metrics Capture

Because they're derived directly from the asset under development, our metrics give us an objective way to index and monitor quality. What’s even better is that these metrics can be automated and run frequently. If we have continuous integration established in our teams (e.g., where the project binary is built as often as every time code is committed) we have the ability to subject the binary just built to a battery of automated quality metrics and tests. Some tests may take a long time to run, while others may run in just a few seconds. This is fine. We can construct a build pipeline to run our metrics and tests in the most efficient manner.

We can collect up-to-the-minute quality data for any project, such as:

• What extent of unit test coverage do we have, and are all tests passing?
• What extent of functional test coverage do we have, and are all tests passing?
• Are we creating code that appears to be high maintenance due to complexity scores, duplication, or other poor coding practices?

And so forth.

This gives us a collection of technical and functional risk indicators that are both comprehensive and current.

By efficiently automating the capture of different quality metrics, we don't need to ask people to generate this data for us: we can lift it right off the binary. This makes data collection non-invasive to the teams, and less prone to collection error.

Tools such as Cruise and Mingle (both from ThoughtWorks Studios) have dashboards that allow people to see first hand current quality and project status across a number of different projects. This allows people in the PMO to look into what's actually happening without burdening the teams, and make far more specific and accurate status reports to project stakeholders.

All told, we're spending less effort and getting greater accuracy of what's happening within each project in the portfolio.

We now have all of the essential components of the agile PMO. Early on in this series, we talked about aligning executive and executor in how we organize, gatekeep and articulate the work to be done. Once we've done that, the data we glean on performance and quality has integrity by virtue of being solidly founded on results achieved, not hope that everything will work out in a future we've mortgaged to late stages of a project. By automating collection of this data, we can see how a project is evolving day-in and day-out with far less effort - and conjecture - than we've traditionally had in IT.

In the next and final installment of this series, we'll recap how all of these concepts and practices fit together, consider some caveats, and present some actionable items you can get started with today.

The Agile PMO: Measuring Quality

In the last installment we took a look at the project management information we get from results-based organization and execution, and how that provides an unambiguous status assessment. But project status data doesn't give us the complete picture: we also need to know that a team is delivering solutions in accordance with all of our expectations, such as quality and maintainability. For the PMO, that means looking at technical and functional quality along side project status.

---

Quality Measures

We have no shortage of quality metrics. For example, in the Java world we can measure all kinds of attributes of code: overcomplicated expressions, wasteful use of resources, ghost code, duplicate code, complexity, and so forth. That’s both good and bad. Good in the sense that code quality doesn’t need to be taken for granted, because we can measure attributes of the asset we’re creating. Bad in the sense that with all this data, it’s hard to separate signal from noise. Quality measurements are great to have, but a meaningful assessment of quality is a different matter entirely.

There are many authorities on code quality, so we’ll not dive into them here. But there are a few metrics worth pointing out that are strong indicators that code will be difficult and expensive to maintain: the extent of code duplication, the presence of highly complex code (i.e., cyclomatic complexity), the presence of many large methods (in terms of number of lines), and code that is poorly encapsulated. If any of these are present to a large degree, we have indication that we’re taking on excessive amounts of technical debt. This is material to maintaining viability of a business case: the higher the technical debt, the more expensive the cost of the solution, the lower the yield on the IT investment.

Quality Tests

In addition to measuring quality, we must also test for quality. Quality comes in many different forms. There is functional quality (does the application perform the tasks that it needs to perform?) and non-functional quality (is it fast? does it scale? is it secure?) Our tests can include unit tests, integration tests, and functional tests. A unit test exercises a specific piece of code, while integration tests validate round trips to other systems, and functional tests validate complete scenarios. We can perform these tests manually, or, better still, we can code them. If we code our tests, we can execute them automatically. We can build a library of automated tests and subject an asset to them at any time, meaning we can get up-to-the-minute information on the functional and non-functional quality of a solution at any time.

We must be cautious. Our quality testing is only as robust as our underlying tests, so we also have to validate that our scenarios are thoughtful and meaningfully complete. Some tests are destructive, and require disciplined environments management. But testing has come along way. Functional testing tools have improved in recent years, making functional tests less fragile and easier to maintain when software changes.

The greater and more comprehensive the automated test coverage, the less assumption there is about technical and functional quality. This provides reassurance to the PMO that both functional and technical quality is being maintained over the life of the project, and that incremental functionality previously gained is sustained. This will have a material impact on achieving our business case.

Assessing Quality Information

Metrics and tests give us a collection of data points about our code, each in a different unit of measure. To turn that data into information, we need to structure it in a meaningful way. We have several options for doing this.

One alternative is a scorecard, which I wrote about in the Agile Journal some time ago. To create a scorecard, we must first normalize metrics into consistent scores using simple rules or heuristics that give us degrees of "great" to "poor." We can compare the code in question against a representative but consistent baseline of quality, so we have an absolute point of reference. We can then collect our metrics into broad categories of “indicators of good” (hygienic measures) and “indicators of bad” (toxic measures). By doing this, we can ascertain how good or bad our current state is, and whether or not it becomes better or worse over time.

Another alternative is a technical balance sheet, which Brad Cross wrote about in the alphaITjournal. In this approach, the business value and technical debt of every package is scrutinized to determine whether we’re right-side-up or under water on the solutions we've created. By drawing the line between “value” and “debt” it also tells us where our real risks lie, and what our priority and urgency should be.

Performance and Quality: The Complete Picture

Structured quality data described here paired with project performance data in the last installment gives the PMO what it needs to assess current and ongoing performance of a project. The PMO can answer for each project the two governance questions: Am I getting value for money? and, Am I receiving solutions in accordance with expectations? (n.b. It is a minimal answer because customer satisfaction and staff capability must also be considered, but that's for another blog post.) But this is a lot of data, and if we don't have an efficient means by which to collect it we'll be crushed under the weight of reporting and collection. In the next installment, we’ll take a look at what we can do to automate data capture so that collection is non-invasive to our organization, a by-product of day-to-day operations, enabling us to be an Agile PMO.

Come the Hour, Come the Leaders

Earlier this week, I published an article called Come the Hour, Come the Leaders in alphaITjournal.com. In it, I point out the acute need for business leadership in today's economic environment and identify six things we can do today to act on a leadership agenda. Today's Financial Times brought some reinforcement to those messages in the first of a four-part series called Managing in a Downturn.

Stefan Stern's Time for Managers to Stand and Deliver contains some good and practical guidance for management leaders. He also sites a Booz & Co. survey that shows that as many as 40% of senior managers said they doubt their leadership have a credible plan to deal with the current crisis, while 46% doubt the leadership team is capable of carrying out its plans, whether credible or not. This data strongly reinforces my point that "how we act and prepare, and how we explain our actions and preparations, inspires confidence more than all the rah-rah optimism in the world will ever achieve."

In Seizing the Upside of a Downturn, Donald Sull makes the point that it is imperative to be organized for consistency, instead of lurching during good times and seizing during bad ones, making reference to Lean practices as a model. He makes excellent points consistent with one of the actions I recommend: "Cutting costs to withstand a downturn in the hope that recovery is around the corner (and with it a return to business as usual) is not leadership. Being sustainably responsive to whatever the economy, the market, governments and the competition deals us is leadership. We can act very boldly to eliminate situational complexity, unaligned gatekeepers, and any other obstacles that make it difficult to get things done. We can also look very closely at Lean principles to not only eliminate waste but to make sure effort is directed toward results."

It is quite satisfying to see reinforcing articles appear within a matter of days of each other. It suggests it is a timely and important topic. I highly recommend that you read all three.

The Agile PMO: Results-Based Execution

In the last installment we took a look at why it’s important that project gatekeepers be consistent in terms of effort and results. To understand how we can execute on this, we need to take a look at how teams are organized and execute.

---

How we organize determines how effectively we can define results-oriented “gates." Traditionally, IT teams have organized in silos, working on abstract slices of the business goal (as opposed to the end-to-end). When we organize in silos, we assume that what teams create independently will work together with little effort. When it doesn’t – and that’s the case more often than not – our economies of scale are completely obliterated. Consider the Airbus A380: teams working in complete independence of each other discovered after their sections were "complete" that they couldn’t connect up the electronics.¹ Were the independent sections of the plane “complete” according to the project plan? Yes. Was the plane nearer to completion by virtue of those sections being done? No. It’s entirely possible that Airbus could have built those sections entirely from scratch (to consistent wiring specs) in the time it took to integrate the finished units they had. The lesson learned is that no matter how well we think we define our APIs, no matter how disciplined we think we can work in a silo, integration is never free.

In addition to how we organize, we also need to have some means by which to execute and therefore measure our progress that is directly rooted in the context of the asset. Functionality that is coded and tested is the best measure of "results" that we have.

To act on this, we need requirements expressed as small, actionable statements of business functionality. Agile Stories lend themselves very well to this. Stories are small, granular statements of business need. For the PMO, Stories provide us with the best measure of progress: a Story is either done, or it’s not done. It’s not partially done or kind-of done. If Stories are written in terms meaningful to the business, and if we track progress to Stories, we can assess progress in terms of results. Compare this to how we measure progress in traditional IT: there are long delays between functional deliveries, so the PMO has to rely on surrogates such as timesheet data and collections of technical tasks. Hours spent and completion of technical tasks are measures of effort. Effort doesn't necessarily translate into results. Stories are a measure of results.

The fundamental true/false nature of a Story's completeness lets us measure progress in some very simple but information rich ways. The most common way is the burn-up chart.

These example charts show that scope (in terms of Stories) may expand or contract as new discoveries are made and work is reprioritized. The projected rate of progress through the Stories - that is, how quickly the team is expected to render business needs code complete - is rooted in a simple formula that includes capacity, distraction management, and estimate weight (complexity, etc.) relative to the team.

By tracking progress through Stories, we're measuring accomplishment of meaningful results. With each iteration, the PMO knows the specific functionality that an asset possesses and how much it cost to get it to that point. We also know what functionality the asset does not have and we have a pretty good means by which to forecast how much it's going to cost to complete that functionality. Best of all, in near real-time we can see if a project is showing signs of trouble, we can see almost immediately the impact of changes that we make, and we can communicate all of this in business (as opposed to IT) terms. Traditional IT cannot provide this level of transparency.

The burn-up is meaningful only if we know that it has integrity. Nothing prevents us from defining and tracking technical tasks. If we do that, we're really no better off than we are in current IT practices: it’s just a burn-up of effort, but not of results achieved. We have to make sure teams are relentlessly focused on satisfying business need, from the time a requirement is captured to the time software is certified as production ready. By writing well formed Stories, we're writing the "completion gene" into the DNA of a project team. This aligns the interests of the business (the buyer), the PMO (the buyer's agent and de-facto underwriter), and the development team.

This gives us direct line-of-sight from the unit of measurable work all the way through to the project reporting level, so that when we report upward we know that there is integrity in what we’re reporting. This is deceptively simple, but is the critical component to the Agile PMO: we know what is done, and what isn’t done, not in IT terms but in the terms of what it is we're buying. By extension, we know our investment yield to date and what returns further investment will yield.

The proliferation of Agile Project Management tools, such as Mingle from ThoughtWorks Studios, make it far easier for the PMO to get project performance data from in-flight projects. We don't need to transcribe data from what a PM has told us into what the project sponsors need to know. We're not e-mailing spreadsheets around. We're drilling into a project dashboard to see what’s going on, and we know what’s going on in very granular terms that relate back to the state of the asset.

The combination of team organization and Story-based requirements allow us to work and measure in terms of results. But the results we're looking for go beyond “completed Stories.” We must also have some appreciation for the quality of the solution delivered. Progress – even in “functionality” terms – may be completely hollow if the expected level of quality (e.g., maintainability, technical quality, etc.) isn’t baked in at the same time. This means we are at risk of over-stating our results. In our next installment we’ll have a look at how we can align quality metrics to get a complete picture of solutions delivered, and we’ll look at how to automate capture to make this simple. Once we’ve done that, we’ve defined the fundamental tools necessary for an Agile PMO.

¹ Hollinger, Peggy."In a tangle: How having to wire the A380 by Hand is hampering Airbus." Financial Times. 16 July 2008.

The Agile PMO: Consistent Project Gatekeepers

In the last installment we took a look at the gap between what the PMO reports out, and what's actually happening in a project team. To begin to understand the nature of this gap, we’ll first take a look at what we use for project gatekeepers.

---

We need to make a clear distinction in an IT project between the means and the ends. We often confuse this, because what we see day in and day out is that we’re paying for the means of production, when in the end we’re really acquiring an asset. Unfortunately, this tends to skew our thinking about how we execute, organize, measure our progress and assess our exposure.

Traditional IT projects are mass economy-of-scale exercises: once development begins, armies of developers are unleashed. So in Traditional IT we stage large volumes of work to keep the largest and most expensive pool of people – developers – busy in the hopes of maximizing their productive effort. To minimize the chance that development is misdirected (e.g., due to poor requirements) or wasted (e.g., due to poor technical structures), we create checkpoints, or gatekeepers, throughout the project. Satisfy the gatekeeper, so the thinking goes, and we minimize the risk. Traditionally in IT, our gatekeepers are typically several different waves of requirements and specification documents, then software, then test results, then a production event.

This may give us lots of gatekeepers, but they’re inconsistent in both degree of effort and results achieved.

Clearly, a small team delivering documentation is nowhere near as significant an event as a large team delivering executable code. But of bigger concern is the latency between the time when requirements are captured and the time they're available as working code in an environment. We don’t know for fact that our documentation-centric gatekeepers have truly been satisfied until we have a functioning asset. A dozen people can reach a dozen different conclusions after reading the same documentation; the proof of the quality and completeness of documentation is in the delivered software. Inadequacies in documentation may not become apparent until QA or, if we’re lucky, during development. In effect, there’s very little other than opinion to prevent us from developing a toxic asset: bad initial requirements are transformed into flawed derivative artifacts (specifications, code, even tests) as they pass through different stages. And, of course, we not only pass along quality problems, we risk introducing additional quality problems unique to each stage (flawed technical specifications, poor tests). This just adds insult to injury: we’ve not only put ourselves at risk of creating a useless asset, but our interim progress reports are laden with false positives.

One solution often attempted is phased delivery of use cases: the traditional IT steps are still performed, only we make interim deliveries of code to a QA environment and execute functional tests against them. The theory goes that functional success is assured by test cases passing, which, in turn, indicates some measure of “earned value” for the total amount spent. This assumes that the software released to QA on this interim basis is of high functional and technical quality. If it is of low quality – again, think of all the problems that build up when people work in technical or component silos and all that toxicity we’re building up through the “soft” gatekeepers of project documentation – the blowback to the teams in the form of a large number of defects raised will interfere and ultimately derail development. When this happens, it obliterates the economies of scale we were hoping to achieve. Phased delivery of use cases does less to expose problems in a solve-able way early in the lifecycle than it does pile-on work to development teams that are already overloaded. It adds noise to the development cycle and confuses decision makers as to what is going on, and why it’s happening in the first place. This may fail a doomed project sooner, but not by much. The real tragedy is that the idea of incremental delivery will be discredited in the minds of the people involved in the project.

By comparison, Agile maintains a steady pace of progress by having all of functional efforts simultaneously focused on achieving the same result. An Agile team is not an exercise in scale. It maintains a more consistent (or at any rate, less volatile) level of effort over the life of a project. Our gatekeepers are consistent, rooted in certification of the code, not certification of things that describe what will be coded. Either we have delivered the requirements defined or we have not. They either satisfy our technical and functional quality gatekeepers or they do not. They are found acceptable by the business or they are not. We know this with each iteration – every 2 weeks or so – not months or even years after requirements have been penned. Quite simply, because we derive our certification exclusively from the delivered asset and not from things that describe the asset, we’re not confusing the means for the ends.

Just because Agile teams are not exercises in scale doesn't mean they don't scale. To take on a large application, we divide the project into business-focused teams instead of technically-focused teams. "Work completed" is more clearly understood, because we report in terms of business needs satisfied (results) and not technical tasks completed (effort). Reporting progress in a large development program is therefore much more concrete to everybody involved.

However, this doesn’t mean that an Agile project won’t fail. It may. But if it does, it’s far less likely to be a spectacular failure. By paying attention to results as opposed to effort, we spot both trouble and opportunity a lot sooner in an Agile project. This means we can take smaller and less expensive corrective action (reprioritzation, technology change, team change, etc.) much earlier. More importantly, we’ll see the impact of those actions on our bottom line results much sooner, too. This is far better than being surprised into making a large and expensive correction late in the lifecycle.

So what does this mean for the PMO? It means that we have to change what it is we’re measuring – the means by which we can declare “victory” at any gatekeeper – if we’re going to change what it is we’re managing. We don’t want our gatekeepers to be rooted in effort; we want them rooted in results. In IT projects, the results that matter are the code and its demonstrable attributes (performance, technical quality, functional quality, etc.), not assurances about the code. We want to see results-based gatekeepers satisfied from the very early stages of the project, and we want them satisfied very frequently. We can do this across the portfolio to reduce execution risk, and with it reduce the probability that we'll get blind-sided.

Changing our gatekeepers is important, but it’s only the first step. In the next installments we’ll take a deeper look at how we organise and execute for development, and the impact that has on the confidence with which we can measure progress. We also need to be aware of how much work we might unintentionally create for people. Setting up these gatekeepers sounds great, but we need to avoid “metrics tax” burden on the teams, so we’ll also take a look at how we can make this collection non-burdensome to both team and PMO, and get closer to real-time project metrics.

The PMO Divide

This content is derived from a webinar I presented earlier this month titled The Agile PMO: Real-Time Metrics and Visibility. This is the first of a multi-part series.

---

We’ve all seen it: the project that reports “green” status on its stop-and-go light report for months suddenly goes red in the late stages of development. This is nothing new to IT, as projects suddenly crater all the time. But it begs the question: why does this happen as often as it does?

Program Management Offices (PMOs) are at the nexus of this. PMOs are responsible for keeping an eye on the performance of the IT project portfolio. They sit between the executives who sponsor IT projects and those who execute those projects. This means the PMO is responsible for bridging the divide between the two groups. But this divide is wider than we think. All too often we end up with overworked project managers frustrated by doing double duty managing a team and filling out status reports on one side, and angry, humiliated business sponsors blindsided by sudden project changes on the other.

Let's look at what it means to sit between executive and executor.

Facing “upward” to project sponsors, the PMO needs to be able to report status. It must show it has control over spend and that there is demonstrable progress being made. Facing “downward” the PMO needs to get spend and progress information from delivery teams. But because of the way most IT projects are structured, these aren’t easy questions to answer, and this creates an information gap.

IT projects are often structured by area of technology specialization (e.g., User Interface, middle tier, server side, database, specialists in things like ERP systems) or by component (e.g., one team works on the rating engine, one team works on the pricing engine, and so forth). This means that development of a bit of business functionality is splintered into independent effort performed by lots of specialists. Those individually-performed tasks need to be integrated and then tested from end-to-end. Integration is an opaque, under-funded phase most often scheduled to take place late in the project. End-to-end testing - the best indicator of success - can't take place until integration is complete. This means that lots of development tasks may be flagged as “complete” but they’re complete only by assertion of a developer, not by “fact” of somebody who has exercised the code from end-to-end.

What this means to the PMO is that when it looks “downward” to get an answer for somebody “upward” there’s a fair bit of conjecture in the answer. By deferring integration and testing, the whole of what we have at any given point in time is less than the sum of the parts. Code has been written, but it may not be functional, let alone useful. Measures of progress and spend are therefore highly suspect, because they are really lagging indicators of effort, not forward looking indicators of results. It also means that when we use effort as a proxy for results, we inflate our sense of progress. In traditional IT, which is effort-centric, there is nothing preventing us from reporting inflated numbers for months on end. The longer we do this, the greater the risk of being blind-sided.

This doesn’t become a serious problem in each and every project because the gap may or may not be a serious risk. The degree of exposure depends on the situation in the team. Since we know from experience that some teams seem to succeed while others fail, it’s worth exploring why this is.

In the best case scenario, reporting up to the PMO is a nuisance to a project manager. The data the PMO is asking for isn't what the PM uses to manage the project, so filling out status reports is a distraction. It can only truly be a nuisance and not represent an outright risk, though, if the team itself has all the behaviours and communications in place to complete their objectives in a business context. That is, the sum of the tasks in the project plan might not describe what needs to be done to complete business delivery, but the team itself may have the right leadership and membership so that it takes responsibility for completing the delivery. So, while there may be “leakage” on the project budget and timeline because not everything that the team does is fully and completely tasked out (and still inaccurately tracked in time entry systems and what not), the impact of this leakage is contained because the team is by its very nature working toward the goal of completion. There may be a lot of reasons why this is the case. Perhaps the team has been working together for many years and knows how to build-in contingency to cover the small overages. Or perhaps it's simply a team with few skill silos. Regardless the reason, leakage is contained when the right team dynamic is in place.

In the worst case scenario, people in silos work to complete their tasks to a point where nobody can tell them that their tasks aren’t done. Working to complete tasks, of course, isn’t quite the same as working to complete functionality. Completing UI code, services, and some server-side code does not necessarily define a complete business solution. In very large projects it's not always completely clear who is responsible for the complete solution. Is it the business analyst? The last person to commit code in support of a use case? The project manager? The QA tester? This responsibility void is made more acute by the fact that the “last mile” is the hardest: the steps necessary to integrate all the bits of code so that everything lines up and technically performs, as well as meets functional needs and satisfies non-functional requirements, is always the most difficult. In a large project structured around technology specialism (and very often made worse by a staff of “passengers” fulfilling tasks and not “drivers” completing requirements), we don’t have leakage, we have full-scale hemorrhage. No amount of contingency can cover this.

This means that in traditional IT, the PMO isn't bridging the divide. The data it gets from teams isn't reliably forward-looking. Reporting against task completion inflates progress, while spend data is simply cost-of-effort that doesn't directly translate into cost-for-results. The reported progress is inflated, and cost control is misleading.

This puts the PMO in a situation where it is underwriting the risk of the development capacity that has been sourced to complete a project. Work is being done – we know this from the timesheet data and task orders – but there’s no map from timesheet data to the degree to which a business need is functionally complete, and no way to know that it’s technically sound. In effect, the PMO is the buyer’s agent for an asset and it is underwriting the risk of developing that asset, but it’s not taking informed decisions with the state of the asset in full view at all times. To get visibility, PMOs typically try to scrutinize the minutia and decompose the project into further levels of detail and precision. Ironically, the greater the specialization baked into the plan, the more likely we are to miss the things that get the software into a functionally complete state. For all of this alleged precision, we may have more data, but in the end we have less information.

How can we bridge this divide? By managing and measuring incremental results, not collective effort. This aligns day-to-day activity with topline reporting. That, in turn, reduces our exposure to late-stage project collapse.

Ultimately, we want the PMO to have real-time and forward looking information about it's project portfolio, and to be able to get that information in a manner that is non-burdensome to project teams. But getting ourselves into this future state will require some re-alignment. In coming posts we'll look at IT organization and practice, as well as what we use as measures for progress and quality, that will allow us to do this. As our first step, we need to reconsider what it is we use for project gatekeepers, basing our decisions not on descriptions of the work we expect to do, but on the actual state of the asset under development.

The Agile PMO - Real Time Metrics and Visibility Webinar - 5 November

There’s a lot riding on IT in the current economic climate. In tight times, businesses rely on efficiency, and IT investments will be expected to create a lot of that efficiency. But while IT assets may help the business tighten up, IT execution must also tighten up to match the times.

That doesn’t mean IT projects have to execute flawlessly. They never will, as there will always be situations and events that challenge even the most experienced of teams. What it does mean is that the people responsible for IT projects will need to make well-informed decisions throughout the life of a project. That requires current, accurate and clear information about what’s actually happening in eah project.

IT doesn’t excel at this today. The failure rate of IT projects has been discussed for decades. Yet the most important IT initiatives that are subject to the greatest scrutiny still crater suddenly late in their lifecycles, much to the surprise of their executive sponsors. This exposes the very wide divide between what the PMOs need to know to oversight a portfolio (such as total time spent, features complete and functional QA results) and the indicators that the PMs use to manage projects day-to-day (such as technical task orders, defect counts and high-priority issue lists.) This gap also means that the status data that the PMOs eventually get is late and stale.

What this all means is that PMs are doing double duty, executives are getting blindsided, and PMOs are caught in the middle unable to satisfy either. The collective frustration by all parties is unfortunate, but it may also be little more than a tragic sideline. Capital is scarce and increasingly impatient, and IT will find it even more so if its business partners have little confidence that IT can deliver. Historically, executives have felt backed into a corner when an IT project fails, given little choice other than bailing out a project that has suddenly and surprisingly redlined. But as we're seeing in the global economy right now, historical patterns no longer apply.

There is a better way. Join me on 5 November for The Agile PMO – Real Time Metrics and Visibility. We’ll discuss how Agile practices align day-to-day execution with executive needs, and how the PMO is instrumental in making this happen:

• Using requirements - not abstractions - as gatekeepers. What does it mean to complete business requirements and not just tasks, and why does this distinction matter?
• Transparency. How can the PMO get unambiguous line-of-sight into what’s happening on the ground across the portfolio, both functionally and technically?
• Metrics. We need information, not dispirit data points. What is signal, and what is just noise coming out of a project? How does Agile cut through the noise?
• Collection. We need to collect project data efficiently, otherwise our projects will suffer under the weight of data generation (or simply not report it). How does Agile align with PMO needs so that collecting status data is not a burden to project teams?

I hope you can attend on the 5th.

Registration Details: The Agile PMO - Real Time Metrics and Visibility
Wednesday, 5 November 2008
Time: 12:00pm Eastern Standard Time (US-New York, GMT-5:00)
Registration URL: https://thoughtworks2.webex.com/thoughtworks2/onstage/g.php?t=a&d=842762110

Agile Readiness Assessment Webinar - 19 September

Please join me on Friday, 19 September for An Agile Readiness Assessment, a ThoughtWorks sponsored webinar.

Taking on Agile can appear to be an overwhelming commitment with no obvious place to start. For one thing, Agile is often a significant departure from how a team is operating, requiring organisational changes, new practices, and stricter discipline. In addition, because there are so many different things to be done - from continuous integration to Story based requirements - it's difficult to know what changes to make first. Finally, organisational constraints such as phase-based governance and shared QA can create questions about the extent to which Agile practices will have an impact, and raise doubts as to whether they can be taken on in the first place.

In this webinar, we'll discuss how to overcome stationary intertia and plot a course to Agile practice adoption.

• How can we critically assess the state of our practices today?
• What goals should we target given constraints and organisational realities?
• How do we prioritise what we should do first?

I hope you can attend on the 19th.

Registration details:
Friday, 19 September 2008
Time: 1:00pm Eastern Standard Time (US-New York, GMT-4:00)
Registration URL: https://thoughtworks.webex.com/thoughtworks/j.php?ED=108081447&RG=1&UID=0

IT's Identity Crisis

IT lacks a consistent definition of exactly what it does vis-à-vis its organisational peers.

• Accounting is the language of business.
• Finance is how business gets capital.
• Marketing creates customers.
• Sales brings them in.
• Operations are how a business creates value.

IT does … what, exactly? Creates new business offerings? Retains customers? Is how business gets done? What do these really mean?

All too often they end up meaning, “would you like fries with that?” When that happens, IT devolves into a cost to be contained, a nuisance to be tolerated.

This ambiguity of purpose is made worse by the fact that IT brings both a language and set of priorities that are of no real interest to the business (e.g., technical "issues"). It’s no wonder IT struggles to justify its annual spend: it has a fundamental identity crisis.

This creates some rather bizarre side effects.

One is that a lot of businesses put IT in a narrow box, giving it a rudimentary but clear definition as a utility that operates at a predictable, consistent cost. The price of this simplification is that IT cannot perform as a competitive capability, but so it goes. Hard costs ("annual IT spend was reduced through strategic sourcing contracts") are easier to present to shareholders than soft language ("IT gives us a transformational capability.") Having clear line of sight as to where IT spend is going trumps vague promises of competitive advantage.

Another are the proliferation of IT firms on the sell side with very odd-sounding offerings: "We radically transform business to invent and reinvent them.” Yes, of course you do. Good luck with that.

But the real tragedy of IT’s identity crisis is that it is significantly responsible for two of its core problems.

One is that IT serves the wrong master (technology) at the cost of the right one (the business). Debates over platforms and tools often overshadow discussions of business need. This is particularly disasterous when the business is drawn in to mitigate a resolution. This is why IT typically lacks a seat at the top table of the business.

Another is that IT lacks both quantity of management practitioners and maturity of management practices. Despite involvement in every part of the business, generally speaking IT is not a destination employer for management talent, certainly not to the extent that other business disciplines are. To wit: finance typically attracts top business talent, while more often than not IT promotes engineers or mathematicians with little business education or acumen into positions of management.

Application development exemplifies this. Purchased solutions such as accounting systems or office tools have become business utilities. However, custom applications that support custom operations from which businesses derive competitive advantage defy a utility model. There’s been effort made to bring commodity thinking into appdev, to a point where we’ve created buying patterns that commoditise people. But skills – especially at the high-end of IT – are not ubiquitous and portable: one firm’s technical architect is another’s junior developer. We’ve abstracted what we’re buying into roles and definitions, and in so doing we've made it cheaper to get what we’re buying, but we’re not buying what we really need.

What we’re buying in appdev, of course, is capability. That’s hard to define. But then again, so is IT in the first place.

So having asked the question, what’s the answer? What is IT relative to its peer group of business disciplines?

IT maximises return on invested capital.

IT investments are made for one reason only: efficiency. We can execute operations (e.g., define and trade exotic financial instruments or run a manufacturing plant), comply with regulation, win and retain customers, and keep track of revenue and cash flows all by hand if we must. IT investments may make many opportunities possible that would otherwise not be economically viable, and it may make the burden of regulation less costly to bear, but it’s an efficiency game. This means IT maximises returns by quickly delivering solutions that create business efficiency.

By extension, it also means that IT should be a destination discipline for business talent. Capital that needs to sweat the assets will do so through efficiency of operations. In most businesses, efficiency will be realised substantially through IT, because IT has a hand in every aspect of a business. Any representative of that capital (e.g., the board, the CEO, the CFO) looking for ways to maximise returns will start by leveraging IT. This requires not technology leadership from IT, but business leadership.

So when capital comes calling for that leadership, IT needs to be prepared with an answer. That answer isn't that IT solves "business technology" problems: arguably, they're all contrived anyway. It isn't that IT achieves the minimum cost-per-role-staffed relative to its industry peers: that's abdication of leadership masquerading as fiduciary responsibility. Nor is it to reinvent business: there are still far more low tech than high tech solutions to business problems. IT must answer in terms specific to what it can deliver that creates business efficiency and therefore returns. This is how it fulfills its organisational role to maximise return on invested capital.

Any other answer misses the point.

Introducing alphaITjournal.com

alphaITjournal.com

I'm pleased to announce the launch of alphaITjournal.com, an online magazine focused on the execution, management and governance of IT investments that can produce outsized (or "alpha") returns. The mission and purpose are summarised in the welcome message on the site and in the press release that was issued in early July.

There are a few things that I hope stand out about the site.

The first is the site layout. It's designed to give attention to writers and their articles, and make the content easy for readers to navigate without being overwhelmed by a polyglot of messages.

Another is the absence of advertising. Aside from the "Presented by ThoughtWorks" message on the left navigation and bottom menu, there is no advertising on alphaITjournal.com. Being practitioners, this affords us flexibility in dealing with changing project demands and work priorities that will affect content production and editing.

Still another is the continuous release of content. Rather than having monthly editions, there will be one or two articles released each week. This will make it easier for the reader to stay current, and it will also make it easier to sustain fresh content on the site.

Last but certainly not least is the diverse community of writers. While ThoughtWorks is sponsoring the site, the community of writers are from all corners the IT universe. They, in turn, are producing content on a diverse collection of topics, all with a common theme: how to maximise returns on IT investments.

I hope that alphaITjournal.com consistently provides compelling content so that you'll be a regular reader, even a promoter: add it to your RSS news reader, share it with your peers and customers, add a link to it from your blog. I also hope that you'll consider being a contributor. We have a number of writers, but we are always looking for more. If you have ideas for individual articles, a series or a column, drop me an email.

We've just gone live, so there are a few additions we'll make once we establish our rhythm (such as reader comments). Meanwhile, if you haven't done so already please give alphaITjournal.com a visit.

Agile Made Us Better, but We Signed Up for Great

This content is derived from material presented in a ThoughtWorks-sponsored webcast in June 2008. A two minute video presentation of this material is available. A complete webinar re-broadcast, including audience Q&A, will be available soon.

---

The popular press makes Agile sound like nirvana. Practitioners speak of it in nearly religious terms. Yet we often find that IT teams are underwhelmed after going “Agile,” even after having expended considerable effort on making the change.

Why is this? Is there too much hype around Agile? Could it be that it doesn’t work? No, it’s because they’ve fought only half the battle: they got some of the practices, but not the behaviours.

When teams or departments decide to “go Agile” they’re typically moving away from what they’re doing now, as much as if not more than they’re moving toward what it is they want to be doing. That is, they’re trying to get away from regressive behaviours where the way work is done impedes responsiveness, or they’re trying to get away from chaotic behaviours, where people are pursuing responsiveness at the cost of consistency and quality.

Changing the way work is performed is no simple task. Making investments in how work is done is extra effort above and beyond what has to be done just to keep up with the day-to-day. And there’s stationary inertia in IT: a lot of practice and theory have roots dating to the Eisenhower and Churchill eras. Getting away from regressive or chaotic states takes a lot of effort, and that effort isn’t necessarily sustainable.

No surprise, then, that many IT teams lose their appetite for change once they’ve shed their bad practices in favour of minimally good ones. But good practices are not the same as good behaviours. And that’s what separates the “functionally Agile” teams from the truly responsive ones. Do developers have a Pavlovian reaction when the alert goes out that the build is broken or are they content to leave it to somebody else? Are people co-located and directly engaged with each other in the execution of team responsibilities, or do they simply sit near each other still working in silos and swim-lanes?

Agile is not a Boolean question. There is no single thing you can do, or tool you can adopt, that will make your team “Agile.” It is a collection of practices. The extent to which these practices are mature in a team determines how responsive the team can be. The more mature states of practice require aligned behaviours.

This isn’t academic. Working with several colleagues, we’ve constructed an assessment tool, called the Agile Maturity Model. We’ve looked at 10 dimensions including project management, requirements, development and configuration management, and identified consistent patterns of progression – or maturity – in the way people and teams move toward more agile practices. For example, a team that infrequently performs its build manually today will not be able to cope with a build that automatically fires with each code commit and fails if code quality levels are below a specified threshold. The same is true for collaboration: a team that communicates requirements or project status by presentation is not going to get much mileage from automated collaboration tools. Durable practice results from taking incremental steps. This is how we gain mastery.

A maturity model helps us understand what it is we are doing as well as what it is we are not doing. That it’s based in experience makes our path to responsiveness less a matter of opinion, and more a matter of fact. But the real value is that it gives us some insight into the cost and the returns of taking the next steps. For example, perhaps if our frequently executing build were a continuously executing gatekeeper of quality, we could eliminate hours of rework, lost productivity and late nights because of bad builds being released into an environment. Or perhaps we wouldn’t have missed a subtle shift in the business priority had we been working as a team to deliver small but complete business requirements instead of technical tasks. A maturity model helps us to clearly pinpoint our best opportunities for change.

Using the model, we can also index where we’re at. There’s merit in an index, in setting some quantitative value for our target, historic and current states. It helps us to be more communicative about our strengths as well as our deficiencies. But the point of having an index isn’t to score or grade. The model isn’t our team, and the model doesn’t give results to our business partners. All it does is gives us an indicator of the extent to which we’re past the point of doing things that undermine responsiveness, and at a point where we’re behaviourally aligned for it. Or, that we’re not yet past that point. An index is an indicator that helps us frame our situation; it is not our sole purpose. Process is important, but we’re on the payroll to deliver solutions; we’re not on the payroll just to have really great processes.

There’s nothing wrong with being “functionally Agile.” Breaking free of the restrictive practices or simply getting some control over chaos is a better situation for an IT team, and usually is the result of significant effort. But don’t mistake it for being organizationally responsive. Recognize there are degrees of practice and find the optimal combination for your team or department. Above all, hold your teams to the expectation that they will not just perform to a set of practices, but behave in such a way that they maintain the highest state of readiness for whatever comes. Achieve that, and your IT organization will be more resilient to threat and better able to capitalize on opportunity.

The Moral Hazard of IT projects

The longer an IT project is expected to take, the greater the risk of moral hazard: i.e., that IT will provide poor information to its business partners or have incentive to take unusual risks to complete delivery.

This is not borne of maliciousness. People on an IT project are not necessarily out to defraud anybody. It may simply be that people incompletely scope the work, make assumptions about skills and capabilities, or are overly optimistic in estimates. This creates misleading project forecasts, which, in turn, lead to a disappointing asset yield.

This is the raison d'être for the rules-based approach to IT: improve rigor in scoping, estimating and role definition, it is argued, and projects will be on-time and on budget. Unfortunately, this won't accomplish very much: the moral hazard that plagues any IT project is not a product of poor practice, but of behaviours.

Rules-based IT planning assumes that each person in a team has an identical understanding of project and task, and is also similarly invested in success. It ignores that any given person may misunderstand or outright disagree with a task, a technology choice or a work estimate. These differences amplify as people exit and join a project team: those who are present when specific decisions are taken – technical or business – have a context for those decisions that new people will not. The bottom line is, there is a pretty good chance that any action by any person will not contribute to the success of the project.

Complicating matters is the ambiguous relationship of the employee to the project. The longer a project, and larger a team, the more anonymous each individual’s contribution. This gives rise to ITs version of the tragedy of the commons: because everybody is responsible for the success of a project, nobody takes responsibility for its success. The notion that “everybody is responsible” is tenuous: success or failure of the project may have no perceived bearing on their status as employees. And, of course, people advance their careers in IT by changing companies more often than they do through promotion.

But by far, the biggest single contributing factor to moral hazard is the corporate put option. There’s a long history of companies stepping in to rescue troubled IT projects. This means people will expect that some projects are too big or too important to fail, and that the business will bail out a project to get the asset.

All told, this means that the people working in a traditionally managed IT project may not understand their tasks, may perceive no relationship between project success and job or career, and may believe that the company will bail out the project no matter what happens. There might be a lot of oars in the water, but they may not be rowing in the same direction, if at all.

Especially for high-end IT solutions, the rules-based approach to IT is clearly a fallacy: any “precise” model will fail to identify every task (we cannot task out solutions to problems not yet discovered) and every risk (project plans fail to consider external forces, such as dynamics in the labour market). Rules feign control and create a false confidence because they assume task execution is uniform. They deny the existence of behavioural factors which make-or-break a project.

A rules-based approach actually contributes to moral hazard, because the tasks people perform become ends in and of themselves. To wit: writing requirements to get past the next “phase gate” in the project lifecycle is not the same as writing actionable statements of business need that developers can code into functionality.

Work done in IT projects can end up being no different from the bad loans originated to feed the demand for securitised debt. At the time development starts in a traditionally managed project, all we know is that there are requirements to code (e.g., mortgage paper to securitise.) Further downstream, all we know is there are components to assemble from foundation classes (e.g., derivatives to create). Nobody touching the details of the project have responsibility for its end-to-end lifecycle; once a detailed artifact clears the phase gate, that person is done with it. This is supplemented with misguided governance: quality and completeness of intermediate deliverables aren't reconciled to a working asset but to an abstraction of that asset, the project plan.

Just as we don’t discover defaults until long after the bad paper has entered the securitisation process, we similarly don’t discover problems with specifications or foundation code until late in the delivery cycle. There's typically only a minor provision (in IT terms, a “contingency”), meaning we can absorb only a small amount of “bad paper” in the project. And because it comes so late in the cycle, the unwind is devastating.

This does not mean that IT professionals are untrustworthy. What it does mean is that there must be a short impact horizon for every decision and every action. Our top priority in managing IT projects must be to minimise the time between the moment a requirement is articulated and the moment it is in production. That means the cycle time of execution – detailing requirements, coding, testing and releasing to production – should be measured in days, not months and years. This way, the results of each decision are quickly visible in the asset to everybody on the project.

Short impact horizons align behaviour with project success. Each person sees evidence of their contribution to the project; they do not simply pass the work downstream. A project may still go off course, but it won't do so for very long; a small correction is far less costly than a major unwind. And, of course, we can extract better governance data from an asset than we can from a plan.

Best of all, we’re not backstopping the project with the unwritten expectation that the business may need to exercise its put option.