The Agile CEO: A Blog About Agile Management

Agile in the Mainstream: The Daily Standup on WSJ Front Page

Pam Dyer — Thu, 02 Feb 2012 17:50:00 GMT

Here's another indication that Agile and Scrum in particular are catching on like wildfire. Agile’s radiation through the tech sector is easily explained since it fits hand-in-glove with software development, but when we hear about it in the Wall Street Journal, we witness something else: Penetration of these ideas into the business mainstream. What is a stand-up but a vital daily status meeting ruthlessly stripped of all waste? You can’t get more lean than that. Agile is a pointer to a waste-intolerant, performance-driven culture obsessed with the pursuit of excellence. What business would not want some of that?

Software Development is Design Work, not Construction Work

Charlie Rudd — Thu, 01 Dec 2011 18:43:00 GMT

In my last post, we discussed why software development is more like designing than building. The following diagram illustrates the point:

Construction is building to specification. In the case of a house, the construction is done by tradesmen and the specification is a blueprint. In the case of a software system, the construction is done by a compiler and the specification is the source code. In both cases, the work to produce the specification is design work. So just how different is building to specification from design work and how might this change our expectations regarding software development?

The first thing to keep in mind is that a comprehensive specification not only provides an objective way to verify delivery of the desired outcome, but also entails an objective definition of all the work that needs to be performed. Each source code statement determines precisely what “work” the compiler will perform. The blueprint makes clear everything that the tradespeople need to do. If you wanted to, you could count the number of nails you will need and how many times you will need to hit the hammer. Or to put it differently, you could develop a comprehensive task-level WBS from the specification. This kind of work is reducible to a finite set of repeatable tasks and procedures that can be abstracted as labor. Such work is inherently automatable. In principle, a machine could be built or programmed to perform this work and when people perform this work, they are in effect part of a larger virtual machine. Switching people operating within a virtual machine such as an assembly line is comparable to swapping out parts of any other machine: the machine’s output does not change. In fact, that is the whole point. This spec-driven approach to defining and managing work is the approach known as scientific management (or Taylorism) that was developed to optimize manufacturing production. Let’s call this kind of work fungible work, and the production process where it is performed the fungible work machine.

The fungible work machine is a one-trick pony. The inputs and the outputs are always the same. When people are valued for the part they play within a fungible work machine, they are valued as standardized labor units and not as unique human beings.

Now let’s contrast construction or fungible work with design work. Design work taps human creativity. The outcome emerges over time and is not predictable. To a large degree, the outcome is not tangible. The outcome is some kind of specification to produce something tangible. Design work is a form of knowledge work. Knowledge work involves analyzing, sharing, elaborating, and validating ideas. Developing ideas usually requires different perspectives, which requires discussion and collaboration with others. It’s tough to get to the bottom of human creativity. Attempts to reduce this kind of work to elemental procedures fail. When people put their heads together and create something new it’s often seems like a miracle.

When it comes to knowledge work, who does the work makes all the difference. You change the person and you change the outcome. The outcome is unpredictable. To succeed, knowledge work often depends upon collaboration and experimentation. In contrast to fungible work, people add value through their unique human characteristics of creativity, thinking, and communication; not by contributing generic labor.

Fungible work and knowledge work could hardly be more different from each other. They operate under different conditions and in different environments. Perhaps the most important contribution of Agile software development is the recognition that software development is fundamentally knowledge work not fungible work, as past development methods and practices have assumed.

Why Agile Spreads Like Wildfire: Upfront Specification is Impossible

Charlie Rudd — Wed, 16 Nov 2011 19:31:00 GMT

In my last post, I talked about why it’s really hard to produce a software specification before you start work that is as complete as the blueprint you would use to guide the construction of a building. Today we will discuss why it’s also impossible.

Let’s review our building blueprint example from another angle. After the blueprint is completed, just about any competent builder can use the blueprint to construct the building. Carpenters know what dimensions the house and rooms should have, roofers know how many square feet to roof, etc. In addition to knowing what work needs to be performed, builders also know exactly how much of each material will be needed. Although the construction may take place over several months, the builders will have a precise estimate of what the costs of construction will be. The developer who hires the building contractor not only knows what it will cost, but also is quite certain that as long as a competent contractor is employed the finished product will be pretty much the same.

Let’s now apply this example to a software project. Instead of a building at completion, we have an executing software system. The system is not built by a building contractor - it’s built by the compiler. Although it may only take a few moments to build, the end result will be close to identical regardless of which compiler we use. …say, wait a minute! If the builder is the compiler, then that means the blueprint is the source code.

We just put our finger on a fundamental confusion. Software developers are not builders in the sense of carpenters building a building. They are more like designers designing the blueprint. Their work product is not the finished product, but a specification for the finished product. Therefore, by definition, you cannot complete the software system specification until you complete coding the source code.

So what do we call that document we were referring to as a software specification? It’s also a specification. In fact, it’s a specification for a specification.

The artifacts produced by a traditional waterfall software project are in fact all specifications that stand in a “specification for” relationship with the next in the series.

That is, design docs are specifications for source code, functional specs are specifications for design docs, and so forth. Doing software development like this is like playing a particularly convoluted and abstract form of telephone - you know, everybody in a circle whispers something quickly that is hilariously misunderstood at the other end. Except that sometimes on a software project it takes a year or more to get around the circle, and by that time nobody thinks the outcome is very funny.

Developing software iteratively and incrementally the Agile way does not result in a big surprise at the end like playing telephone in a waterfall project does. Even so it's usually a lot more fun.

Why Agile Spreads Like Wildfire: Software Specifications

Charlie Rudd — Thu, 27 Oct 2011 21:12:00 GMT

The principle reason that Agile development methods have caught on like wildfire is that they address the root cause of most software development project failures: Unreliability of software specifications. To put it differently, if software specifications were as reliable as building blueprints, then the principle justification for investing in Agile competencies would disappear. Agile practices might still have value, but the argument that they should be the dominant approach used by the industry would be much more difficult to make.

With this in mind, it’s worth considering the question: Are software specifications inherently unreliable or is their uncertainty the side effect of something else? For example, maybe it’s caused by widespread failures in execution that are endemic to an immature industry. If lack of industry know-how is the problem, then one should expect that, as the software development industry matures, problems with software specification will gradually diminish and ultimately achieve the reliability of specifications in more mature industries (e.g. building blueprints). On the other hand, if there is something about the nature of software specifications that makes them inherently uncertain, then methods, such as Agile methods, that help us manage through uncertainty will be needed for a long time.

This is not a new topic. Perhaps most famously, Fred Brooks wrote on this topic in his essay No Silver Bullet, first published in 1986. He raised the question, why, although computer technology rapidly improves, the craft of computer programming has not kept up? Even after taking into account huge advancements that have been made through the introduction of things like higher-level programming languages, relative to hardware advancements, software development improvement proceeds at a snail’s pace. After discussing several reasons why software development is inherently difficult, he concludes that indeed, when it comes to software development, there is no silver bullet.

One of the difficulties he explores is the inability to visualize software systems. In other words, you cannot draw a picture of a software system that geometrically corresponds to all of its relevant functions.

For example, consider a blueprint of a building. Each element of the blueprint is in a one-to-one correspondence with some aspect of the finished building and at scale. With a bit of training, most people can project a pretty accurate vision of what the finished product will look like and how they might relate to it. Furthermore, information contained in the blueprint can be used to project an accurate 3-dimensional representation of the future building making visualization quite easy. Blueprints work because they represent buildings that are spatially fixed in three dimensions. Now let’s consider a software system.

Executing software does not correspond to anything that is spatially fixed. We can diagram elements of the software system but often the relationship between diagram and element is quite abstract and is not meant to map to anything physical. And though some elements have visual qualities, there is no unifying spatially-fixed structure that makes everything coherent or intuitively obvious. The following list of aspects of a computer system illustrates these points:

Computer topology (physical servers, workstations, devices, networks)
Application architecture (database, user interface windows and representations, servers, web services, browsers, etc.)
Data model (tables and relationships found in a relational database)
Business rules
Consider UML diagrams used to model the object-oriented design of the behavior and structure of software (that’s right there are 14 different diagrams).

Even after you add all these views together, your picture is still nowhere near as complete as the blueprint of a building. Software is much more complicated than a building, and unlike a physical thing it’s difficult (literally and figuratively) to get your arms around it. In addition, software is more complex than a building. Something that is complicated has many moving parts and perhaps a deeply nested bill of material. Something that is complex adapts and changes as it interacts with its environment and has behaviors that are practically (if not theoretically) impossible to exhaustively predict. In addition these interactions may cause unintended side effects, known as bugs. From a specification perspective, there is often no practical way to enumerate all the possible ways that a software system might behave as it interacts with users and other systems, before it is built. For these reasons, we can conclude that at least for highly interactive software systems, written software specifications that precede coding are necessarily incomplete and therefore inherently unreliable.

Agile software development anticipates the need to close the gap in software specification while the software is being constructed, since the spec can't be completed before you start.

PMI and Agile Practioners

Charlie Rudd — Fri, 30 Sep 2011 18:06:00 GMT

In my last post, I closed with the following:

The PMI has embraced Agile project management and is the first to admit that by doing so they enrich the entire project manager community of practice. Does PMBOK have anything to offer the Agile community of practice?

A great way to begin asking this question is to review The Software Project Manager’s Bridge to Agility. The authors compare the traditional (PMBOK) approach and the Agile approach to software project management. It becomes quite clear that for most of the traditional project management functions (e.g., scheduling, estimating, task management, etc.) there is a corresponding Agile approach. However, when it comes to how, who, when and to what degree these functions are performed there are big differences.

It’s also true that project management functions generally cannot be mixed and matched between the Agile and traditional approach.

For example, let’s consider the traditional approach to scheduling. You schedule all the activities that need to be completed for the entire project, usually at the task level. To schedule the tasks you need to know their duration, so task level estimation is necessary to complete the scheduling. You also need to know what work needs to be performed, so scope must be detailed enough to define work at the task level and scope must be fixed up front. Scheduling (and consequently, estimation and scope) all need to be completed before software development begins. This is because the schedule is the backbone of the project plan and as such will form the governance framework for the subsequent effort. The project plan is the law that governs the project, and the project manager enforces the law. Changing scope is equivalent to changing the law. That’s why change request approval may require the functional equivalent of an act of congress.

In the above example, we can see that the various project management functions are not easy to decouple. So if you choose the Agile way then you generally need to go whole hog.

If you went whole hog Agile and then adopted either PMI Agile practices or Scrum, would there be anything left in the PMBOK toolbox for you to consider?

Let’s consider one traditional practice. The weekly status report is an essential element of the traditional approach to project communications. However, it is often abandoned when a team goes agile. The reasons why include two key arguments:

Emailed weekly status reports are not read and the metrics they (traditionally) report on don’t effectively measure status anyway.
- Much more useful for understanding the true status of the project is the information available at any time by simply reviewing the charts and metrics that are prominently displayed by the team or by participating in the frequent sprint reviews, daily stand ups, and the like.
Conclusion: Rather than waste energy on useless email pushed out to stakeholders, simply invite stakeholders to inspect the team and work and see real progress measured in real time.

What might be wrong with this argument?

First of all, if the content of the status report consisted of Agile metrics rather than bogus metrics (e.g., percent complete on design), maybe there would now be a reason to read the email. But more importantly when we stopped pushing status out from the team, we shut down a communication channel and we replaced it with a new channel using a different mode (self-serve at the team site). What if the people we were communicating with don’t have the ability to visit the team? Who will make sure that these proceedings are available remotely? What if what the team is talking about is not what the stakeholder needs to know, when they need to know it? Who will take responsibility for these tasks?

If this is a new scrum team where the ScrumMaster was drawn from the development ranks and the business analyst designated as product owner is trying to master a new role and keep up with the team, the likely answer is nobody.

An experienced project manager would never make this mistake. She would have known that, although 20 of the 30 recipients will never read the status, the politics of the organization demand that they receive it. She would have known that certain metrics, as irrelevant as they are for noting project progress, are still a requirement to fulfill the corporate governance policy of this publically traded company. She would have known that three of the 30 recipients were vitally concerned with progress but would never be in a position to visit the team and needed information not in the status report, so regular conference calls would be needed. She would know exactly what the status report did and did not do. No one told her these things. She took the initiative to find them out because her experience told her that for this kind of project there would likely be these kinds of communication requirements. She would never have confused the artifact of the communication with the value of what needed to be communicated.

Unfortunately, there was no experienced project manager assigned to this project. The candidates who might have assumed these tasks, the Scrummaster and the product owner, did not because they were unaware there was any need, in part because they had no project management experience. If asked, "Don’t you need a project manager?", they might have answered,

“No, all the important work is done by the product owner, me or the team. All that’s left for a project manager to do is send the weekly status report, and we all know how much that is worth, right?”

Actually, no. Only the experienced project manager knows the real and limited value of the status report and other project management communication techniques. Similar arguments could be made about project risk management.

Let’s look at my manufactured controversy from another perspective. What we have is a conflict between two Agile principles. On the one hand we wish to avoid mechanically doing non-added-value administrative tasks because they are wasteful. On the other hand, we do everything in our power to strengthen the working relationship with our customer stakeholders. A judgment needs to be made that balances these two countervailing forces. And to make a good judgment call you need the practical knowledge, which we can always hope is a side effect of experience. With this in mind, let’s return to our PMBOK toolbox.

There are tools inside the PMBOK toolbox that can complement Agile practices, but the knowledge to use them is inside the heads of experienced project managers.

The PMI Agile certification unites the emergent Agile community with the traditional project management community of practice. And as they collaborate, they will share their experiences and learn from each other.

The PMI Agile Certification Indicates that Agile has Crossed the Chasm

Charlie Rudd — Thu, 22 Sep 2011 16:41:00 GMT

We hear a lot from our market analyst friends that Agile adoption has entered the mainstream. But how much faith can we really put in their words? After all, a big part of their mission is to make as big a market splash as possible for new ideas and concepts, especially when technology companies are eager to pay to position their latest, greatest mousetrap.

Certainly there are anecdotal signs of increasing agile adoption, but are Agile practices now mainstream practices? Has Agile crossed the chasm? And if a tipping point has been reached, how would we know? Well one big indication is the new Project Management Institute (PMI) Agile Certification.

The PMI is by far the world’s largest professional organization for project managers. It also takes the broadest view of the project management profession. As a non-profit organization that is mostly run by volunteers, its mission and every program it initiates reflect the interests in aggregate of the collective membership. So when this organization does something different, there could hardly be a better indication that something different has happened in the project management profession.

And what is new and different is the PMI Agile certification. First and foremost, the PMI exists to establish and sustain project managers as professionals and the cornerstone of its strategy to do so is the PMI professional certification. So when the PMI adds an Agile certification program it’s a little like the Catholic church changing Canon Law. This is all the more surprising given that the Agile movement formally began much like the Protestant movement did with the nailing of the Agile manifesto on the door of the Church of traditional practices -- a church with a Bible named PMBOK, the PMI’s orthodoxy of project management practices.

For many early Agilists, PMBOK was the poster child for what was wrong with project management. The Agile approach was the “solution” to the “problem” of traditional practices. One key example: detailed plan-driven projects, foundational to PMBOK, are anathema to the Agile way.

So the fact that these two movements are aligned indicates something significant has changed.

What have not changed are Agile practices and principles. They are the same practices and principles today as they were ten years ago at their formal inception. What has changed is that a much broader segment of the population recognizes the legitimacy and value of Agile practices. Agile practices are not a fad. Nor are they curiosity tools that a hobbyist buys on impulse and then tucks away but, like a screwdriver or a wrench, Agile practices are essential tools that project managers will use every day.

And once the PMI added the Agile certification to the PMBOK toolbox, Agile pracgtices crossed over into the mainstream in a very real way.

Scaling Agile: Building or Growing? (Part 2)

Charlie Rudd — Wed, 14 Sep 2011 20:41:00 GMT

In my last post, we discussed that when Agile values clash with the corporate culture, the effort to adopt agile practices will be impeded if not extinguished. We asked the question: Is there really anything you can do about this problem? After all, how do you go about changing the corporate culture? In this article, we will discuss what you can do to help your organization intentionally shift its values and culture.

I recently had the good fortune to discuss scaling Agile and related topics over dinner with Esther Derby and Diana Larsen, two of the most well-established business consultants in the Agile industry. What they had to say was encouraging. Not only can managers take action to improve conditions, they have the power to transform the corporate climate. One big idea: apply simple rules.

Simple Rules

Throughout the animal kingdom, the often complex and apparently intelligent behavior of animal collectives can be accounted for by applying a few simple rules. For example, a few simple rules can be used to account for the complex behavior a flock of geese adopts to retain an optimal flying formation under ever-changing conditions. Similar rules can be used to explain the behavior of insect swarms, schools of fish, and herds. Animals evolve these rules as real-time, adaptive responses to their environments.

Simple rules also apply to the world of corporate behavior. The good news is that people don’t necessarily need to wait millions of years for these behaviors to emerge before they can take advantage of them. We can choose to adopt them at any time. So what do these simple rules look like?

As Esther Derby has has written in her blog, simple rules “…are short statements that guide interactions and decision making within the group and across other groups within the organization.” One example she suggests is “Use every failure as an opportunity to learn.”

Diana Larsen remembered a dysfunctional management team that agreed to share appreciations at the start of each team meeting. Over the course of several months, negative patterns melted away. She was convinced that this one simple rule was instrumental in the team’s transformation.

Well-designed simple rules are easy to understand (they are simple!) and when they have the fractal-like quality of being patterns that apply at many different levels, simple rules have the potential to spread rapidly through an organization. And when these rules embody desired principles and values they have the power to transform the corporate culture.

Managers who advocate simple rules that reinforce Agile values and principles will never be on the wrong side of a “values clash”. When a leader in an organization invites a workgroup to “use every failure as an opportunity to learn” in an organization where failure of any sort has been taboo, she is opening what had been a closed door. And Agile success is all about opening up doors.

Managers like me were first drawn to Agile practices in order to exploit the extraordinary operational advantages. But what we learned along the way was that the operational power of these practices stems from the values and principles in which they are rooted. In fact, there can be no Agile value without Agile values. And Agile values won’t take root in an inhospitable corporate environment.

So when we talk about scaling Agile to the enterprise let’s not talk about building things. Let’s start by planting simple rules, the seeds of change that if properly cultivated will take root and grow throughout the organization. Then let’s stand back and watch our garden grow.

Scaling Agile: Building or Growing? (Part 1)

Charlie Rudd — Thu, 08 Sep 2011 16:00:00 GMT

When we talk about scaling “Agile”, are we thinking of economies of scale? What picture comes to mind? Is it one that involves “building” or “manufacturing”? Although these mental models are sometimes useful, they may do more harm than good when it comes to Agile adoption.

If we are “building” an Agile organization, then we may be thinking of processes, technology, and people as construction materials. And if we are treating people as material, then we draw perilously close to violating a fundamental Agile tenant — that the source of all value comes from thinking, breathing, creating people. This is in stark contrast to the idea that value is extracted from people in the form of labor. Labor abstracted as a fungible asset is a cornerstone of our manufacturing legacy. We optimize the value of people by applying economies of scale that allow us to achieve the lowest possible unit cost for their labor.

Too much of a traditional production mentality may head managers towards a “values clash” that could jeopardize the success of their Agile adoption. After all, in many respects the agile movement can be seen as a reaction against the de-humanizing collateral damage caused when organizations scaled up, while treating people as resources.

Many of us who have been part of large organizations have experienced a separation of interests from those of our employer. We joke about stupid and out-of-step company policies. We may blame distant executives or we may believe that they are caught in the same mindless trap that we are. Either way, we see no way out. It’s often much easier to find common cause with our immediate workgroup than with the organization at large. We may even find ourselves banding together to more effectively struggle against the larger organization that — ironically enough — impedes us from delivering the very value that we know is vital to the organization’s interest. In other cases, the CYA phenomenon kicks in. We search for safe havens within the organization and pursue our individual interests individually. Now an even grander irony unfolds: everyone performs their jobs meticulously but the broader program is doomed and fails.

Are these adverse conditions an inevitable consequence of size when organizations grow large? If the answer is yes, then we may have a real dilemma. If keeping things at the human scale, which is to say small and intimate, is integral to an Agile solution, then maybe the process of scaling Agile destroys its value.

Some leaders in the Agile community believe Agile practices cannot co-exist within large organizations. You can have one or the other but not both at the same time. This leads to the rather startling conclusion that to achieve Agile value you need to tear down large organizations.

It’s understandable that people develop this opinion. When we experience alienation and malaise in large organizations, we often also feel powerless to effect any change. But perhaps we go too far when we say that large organizations always squelch healthy human interactions. Some of us who work in large organizations report that life is good.

What most of us can agree with is that once the corporate climate is established it’s not easy to change. When that climate is inhospitable, managers may feel they ought to do something to make things better but may not be sure if there is anything they can do.

Well, maybe there is something that managers can do. In my next post, we’ll discuss tangible steps leaders can take to improve the corporate environment, while paving the way for Agile practices and values.

What is the Purpose of an Agile Maturity Model?

Charlie Rudd — Mon, 21 Mar 2011 06:16:00 GMT

Clearing up some semantic confusion

In my last post, my attempt to answer the question “What is an Agile Maturity Model?” did not get too far before we ran into potential semantic confusion with the term “maturity model.” We established that there are at least two types of maturity models, namely Lifecycle models and (tentatively) evolutionary models. Although they share the attribute of progressive phases, they also have important differences. The lifecycle models maturity as the aging process: Birth, growth, decline and death. The evolutionary model advances but does not decline or if decline does occur — unlike aging — it’s reversible. Since Agility is a quality that is voluntarily acquired and does not inevitably progress, the lifecycle model appears to be a poor fit. This allows us to reduce some semantic ambiguity by tentatively replacing the term “maturity” with the more narrowly defined “evolution.” Unfortunately there are also problems with the term “evolution.”

Although the term “evolution” is often used to denote progress, the biological theory of evolution is entirely devoid of this notion. Organisms adapt as needed to changing conditions in the environment. End of story. The statement that “humans are more highly evolved than other animals” is not based on science. So perhaps the term “evolution” is not the best fit, after all. So then what?

I proposed the term “progressive phases” in my last post as a common quality of lifecycle and evolutionary models. Can we use that term? Well, since we are being picky, the word “phases” has some issues. “Phases” of the moon starts us back on the lifecycle track and phase states (e.g., solid, liquid, gas) has (like evolution) no innate quality of progress. How about the word “stages”?

“Stages” means that changes take place in discrete, characteristically recognizable steps, which can be used to identify the subject’s current stage. For example, if a butterfly has wings it has reached its adult stage. Stages (for our purposes) are also successive (e.g., the pupa stage always precedes the adult stage of the butterfly). This is in contrast to change with unpredictable or arbitrary outcomes (e.g., evolutionary change). “Stages” is a better fit than “Phases.” How about “progressive”?

“Progressive” may mean that things get better as they succeed through stages. For example, each successive stage in Maslow’s need hierarchy represents a qualitatively superior state compared to its predecessors. Alternatively, progressive may mean moving closer to a goal. For example, in the case of the cognitive phases of a buyer (i.e., Awareness -> Interest -> Desire -> Action), although things succeed through stages, there is no payoff until the final stage. The term “better” matches our needs more closely than “closely” since we do expect things to get better as we progress through stages. Therefore we will restrict our use of “progressive stages” to mean “gets better and better in stages”.

We can avoid much of the semantic ambiguity of the term “maturity model” by substituting the phrase “model that characterizes the progressive stages (of something)”. Now we can now update our previous template for an Agile maturity model to the following:

A model that characterizes the progressive stages of something
(as yet undefined) that gets (measurably) more Agile.

We now find ourselves in a better position to consider the purpose of our Model.

More confusion

Turns out in addition to metaphoric confusion there is also the potential for confusion about purpose or, to put it more precisely, confusion between means and ends. Although the immediate purpose of an agile maturity model — to measure the stage of maturity that has been achieved — is clear enough, it is not very satisfactory. To obtain a more satisfying answer we need to link it to a further purpose. To do so we can employ laddering, a technique used in TQM to depict means-end chains.

The rungs of the ladder represent the links between means and ends. Whether or not a particular rung is viewed as a means or an end depends on if you are going up or down the ladder. When you go up, the current rung is viewed as the means to the rung directly above. When you go down, the current rung is viewed as an end to the rung directly below. As you go up the ladder the answer to the question “Why the current rung?” is provided by the rung directly above. And as you go down the answer to the question “How to achieve the current rung?” is provided by the rung directly below. Let’s now create our own ladder:

Starting at the bottom we can work our way up the ladder, while asking the question “Why?”

Rung		Purpose
1	Why an Agile Maturity Model?	Identify Maturity Stage
2	Why identify Maturity Stage?	Determine how Agile we are becoming
3	Why Become more Agile

Lets pause here for a moment and consider an article posted by Esther Derby entitled “Achieving Agility: Means to an end. Or end in itself”.

She points out that seeking to grow more Agile as an end in itself serves no useful purpose. Agility has utility only insofar as it serves as a means to obtain some business objective (i.e., an end). The broader purpose of our Agile maturity model then depends on the specific business objectives we are trying to obtain. Since each business has different business priorities the extended purpose of Agility (and our Agility maturity model) will vary from organization to organization. Therefore there is no point in asking questions such as “Am I more agile than Company B?”

It is also pointless to ask questions such as “What percent agile am I?” (or what Agile stage have I achieved) outside the context of specific business goals. In fact, these questions may be pointless even if they are attached to business goals.

First of all, progressive stages of maturity need to correspond to progressive changes in business objective performance. Secondly, although business objectives vary, the Agile stages must remain the same. If both of these conditions don’t hold, then the stages attribute of our model will also not hold. If the stages attribute does not survive our inquiry, our grounds for calling our model a maturity model become very shaky. It’s interesting to note that of the six examples of maturity models that are progressive stage models (numbers 2 and 8 are excluded as lifecycle models) listed in my previous post, four are criticized for having successive stages. The critics complain that if the stages exist they don’t necessarily take place in the prescribed sequence. One of the remaining two models, CMMI, offers both staged and non-staged versions, which suggests that “stages” are not a hard constraint. This is a change from CMMI’s precursor, CMM, which was a staged model and was criticized for being so. Since we are talking about it, it’s definitely worth remembering that CMM implementations were heavily criticized for being conducted as ends in themselves. Although engineering groups at considerable expense became certified as CMM Level 3, 4, & 5, the business at large did not necessarily improve. Even though CMMI has been designed to avoid this problem, justified or not it still suffers this criticism. This of course is the very problem that Esther Derby exhorts us to avoid.

So where does this leave us? Well, if we are going to hang on to the notion of “(successive) stages”, we need to come up with pretty convincing empirical evidence that these stages actually exist. And, if we fail, maybe it’s time to give up on the notion of an Agile Maturity Model. I think it’s interesting to consider that in our survey of models across several disciplines that were originally designed as staged models, most have subsequently been de-legitimized for being so. It makes one wonder if our underlying paradigm for progress is shifting from a staged paradigm to something else. If a more fitting paradigm for progress is emerging, maybe that is where we should be looking for a useful model. Something for us to keep in mind.

Getting back to Esther Derby’s fundamental point, whether we end up sticking with a maturity model or come up with a new kind of model, we will still need to convincingly demonstrate how the model is linked to business objective improvements, if it is to have utility. Something else for us to keep in mind.

We climbed up our ladder high enough to determine that the adoption of Agile practices should be linked to the higher purpose of achieving specific business objectives if advancement in Agility is to have any meaning. At some point someone should move further up the ladder to make sure that the business objectives themselves are linked to a higher purpose. In the world of commerce, the ultimate purpose that we find at the top of the ladder is to increase business value. Ultimately then our use of agile practices should be part the of a means-end chain that leads to the generation of business value.

What is an Agile Maturity Model?

Charlie Rudd — Thu, 03 Mar 2011 07:24:00 GMT

The topic of Agile maturity models is not new to the Agile community. For example, Martin Proulx of Analytical Mind recently published, as he says, ‘yet another agile maturity model” that provides an interesting discussion as well as additional links on this topic. Although periodically discussed, it is not at all clear that these discussions are converging toward a common definition. In fact, there seems to be a fair amount of confusion on this topic. What we really are talking about when we say we are talking about Agile Maturity models is not always clear.

Most of us would probably agree that the phrase “Agile Maturity Model” does not mean what it appears to mean. We really don’t mean the word “Agile” to describe maturity models in the sense that the word “blue” describes “blue cars”. So what do we mean by “Agile maturity model”? Do we really mean for “Agility” to be the subject of the maturity model? Do we really mean to say Maturity model for Agility?

At first blush this seems more plausible, but the answer is still no. We are not interested in the maturity of Agility as an abstract concept. Rather, we are interested in agility as a quality of something else. In particular, we are interested in “things” that mature in the sense of becoming more agile over time. From a practical perspective, it’s also important that we can clearly observe (i.e. measure) what we mean by becoming more agile over time.

So what we are really talking about is:

Maturity model for something (as yet undefined) that gets (measurably) Agile over time.

Now we might be able to say what an Agile Maturity Model is if we can define:

Maturity model,
thing, and
measurably.

I’d add “Agile” to the list except that I am afraid then you really would lose patience with me (if you haven’t already).

What is a Maturity model?

Let’s look at some examples:

Erikson’s (8) stages of psychosocial development: The developmental stages of a person — Infant, Toddler, Pre-School, Childhood, Adolescent, Young Adult, Middle Adult, Senior.
Metamorphosis, the four stages of a butterfly’s life: Egg, Caterpillar, Pupa, and Adult.
AIDA. Progression of cognitive phases for a buyer (Lewis): Awareness, Interest, Desire, Action.
ADKAR: The steps an individual takes in adopting change (Prosci): Awareness, Desire, Knowledge, Action, Repetition.
Team development (Tuckman): Forming, Storming, Norming, Performing, (added later) Adjourning.
CMMI for Development, Model for process improvement (SEI): Managed, Defined, Quantitatively Managed, Optimizing.
Hierarchy of needs (Maslow): Physiological, Safety, Belonging, Esteem, Self-Actualizing.
Industry life cycle stages (Anderson and Zeithaml): Introduction, Growth, Maturity, Decline

The first two examples describe aspects of how two different organisms mature. We can also apply maturity models to things that are not organisms (i.e. animal or vegetable) but have the organic quality of developing over time. For example, the term “industry lifecycle” (example #8) metaphorically attributes “life” to industry. When we cross the line from the literal to the metaphorical, we need to be careful. Although we can obtain a valuable perspective by viewing our subject from a perch within a different domain, there is also the danger that we project semantic noise along with the useful metaphorical abstraction that ends up obscuring rather than illuminating our understanding. For example, by adopting the industry lifecycle metaphor, we would not want to inadvertently set expectations that “parents” are pre-requisites for the “birth” of a new industry. Let’s delve into this a bit.

The hierarchy of needs and industry life cycle stage models (examples 7 and 8, respectively) represent different types of maturity models. The industry life cycle stage model represents all phases that all industries go through from birth to death, which we can term a life cycle model. In contrast, the hierarchy of needs model is not a lifecycle model because not all people complete the hierarchy and some complete it early in life. Let’s call this type of model an evolutionary model. Lifecycle and evolutionary models provide alternative maturity “patterns” that reflect the respective semantics of the underlying metaphors.

As we can see above, our evolutionary maturity model represents a progression to higher and higher states. The fact that higher levels are smaller suggests not everyone from the state below makes it to the state above. Below we can see that our lifecycle model is represented as a productivity rise and decline over time. In the evolutionary model only an elite subset make it to the top, whereas in the lifecycle model every industry proceeds through every level.

We have seen how two maturity models differ. What characteristics might all maturity models have in common? In light of our discussion so far, let me propose two:

Progressive Phases. There are distinct developmental stages that must take place in a specific sequence for each organism to mature.
Empirically verifiable change. The stage of maturity can be determined by observing characteristic changes in the subject’s features. Although not a requirement for maturity per se, we need this constraint if the model is to have practical value.

Metaphoric models and maturity models in particular provide plenty of opportunity for semantic confusion, especially if the purpose of the model is not clearly defined in the first place. We need to step away for a moment from our task at hand (defining the term “maturity model”, in case you have forgotten), to answer a different question first:

Why might we want an Agile Maturity Model in the first place?

This will be the topic of my next post.