A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.

Purpose and Community

2 Keys to a More Engaged, Productive Organization

blogimage_purpose-communityWhat’s your purpose?

Who do you share it with?

I believe these two questions point the way forward for creative networkers and successful organizations now and into the future.

Two years ago, while working for a large company, I had the privilege of collaborating with a small team of peers, real internal hustlers, to guide the implementation and use of Agile for a large, multi-year corporate initiative. While this was of course a serious responsibility, it was not our full time job. We were constantly searching for the necessary time to devote to it in order to ensure it would be successful. Despite this challenge, our group’s level of engagement and list of accomplishments was more significant than many of us had seen in a long time.

As I have reflected on this experience in the time since, I have come to realize that something deeper had occurred that led to such results. We had a clear and compelling vision with the autonomy and empowerment needed to make progress quickly. We knew what our unique and important purpose was in the organization. There was a small group of us that were committed to this purpose and beyond that to each other – we even had a secret name for our group and maybe a faux gang sign too. We definitely had that team “ba”.

Since then, the two concepts of Purpose and Community have continued to stand out to me as keys to unlocking greater potential in our organizations.


“The capacity for logical thought is one of the things that makes us human. But in a world of ubiquitous information and advanced analytical tools, logic alone won’t do. What will distinguish those who thrive will be their ability to understand what makes their fellow woman or man tick, to forge relationships, and to care for others.” ~Dan Pink

At a very young age, we begin talking about who we want to be and what we want to do when we grow up. Recently, I’ve enjoyed observing my niece, not even five years old yet, talk with great passion about food, recipes and being a baker when she grows up. My sister reports that when they go to a bookstore somehow my little niece-with-an-already-discerning-palate always finds her way to the cooking section and begins flipping through books page by page. Whether or not she will one day pursue the culinary arts is of course anyone’s guess – we all know that our career ideas and aspirations sometimes morph and change as we grow older. Ultimately, though, our search for purpose seems to be a constant throughout our lives.

That’s because we want to know that what we do matters.

Some years ago, as a new manager in corporate IT, I struggled with a lack of a sense of purpose. My team was responsible for a variety of important systems and applications but they did not seem to have any real common thread. That was until the day our new boss entered the picture.

Having the benefit of many more years of management experience, he was quickly able to see a common thread running through our systems from both a business and technology perspective. He moved quickly to define our team and its purpose and did so with startling simplicity and clarity. While team performance didn’t radically increase overnight, that clarity of purpose was the beginning of a laser-like focus for us on who we were and what we provided for the organization. It laid the groundwork for increased team engagement and performance in the long run.

That early management experience for me was formative, but my belief in the power of purpose isn’t based solely on my own experiences. More and more we are learning about the science and psychology behind purpose in our work. Recently, published results from a study by The Energy Project and Harvard Business Review showed that purpose was one of our most important needs at work and that when that need is met we are 1.4 times more engaged at work, 1.7 times more satisfied with our job, and more than 3 times as likely to stay with our organizations.

It’s becoming clear that the concept of purpose is quite powerful.

Put simply, purpose cuts to the very core of who we perceive ourselves to be, why we exist and what we should be doing with the very limited time we have given to us. When we understand our purpose and when our work is aligned with that purpose, we are poised to accomplish far more than we previously thought possible.

Having an understanding of the power of purpose, we might consider asking questions like:

  • What is my personal purpose?
  • Is my personal purpose aligned with my professional work?
  • What do my colleagues and team members perceive their purpose to be?
  • What is our team’s purpose within the organization?
  • Is our team’s purpose strongly aligned with our organization’s purpose?



“Organizations are communities of human beings, not collections of human resources”.  ~Henry Mintzberg

Just as we want to know what our purpose is from a young age, we also want to know others and be known by others. We are intrinsically wired for community, for sharing our lives with one another, our joys, our fears, our struggles, our successes. We bond together in family units and share the very core of who we are in these relationships. We come together for all manner of activities in life from athletics to academics to religious worship and more.

Why then do so many of our modern day corporate institutions feel devoid of a sense of community? Might we be settling for less?

It might help to revisit the definition of community:

a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals; a similarity or identity.

If you’re like me, you might have experienced this type of community a handful of times throughout your career. And these are probably the teams and experiences you remember the most fondly and speak of with pride. Typically though we don’t expect this kind of experience in the workplace. We expect and settle for the opposite – lack of meaningful connections, infrequent fellowship, fear and distrust run amok, disparate identities, and conflicting goals.

It seems to me that some significant contributors to this problem are a lack of awareness of the power of community in the workplace and numerous traditional corporate practices that are usually left unquestioned yet undermine or outright prevent the possibility of community. Some examples that come to mind…

  • Regularly creating and then dismantling project teams
  • Assigning workers to multiple project teams
  • Frequently shifting individual and team priorities
  • Vague sense of organizational vision at the team and individual levels
  • Creating individual performance goals that inadvertently pit individuals, teams and departments against one another
  • Treating professional craftsmen and craftswomen as resources, or more bluntly, easily swappable warm bodies
  • Narrowly defining people by their primary skillset (e.g. Java developer) and thereby limiting their growth, creativity and potential contributions

The list could go on.

I think it’s worth exploring what the idea of community means in our workplace because I’ve experienced its immense power on a couple of rare occasions. I’ve witnessed the deeper human meaning derived from work done in community, the improved relationships and collaboration, the lowered stress, and the resulting increases in team and organizational performance. I also continue to read stories and studies from companies like SpotifyBufferZappos, and others who are exploring this same path and experiencing similar results. I think organizations like this are onto something significant in the creative networker age.

If you’re interested in this notion of community, you might consider asking questions such as these:

  • Do I have a strong sense of community in my workplace? Why or why not?
  • If not, what could the idea of community mean and look like in our workplace?
  • How might a stronger sense of community improve our sense of meaning and our performance at work?
  • What might we together achieve if we had a stronger sense of community aligned to a common purpose?
  • What current notions and practices in our workplace might be undermining the possibility of community?

Success in the creative networker age hinges on understanding our purpose and who is in it with us.

What’s your purpose?

Who do you share it with?

Further Reading

Visualize your Purpose by Jurgen Appelo

Rebuilding Companies as Communities by Henry Mintzberg

Intermediate Agile: Focus on the Learnings

blogimage_intermediate-agileOrganizations that are moving toward Agility or have “been” Agile for a certain time period will go through a number of different stages as part of the transformation process. Let’s say, for example, that your company has categorized Agile into three separate categories (Beginning, Intermediate and Advanced). Your company believes that you both know and embrace the basics of Agility, yet you’re wondering where you should go next. Below you’ll find an intermediate Agile scenario and one definitive suggestion that may give you some ideas on how you continue your journey toward Agility, while not losing sight of the basics.

Different types of transformations and/or changes will take place at multiple levels within the company. Some of the more common levels include, but are not limited to the executive, divisional, managerial, and team layers. As many of us have seen, there are both common and unique aspects to the changes that will take place in each of these areas. For simplicity, let’s say the results of a recent company survey show that everyone has a solid understanding of Agile (and we’ll focus on IT for now). The poll shows very positive results in some key areas like:

1. Articulating the benefits of Agile
2. How Agile has made an immediate impact
3. Importance of self-organization
4. Belief that all work should be visible
5. Linking work products back to the company values and/or mission
6. Understanding why teams should remain together
7. What Velocity is really useful for
8. Knowledge of key Agile metrics
9. Knowledge and awareness of key Agile based charts/graphs
10. Belief that planning and communication cycles are important for success

The list above is short and definitely should not be considered to be an all-inclusive example. Regardless of the amount of time that you’ve “been” Agile, solid company scores in these areas above can be motivating and should be considered a great start. However, even with success, almost any organization will get to a point where they wonder what is supposed to happen next. As many of us know, Agile is not prescriptive. There isn’t a guidebook or travel manual for every company. The beauty of Agile is that it will allow a company to move at it’s own pace in order to “become” Agile based on it’s mission statement, company values and organizational culture. I have always been, and will continue to be a big advocate for organizations to focus on learning’s as they move into a more intermediate phase of Agility.

One aspect that I’m always looking for when working with organizations is their willingness to learn. Do they place as much emphasis on learnings as they do on the most recent deployment schedule, velocity graph or release burn down? Initially, many organizations don’t, but some will come to the realization that the “learnings” are just as important, if not more important, than the latest chart or graph.

Executive Learning

Executives that are not continually learning or pushing the Agile envelope forward will find themselves at a disadvantage with both their industry peers as well as their respective lines of direct reports with the organization. This type of learning doesn’t mean that members of the executive team have to know the latest development or quality assurance trend. It doesn’t mean that they have to be experts on Agile based tools either. It does mean, however, that they should dedicate time to conduct their own Agile based retrospectives in order to continually learn and adapt based on market condition changes pertaining to items like customer needs, competitive indicators or regulation/governance changes. As these changes occur, they should be able to work with their respective divisional leaders in order to inspect and adapt. Most companies that I’ve seen over the years don’t place an emphasis on taking executive time for continual Agile-based learning, but there are a few out there that recognize the tremendous benefits of doing so. Once a decision is made to make this time commitment, make sure that findings, discussions, results, etc. are made available to your entire company. This type of information dissemination will go a long way to helping others understand your perspective of what is happening at your end of the table. A suggested frequency for this type of activity would be three times per year.

Divisional Learning

If we stay on the IT track for now, your division could be broken up into multiple layers. For simplicity, let’s say that we’re only focused on four layers. Those layers are development, quality assurance, deployment and support. Most of the time, we direct our Agile efforts to the first two layers (development and quality assurance), but what if you took a division approach to Agile learning. Given that everyone above had such high poll scores, you may begin to expand your appetite for learning across the entire division.
Regardless of the number of products that make up your division, your VP could make a commitment to either conducting their own retrospectives or use a facilitator. The focus, like the executive learning above, would be placed on what good things were learned across the division as well as what bad things were learned across the division. A suggested frequency for this type of activity would be four times per year.

Managerial Learning

In my viewpoint, this is a section that very often gets overlooked. Many managers don’t know how to play in the Agile-based space because they feel that they are not needed with self-organized teams. This couldn’t be further from the truth, yet managers often don’t spend time working with other managers to continually learn and adapt. However, as your teams begin to self-organize in the beginning stage, managers often find themselves with more time to mentor and guide team members in lieu of running a command and control environment. In a few, very isolated examples, I’ve seen where managers conduct their own retrospectives on a monthly basis. The focus on the retrospectives takes on two forms. The first form is what learning’s are taking place at their specific teams. The second, and by far the most difficult, is what learnings are taking place at their individual levels. I’d suggest someone impartial to the management structure facilitate this. After all, who wants to look bad when there are ten of you competing for the next divisional promotion.

Team Learning

Agile teams are introduced to this concept from the very initial stages. Teams will begin understand the importance of their own retrospectives at the end of every iteration/sprint. Inspecting and adapting discussions and information exchanges are often very visible at the team level. As a result of these efforts, teams often experience two main improvements. Those are improvements to both quality and throughput. The team-based learning is one of the easiest to both conceptually understand and implement. However, a common aspect that can easily get overlooked is focus on taking action on improvements. If action isn’t taken, then the team will eventually see these types of activities as a waste of time. The most common frequency at the team level is at the end of every iteration/sprint. Yet, in some isolated instances, I’ve seen teams do “mini-retro’s” during the middle of the sprint and these yielded good results.


Going forward, the commitment to focus on learning is one that can be made at multiple levels within the organization. The information flow should be both circular and continual in order to realize the maximum benefit. The hardest part for many will be sharing the information, data, findings, etc. for which there has been failure. Yet, if either the organizational culture or it’s value statements have anything to do with learning, then understanding and implementing these types of concepts will yield huge results for your company today and for the organization as it moves into the future. Enjoy Agility for all it has to offer and focus on the learning….not just the story points and fancy charts.

Organizational Change, The Less Painful Way

I was watching TV the other day and saw a commercial for the Invisalign® teeth straightening system. The system gradually straightens your teeth over time “using a custom-made series of aligners created for you and only you.” Thank goodness is it created for only me. Using someone else’s mouthpiece would be pretty gross and would most likely result in a pretty ghoulish smile.Other than the slight lisp the user may have when first getting acclimated to this new thing in their mouth and having to remove the device when eating or drinking, it is pretty much invisible.

Every two weeks, the user gets a new aligner tray that makes slight corrections to the teeth. Overtime, these small adjustments culminate into a new, more confident you. Well, at least the models on the web site look confident.

I thought to myself what a great metaphor this is to implementing lasting organizational change. Introducing change, whether it’s agile in an organization or straightening your teeth, can be painful and how you introduce and manage the change can make all the difference. One can either use pliers to yank each tooth into the right position (not recommended) or nudge them into place through small, frequent changes over time.

The Invisalign® approach to change is very Kaizen in nature in that it uses continuous improvement to achieve a desired future state. Kaizen, as defined by our friends at wikipedia, is:

Japanese for “improvement” or “change for the best”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, business management or any process.”  - wikipedia

Real, lasting change takes time and energy. All too often organizations rush to become agile without considering what care and feeding is required to make it successful. Introducing Agile into an organization is a huge paradigm shift for traditional organizations and should be treated with the same rigor as any other change initiative.


A common approach to effective change management is the ADKAR model. ADKAR stands for Awareness, Desire, Knowledge, Ability and Reinforcement.

  • Awareness of the need for change.
  • Desire to make the change happen.
  • Knowledge about how to change.
  • Ability to implement new skills and behaviors.
  • Reinforcement to retain the change once it has been made.

Let’s walk through a typical Invisalign® example:

  • Every time I look in the mirror I realize that my smile resembles that of Austin Powers. (Awareness)
  • I am scheduled to be knighted by the Queen of England in 6 months so I need to look my best and I need a boost to my confidence. (Desire)
  • I research different approaches to straightening my teeth within the desired timeframe and realize that using pliers and painkillers won’t cut it. There is too great a risk of passing out due to pain and blood loss. I discover Invisalign®. Relief. (Knowledge)
  • I check my bank account to determine that I have the financial resources to embark on this change and I have the patience and fortitude to take this incremental approach. (Ability)
  • Once I complete the aligning tray process, I use the recommend retainer to sustain my smile and not have my canines pop back into their prior snaggletooth formation. (Reinforcement)

Taking a big bang approach to an organizational change is risky and has considerable risk of failure. Not only because it is painful (think pliers), but you may not see quick wins that reinforce the change process.

The J Curve Effect

Let’s turn to the J Curve Effect applied to change management to better understand this. The J Curve Effect is when current performance has plateaued and we introduce a change to improve performance.

In Jerald M. Jellison’s book, “Managing the Dynamics Of Change” he shows us how change undergoes a 5 stage process by using the J Curve principle:

  • Stage 1: The Plateau
  • Stage 2: The Cliff
  • Stage 3: The Valley
  • Stage 4: The Ascent
  • Stage 5: The Mountaintop

Stage 1 is the current performance level of the organization. You introduce the desired change in Stage 2. This causes a dip in performance. You then traverse the valley in Stage 3 as the organization learns the new skills and develops the new habits that will ultimately allow them to improve performance. However, this takes time. Eventually the organization begins the ascent of improved performance in Stage 4 until it surpasses the original productivity level and then increases to the desired level of performance of Stage 5, the mountaintop. The diagram below illustrates this process.


The major risk involved in this journey is how long the organization remains in the valley of Stage 3. The longer they reside there the greater the risk the organization will grow impatient with the perceived lack of progress and not wait for the desired change to come to fruition. One technique to address this risk is to adopt the Invisalign® approach. That is, implement a series of small, successive changes that are of short duration that result in a series of small wins and improvements that, over time, culminate in achieving the desired future state.


The implementation of successive small changes, or J curves, allows the organization to achieve overall improved performance in a less disruptive fashion with more lasting effects. Furthermore, members of the organization will no longer go weak in the knees whenever they see a pair of pliers.

Agile and Community Service

blogimage_agile-and-community-serviceJust the other day some fellow teammates and I volunteered at the Second Harvest Food Bank here in Charlotte and we made some rather cool “Agile” observations.

At the start of our volunteering shift we were given instructions from our guide, Anthony, to ensure the day was orderly and productive.  The instructions included how to examine the non-perishable items donated from local grocery stores, which included everything from canned goods and boxed items, to liquids and non-food items.  We were also instructed to ask as many questions as needed by just shouting out, “Hey Anthony!” Not a lot of formality there…Awesome!!

Once Anthony finished providing the instructions he asked if we had any other questions before we got started.  Since there were no other questions, next thing we did was (can you guess?) …SELF ORGANIZE.  Yep…..you guessed it…..self organize.  We decided as a team how we would approach this work.  We decided who would empty the box onto the table, who would inspect, who would sort to the correct bin, and how we would pair up.  We were given the flexibility to figure out what worked for us.  Sound familiar?

There were rows and rows of boxes filled with non-perishable items lined up across one side of the room.  The instructions were to take one box at a time, check each item for damage and sort it properly.  Only once that box was sorted and the damaged goods put in the proper place could you start on the next box.  What if, we went through all the boxes and checked for damaged goods before we sorted the first box into the proper containers?  Sound familiar?

The last thing we noticed was that the sorting area was divided into sections, dry goods, canned goods, canned soda, snacks, etc.  Once a particular grouping (i.e. snacks, sodas, etc.) had a palette filled with boxes 5 high and 3 deep they were removed from the sorting area to the warehouse where agencies could easily pick them up for distribution to people/families in need.  What if we waited until all of the food was sorted in the appropriate box before it was made available to the agencies?  Is this ringing a bell?

Not only were we discussing how “Agile” this process was, it was also a lot of fun!! This delivery method provided 40 million pounds of food and non-food items to people in need last year.

While we received 30 minutes of quick instruction from “Agile Anthony”, the rest of the 3.5 hours was about how we, as a team, could work together to be the most productive.  All while providing a quality outcome for thousands of people and families in need!

By the way, “Agile Anthony,” now Coach Anthony, was with us the entire time, cracking jokes, making observations, providing tools and removing impediments to help us be even more productive along the way.  Sound familiar?

​Maybe your next team building activity should include a little community service – you can brush up on your Agile skills while helping people in need!

Influencing Organizational Change

blogimage_influencing-organizational-changeWhether you’re piloting Agile for the first time or scaling Agile across a Program or Portfolio, at the heart of any Agile transformation is change. Regardless of the benefit of the change, a large percentage of the people impacted will naturally be resistant. Introducing Agile within an organization should be treated like any change initiative in order to increase the likelihood of success.

This webinar explores the use of the ADKAR change model to lead an effective and sustainable Agile transformation.  During this time we will discuss each step in the ADKAR model:

  • Awareness of the need for change.
  • Desire to make the change happen.
  • Knowledge about how to change.
  • Ability to implement new skills and behaviors.
  • Reinforcement to retain the change once it has been made.

We will also explore the J Curve Effect as it is applied to the change management process and discusses the 5 stages the organization must goes through to achieve improved performance.

This event takes place at 12:00 PM EST on Thursday July 10, 2014 and is hosted by Davisbase Managing Director, Tom Wessel.  Sign up now!

Becoming Agile: Slow Nickels or Fast Dimes?

blogimage_slow-nickels-or-fast-dimesI was touring homes with a real estate agent just a few short weeks ago and somewhere along the way we began talking about family backgrounds. His father was a podiatrist and lived during the era of radios, black and white TV’s, manual shifting vehicles, newspapers…and maybe a telephone. Many of us in today’s fast paced world might consider this to be a time of simple existence. There wasn’t an “app” for everything. People wrote letters when they had something to say and spoke with each other when they were together. TVs were a luxury that many couldn’t afford and kids played outside without wanting electronic gadgets to keep them entertained. I could go on and on, but there are tons of country songs out there that do better justice that what I can wrote down on paper. As we get older, some of us actually begin to realize that those “old people” who were ahead of our time had many experiences that we could all benefit from today. This day was no exception as a Agile based lesson unfolded during our conversation which may be a benefit to all of us as we go forward.

The real estate agent’s father, the podiatrist, lived his professional life by the mantra, “I’d rather have slow nickels versus fast dimes.” The mantra struck a cord in me as we were zipping down the interstate in our big SUV that had cruise control, air conditioned seats, power steering and movie system for the kids. When I first heard the mantra, I didn’t respond. I kept my eyes on the road and allowed the phrase to rattle around inside my head. Ten minutes later, I asked the agent what he believed that mantra meant to his father and I’ll paraphrase the story that he shared.

“Oh,” he said, “my father lived his life believing that he was part of the community in which he lived. He wasn’t looking for the most profitable patients, but rather the patients for which he could create a life long relationship with. He’d rather establish and maintain a patient population group by forming a reputation of service, quality and consistency at a fair price. The end.”

Wow, I thought to myself! A simple mantra like, “slow nickels or fast dimes” turned into a life long strategy in which the good doctor immersed himself in the community and built a successful practice. Having never heard this expression before, I asked the agent if it would be alright if I used the expression and story in an article that had just materialized before my mind’s eye. He said of course…this was an expression that wasn’t just indicative of his father as he’d heard it quite a bit growing up as a child. Excited with ideas, I reflected back on memories with my grand-father as this was an expression that I’m sure he used during his time.

Accidentally Twisting the Term

This is an excellent expression that companies should talk about when they are considering to “Go Agile”. What’s more this is an expression that companies should continually monitor when they have “Become Agile”. The simple expression contains a lot of meaning; especially if we look at it from two different points of view.

Going Agile

Going Agile: As organizations consider “Going Agile” many of the benefits are quickly and easily understood at the executive level. Executives understand the importance of key terms like:

a. Delivery consistency
b. Self-organization
c. Build quality in
d. Customer business value
e. Small / Incremental Releases
f.  Steady pace
g. Sustainable teams

For me personally, I can identify where these key terms equate to slow nickels in lieu of fast dimes. Consistency and predictability are concepts that many individuals and organizations can identify with.

Becoming Agile

Becoming Agile: On the other hand, once organizations begin their Agile journey the expression can quickly become twisted. The expression begins to change from “slow nickels vs. fast dimes” to “fast nickels vs. slow dimes”. Once the initial training is over and teams begin to produce working software, a subtle shift can easily begin to take place. Teams, managers, customers and the organization like what they see at the end of every iteration/sprint. They’re hooked. They want more. The success that they see can be very addictive. More is better. It’s like a child getting their favorite treat…more, more, more. Before anyone can pinpoint what’s exactly what’s happening everyone…and I mean everyone….begins to focus on things like:

a. Number of features, Epics, etc. that we’ll include in the next release
b. How fast are stories getting closed?
c. When is the next integration push?
d. When can we do a press release because marketing needs something now?
e. What can we share at our next big Webinar?
f.  When can sales get the application on their laptops?
g. Who, from development, is going to support our sales team?

Whoa! This list could go on and on and lead the company down a path of self-destruction if not properly monitored. As students of Agility we should continue to monitor if any of these behaviors are beginning to surface within your organization. If so, you may have accidentally twisted slow nickels vs. fast dimes into fast nickels vs. slow dimes, which may need the company to take some immediate action.

Ironically, for those of you who have any experience in real estate may have heard that “Fast Nickels vs. Slow Dimes” resonates with many agents as quick cash flow (even if smaller numbers) is a preferable way of doing business. Interesting that I had both perspectives right in front of me and didn’t even know it.

Are You Practicing Quixotic Agile?

chaos order diverge shutterstock_66320608

In our hurry to ‘do Agile’ let us not forget why we are doing it and where we are going.


Quixotic means to be impulsive, often rashly unpredictable and impractical.  It also means idealistic and un-realistic.  Why does this term matter you may ask?  Whereas the energy and perseverance of the romantic, idealistic quixotic mind can give us courage and stamina to try new things, the flip-side of that is the rashly unpredictable and impractical commitment to the wrong things in wasteful ways and disappointing results. If, in their enthusiasm to do Agile, the team skips through Agile planning and principles and goes straight to starting a sprint, then it is like Don Quixote who set out to fight dragons only to find himself jousting with windmills. Thus their quixotic effort; although enthusiastic, will probably fail to deliver.

I have the privilege and opportunity to work with many teams who are striving to implement and improve Agile. I witness the struggles and challenges teams face while adopting this powerful model for team-based development. Many organizations view Agile as a solution, perhaps even a silver-bullet that will enable them to quickly deliver maximum value to their customers. But in a rush to “do” Agile far too many teams end up doing it in a way that is impulsive, unpredictable and even unrealistic – the result is what I call ‘Quixotic Agile’.

What is Quixotic Agile?

‘Quixotic Agile’ is impulsively “doing” Agile (sometimes simply to be able to say we’re doing it) or applying Agile practices in an unpredictable way. During this early romantic period where we fall in love with notion of ‘Agileness’ and pursue some vague definition of Agile based on our intuitive ideal of what the word agile means can be dangerous to the long term transformation to an truly agile organization.  Teams without proper instruction and perhaps coaching will take short cuts and pursue the easy path.  The consequences of this can be hidden for a while because talented and smart people will tend to get something done regardless of obstacles.  Whether that something was worth doing in the first place is questionable. In this circumstance the team’s performance may temporarily seem to improve but will quickly result in lower performance.  This is a well-documented phenomenon by Dr. Satir (search the Satir performance improvement curve). We should not rely on our enthusiasm for the process or methodology while forgetting that our goal is not to do Agile but to find better ways of delivering valuable working software to our users. Agile is not a silver bullet and when done carelessly, can actually make teams more chaotic.

Agile has a strong appeal for teams with a quixotic personality.  The flexibility, the promise of improved performance and ability to do what you want, how you want, when you want is alluring. A typical Quixotic agile scenario plays out when leadership has mandated a move to agile this year without the budget or support to re-organize or to get a coach.  The result is an Agile project managed using waterfall tools, inheriting substantial waterfall process but using agile terminology and conducting a daily status meeting that the team declares as their standup. These teams will skip many agile practices, ignore the principles, and hopscotch straight to planning a sprint. Perhaps these teams have the impression that to simply do Agile means they are Agile or to adopt a few agile practices will result in marked improvement…it’s not that simple.

The reality is that teams will plan and do something – anything – to stay active and busy. Parkinson’s law is that, “work expands so as to fill the time available for its completion” if the business hasn’t defined and prioritized enough valuable work to fill our sprint then teams will fill their sprint with something.  A quixotic team will soon find themselves scrambling to assemble enough work for a sprint and possibly filling up the sprint with some work of their own invention simply to fill the time. This creates waste in the process and product while at the same time developing a false sense of productivity. By approaching a product this way they quickly lose sight of fundamental Agile principles such as: technical excellence and good design, delivering valuable software continuously and maximizing the amount of work not done.  They will inevitably tend towards a short-term perspective and short-term planning model – only planning sprint-by-sprint, technical excellence is compromised due to a failure to see the larger picture. The compulsion to plan a sprint worth and work fast can result in ad hoc development and gold plating.

Five Levels of Planning: Vision, Roadmap, Release, Sprint, and Daily

Visit http://www.davisbase.com/resources/agile-tool-kit/  for an Agile Quick Facts downloadable PDF

How can an organization capitalize on the new energy of becoming agile, transform in to an Agile team, continue to deliver valuable working software to their users and customers and avoid the mistakes of failed agile efforts?

How can a team NOT become quixotic?

The key is simple. Do the basics! Begin at the starting line rather than skipping to the finish line. The team should pay their dues and learn the process. Take a few lumps early but learn from them.  Look back to the philosophy and principles for guidance in defining the purpose of the practices and process. Do not rely merely on reading and intuitive understanding of the word agile.  Get some training, and if possible, hire an experienced transformation coach early rather then an agile medic later.  As a team, start with the Agile planning and collaboration process. There are five levels of Agile planning that make Agile teams successful – not only in their production process – but also in their transformation.  A disciplined team (yes agile requires discipline) will begin by following a well proven path and process as they gain their own experience and discover better ways of applying agile principles; whereas, a quixotic team might jump straight to sprint planning while skipping over vision, roadmap, backlog development and release planning.

Turning a team from quixotic agile in to a high-performing team requires focus and attention and regular reinforcement of agile principles and practices rather than simply al-a-cart adoption of a few practices.  High performing teams will prepare, execute and improve.

Each team will certainly tailor how they apply agile; Quixotic agile teams will often attempt to be all-inclusive and tolerant of all practices but we should a bit selective and we should not attempt to blend all things together.  Trying to please all possible processes will result in a fragile and unsustainable model. A team who does this will rapidly digress to ad hoc or possibly worse, chaos and failure. The successful high performing team will most certainly discover their unique agile formula.  Their unique recipe should be designed to take full advantage of Agile practices and principles. Agile teams can implement Scrum with XP or Lean practices very effectively.  They can organize around a Feature Driven Development division of the backlog or a DSDM process segregating pre-project planning from development from post-development phases. They could adopt preferred development practices within the Scrum framework. Or organize around a Lean value driven approach.  The point is to choose something, practice it, and make it as good as possible.

A final note regarding our teams: There are many reasons for project failure, but lowest among them (less than 5% of the time according to the Standish group research) is due to lack of capability of the team. Remember or realize rather, that these teams are usually comprised of very talented, motivated, educated and experienced people. The reality is that regardless of methodology or practices, these people will usually find a way to get something done.

Regardless of which custom recipe for agile that is used, the successful teams will still follow the pattern of Agile planning and preparation becoming predictable, focused, driven and productive.

4 Things Healthy Agile Teams Do

“If you don’t take time to be healthy, you better plan on taking time to be sick”


A conversation today with a web developer regarding effective story writing reminded me the importance for a team to plan to be a healthy team.  We don’t get healthy in our personal lives by sitting around talking about exercising or eating better—we change our activity habits, our diets and we set goals to be achieved.  Last year I started wearing a Fitbit Force “wearable tech” health band.  My activity level, based on the steps it tracked, was about 2,500 steps per day—I don’t “have time for exercise” and I feel tired and physically lousy most days—my lack of energy affects my family and we have more “sick days” either me or my kids (which also affects the parents because we have to stay home too).  I needed to change my habits and improve my health.   I set the wristband to alert me every hour I didn’t have any activity (getting up and walking around) and I looked for new ways of setting and accomplishing healthy goals such as “walking meetings” where either 1:1 or small groups would go outside the building and walk while we talked rather than sitting in a conference room.  Every few weeks I moved my goals on the band upward—first to 5,000 steps, then 7,500, finally 9,000 steps.  I take great pleasure in the band alerting me when I reach my goal and I’m reminded that being healthy prevents me from being sick—being sick costs a lot of time.

What do good agile teams do?

  1. Good agile teams take time to improve their skills.  There are years of bad habits, old fears, departmental rifts that have to be overcome.  They enjoy the retrospectives, a time to reflect, inspect and adapt.
  2. Good agile teams know each other because they ask questions and truly care about their teammates.
  3. Good agile practices, like writing great user stories, take time to learn but the learning curve is within the power of the team to control.
  4. Lean Coffee and similar time-boxes of free-thinking discussion or concentrated mini-workshops to improve the team’s skills should be built into every aspect of the culture of a team.  When a deficiency in team dynamics or skills is noticed—discuss it as a team and “get healthy”.

Don’t wait for someone in management to come along or for the project quality to slip.  Failing to take care of the health of your team will force you (at the most inopportune time) to “take time off to be sick”.  This may come in the form of failing to complete your story commitments, struggles with your product owner for effectively written user stories, poor estimating, or simply a team who does not enjoy working together.

So, “If you don’t take time to be healthy, you better plan on taking time to be sick”.  #BecomingAgile.

Blow-up the Iron Triangle: Rethinking Software Project Approaches and Goals to Increase Business Value

Everyone agreed the organization needed change. The IT department had lost another leader from the top job. After going through four leaders in about as many years, the question was, what kind of leader would be coming in next?

The original IT leader did not have many processes and didn’t believe in project management. If you were connected or had friends in the department you could get something done. Conversely, if you didn’t have the connections, you didn’t have much chance of being heard. Let’s call this leader “Cowboy.”

Cowboy’s replacement brought in great people and best practices. It was easier to be heard if you could figure out how to get your idea through the process. The work was more organized with Project Managers and Analysts and loads of paperwork. And meetings, there were many, many meetings. This leader lasted for a few years and we will call him “Process Heavy.”

The next IT leader said the process was too heavy and we needed a new, lightweight method. Scrum was introduced to developers and the staff was reorganized from departments into teams. The new method was held onto so tightly any variance or deviation was shunned and cast aside. The teams were happier and the business liked getting small bits of work more quickly. Unfortunately, the new process brought a confusing new vocabulary and large projects never finished. This leader is the “Developer’s Friend” and he lasted for much less time than his predecessor.

The fourth IT leader felt like a breath of fresh air. “We should be a bit more flexible with our process,” he said. And the business liked when he told them “Yes.” He told all of them yes without a way to give them what they wanted. So the staff with less process had more work. And the business eventually tired of hearing everything is okay when they could not get results out of IT. This leader will be “Yes Man.” He didn’t last very long at all.

No one in the department was willing to guess what the next leader would be like. They were willing to open a betting pool on how long he would last though.

All of the IT leaders above wanted to do a good job and help the business achieve meaningful success. They all want to enable their staff to meet the business needs. “Cowboy” thought he was being responsive to the business by avoiding overhead. “Process Heavy” added vital tools for both project selection and increasing the chance of project success. “Developer’s Friend” gave programmers a better framework for building things right and increasing project success in an entirely different dimension. “Yes Man,” like his forerunner “Cowboy,” was trying to be responsive to business desires. Despite their similar intentions, these leaders offered inadequate solutions for the challenges they faced. None of them added the value their customer needed.

The traditional view of software delivery projects is a fundamental part of the problem. This paper explains the shortcoming of how IT departments look at work and concludes with an integrated solution for increasing value and business satisfaction.

Why is IT struggling?

The forces pushing IT departments to change are multi-faceted yet we have continued to address most everything with the Iron Triangle of Scope, Schedule, and Cost. This response has been a largely inviolate part of not just projects, but IT’s approach to every challenge.

Forces of change threaten to overwhelm us

Pressures to triumph in the marketplace are greater, the rate of change is accelerating, and the opportunity for your competitors to leapfrog past you with new technologies – from social media to big data – grows daily. If you consider the example of software products, AOL reached 1 million user in 9 years. Facebook reached the same milestone in 9 months. And recently introduced Draw Something reached this threshold in about 9 days!

Within organizations projects are failing, investments are over budget[i], waste feels rampant, and very few people understand the expected or resulting ROI. Chief Executive Officers list technology as their #1 concern worldwide.[ii] Meanwhile, prevailing processes continue to inhibit change within the organization. The Economist reports, “The main obstacles to improved business responsiveness are slow decision-making, conflicting departmental goals and priorities, risk-averse cultures, and silo-based information.”[iii]

Combine these factors with a talented workforce desiring to be appreciated and heard[iv] and the roar for change can be deafening. The Iron Triangle works well in some circumstances, but rapidly deteriorates as the rate of change increases.

We confuse Strategic and Utility IT

IT stands alone in with its regular need for large capital projects too often characterized with poorly conceived goals and ill-defined benefits. In part, this stems from confusion between strategic and utility IT services. IT departments provide both service types without understanding the differences. Ross Pettit explains, “This is not a separation of IT by the nature of the technology, but into what technology does for the host business.”[v]

Consider a replacement Inventory Management system for maintaining a retailer’s inventory levels, orders, sales, and deliveries. This software may be cloud-based or internally hosted, integrated with RFID tags or not, developed in-house or purchased from a vendor, etc. Either way, it provides a basic service for organizing inventory data and controlling stock levels. Not having an inventory management system will hurt your business, but having this system does not add strategic value. Replacing an old inventory management system with a new one is unlikely to give you a substantial increase in market share. Worse, if you do not have goals for how this will impact your vendor interactions, inventory turns, or bottom line and then quantity the project success against those goals, there will be significant doubts if the project even added value. The inventory management system is a utility service.

On the other hand, some IT services qualify as strategic. Projects allowing your business to catapult over competitors are strategic. Investment banks are willing to invest multiple millions of dollars to enact trades faster. The transaction speed in this circumstance is strategic. Especially for the first bank able to trade faster than its peers.

An important point to remember in settings of competition and change, is today’s strategic service is tomorrow’s utility. When all of the trading firm’s competitors can trade at the same speed, then the strategic value is replaced with utility value. It is still required, but it no longer provides a strategic impact to the firm. More, if the utility is not maintained, the firm may need to spend strategic-level amounts of money to catch up to peers. The size of this expenditure, however necessary, is a cost of doing business rather than strategic investment.

Another reason IT departments are less effective is because business executives do not adequately understand this difference. The dividing line between these types of services and projects may be grey and the rationale for better utilities may be filled with grand prose and grander numbers, but treating these projects in the same way is inefficient. Martin Fowler alludes to using the Iron Triangle incorrectly when he writes, “The way you staff, run, and budget a strategic project is entirely different to how you do a utility project. Too often people assume that what is good for one is good for the other – and trouble inevitably follows [emphasis added].”[vi]

We measure and reward project success incorrectly

Traditional project delivery has centered on defining the project and producing to the entire scope. This approach generally introduces waste and unnecessary costs into projects, pushing for understanding based upon needs for today’s environment and focusing on complete solutions. It is unreasonable to expect competitors and government regulations to stand still while projects are analyzed and developed. Today’s businesses move too fast for this.

Tom DeMarco, who famously wrote, “You can’t control what you can’t measure,” recently explained this oft quoted line has the wrong implications, that control may be the most important aspect of a software project. He now states “…the more you focus on control, the more likely … (your) project … (will) deliver something of relatively minor value.” Following this, he states:

“For the past 40 years, we’ve tortured ourselves over our inability to finish a software project on time and on budget. This never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”[vii]

Successful projects are often met with recognition and bonuses, especially for project managers and executives. “Success” being defined as producing the initial project scope on time and in budget. We are rewarding the same behavior we are measuring, control. This reward system drives teams to finish projects for the wrong reasons, because they want the monetary reward and recognition, rather than adding the value we need today.

The implication in DeMarco’s statement is the last four decades have favored those goals and projects that are easier to control. When the IT department aims for projects that can succeed within the boundaries of the Iron Triangle they do not reach great success. These projects may be good for the both business and benefit individuals, but they rarely transform the business or customers.

How can IT be more effective?

We need a different solution for this challenge. The correct response encompasses a number of changes to how we view projects. Teams need a new toolset to handle the work before them. Going forward, we must recognize more than achieving negligible scope statements, choose projects for learning and impact, and build for long-term success. This needs to be accompanied by incentive models that recognize control is not our best gauge for achievement.

We need to pick the right model

Jim Highsmith has already given us a new model for viewing projects. In Agile Project Management, he suggests depreciating the traditional Iron Triangle.[viii] The real goals of projects is “producing value that delights customers, building in quality that speeds the development process and creates a viable platform for future enhancements, and delivering within constraints.”[ix] Viewing the Agile Triangle, it is obvious the traditional view is still important, but as a set of controls rather than the primary focus.

The Agile Triangle


The Agile Triangle concentrates attention on releasing products adding value to users and developing sufficient quality for today and tomorrow. Shifting priority from constraints to value and quality gives more weight to what is being delivered than how it is delivered. This change does not mean the how’s of delivery are unimportant. Rather, the how’s need to take a back seat to why we are developing software. The reason for software developmentblogimage_blowing-up-the-agile-triangle is not software itself. The reason for software development is to provide some other benefit via the software!

Deliberately shifting from producing the entire project scope to making small, meaningful differences results in systems with less complexity that are easier to maintain, update, and fix. With smaller, higher quality code bases, there should be a corresponding maintenance cost reduction for the life of the system.

Existing compensations and reward systems will need reevaluation because they create pressure to maintain the status quo.[x] New reward systems will prize the ability to critically assess a project based on factors of learning, delighting customers, and adding bottom line impact.

Customers will find their needs satisfied much sooner with these changes than the traditional project end date.[xi] Highsmith reports clients delighted with only 20 – 30% of the originally anticipated functionality.Moving from the Iron Triangle to the Agile Triangle allows us to change the notion of value from, “Have we completed the project scope within schedule and budget?” to a more useful question, “Have we obtained enough value to redirect our investments to something else?”

We need governance focused on delivering value

IT Portfolio Management ensures resources are properly allocated across projects and business needs. This conversation starts before a project gets to IT with understanding of the corporation’s strategic goals. With this knowledge, the aim of governance becomes ensuring IT is aligned and adding the appropriate value.

Aligned with the Agile Triangle, governing with transparency allows IT and business leaders to act on the delivering the highest value while considering changing business needs. This transparency includes the business’ estimate about value received to date versus the cost, and expectations about future value and cost. This system will put vague and unsupported claims under greater scrutiny and simultaneously recognize halting marginal projects is not a failure, but a savings.

“Process Heavy,” the second IT leader did the organization a favor by adding IT Portfolio Management. With this addition, the business had a framework for talking about what projects were needed and why. He brought in metrics measuring success and built a strong team. Unable to make changes fast enough, he did not add all the tools required for larger, lasting success. Adding governance without the corresponding ability to nimbly adjust to changing conditions is a partial solution.

Similarly, “Developer’s Friend” changed the environment for development teams and gave the IT department new tools, allowing for a nimble response and improving employee morale. Done well, these changes move software development from a hit-or-miss exercise to one where developer productivity is constant and the output is “built right.” Unfortunately, he lost support when the process became more important than the project and goals. Adding delivery without maintaining governance is inadequate.

The solution is adding proper governance to an environment skilled in quickly creating working software. While the focus needs to be on producing value, the environment must accommodate change in response to the business environment. The best use of IT Portfolio Management includes realizing value while projects are ongoing, before reaching the end of their planned timeline.


IT departments, leaders, and projects struggle because of a historical reliance on the Iron Triangle. It is not the right tool for dealing with rapidly changing and extremely competitive corporate environments. The implications have left departments focused on control when we needed experimentation and learning to achieve business-changing goals. Repeating what we have done before, we measure and then reward the wrong behaviors.

Effectiveness does not have to ephemeral. Using the Agile Triangle and good portfolio governance, this paper presents a solution centered on a fundamentally different outlook for IT activities. These interlocking concepts combines value with quality, control with reward systems, governance mechanisms with transparency, and skilled employees that incrementally deliver value. The astute IT leader is beginning to embrace this view.

While divergent from traditional thinking, this proposal builds upon experience gained over the last two decades. These ideas are already being tested on a piecemeal basis within organizations. Each idea succeeds on the strength of another. No one idea, standing alone will meet business needs. Combined, this approach elevates projects out of bad control loops and into meaningful contributions. There is a revolution around the corner for IT projects, impacting business leaders and strategy alike. The next strategic advantage from IT may not be software, but how it views projects and contributes to the business.


[i]Standish Group. “CHAOS Reports.” http://blog.standishgroup.com/.

[ii] IBM Corporation.  “Leading Through Connections: Global Chief Executive Officer Study.” May 2012. http://ibm.com/ceostudy.

[iii] The Economist Intelligence Unit, The Economist. “Organizational agility: How business can survive and thrive in turbulent times.” 2009. http://www.slideshare.net/EMCsoftware/the-economist-organisational-agility.

[iv] Mike Myatt. “10 Reasons Your Top Talent Will Leave You.” Forbes, Dec. 13, 2012, accessed June 26, 2013, http://www.forbes.com/sites/mikemyatt/2012/12/13/10-reasons-your-top-talent-will-leave-you/.

[v] Ross Pettit. “Separating Utility from Value Add.” July 09, 2010 blog post. http://www.rosspettit.com/2010/07/separating-utility-from-value-add.html

[vi] Martin Fowler. “UtilityVsStrategicDichotomy.“ July 29, 2010 blog post. http://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html

[vii] Tom DeMarco. “Software Engineering: An Idea Whose Time Has Come and Gone?,” IEEE Software Magazine, July/August, 2009.

[viii] Jim Highsmith. Agile Project Management: Creating Innovative Products, 2nd edition. Addison-Wesley Professional, 2013.

[ix]Highsmith. “Beyond Scope, Schedule, and Cost: The Agile Triangle.” November 14, 2010 blog post. http://jimhighsmith.com/beyond-scope-schedule-and-cost-the-agile-triangle/

[x] Felipe Furtado, Gibeon Aquino, and Silvio Meira. “Improving Organizational Performance Through Reward Systems,” in Business Dynamics in the 21st Century, Dr. Chee-Heong Quah (Ed.), InTech, May 2012.

[xi] Standish Group, ibid. Studies have shown up to 60% of software functionality is rarely or never used!

The Failed Agile Adoption Pattern

“Failure is not fatal, but failure to change might be.”

~John Wooden

I often think about patterns of success and failure in life. What is it about certain people, teams, and organizations that make them successful over others? Why do others, despite seemingly good intentions, fail? Is there anything we can learn from these failures?

As a coach and consultant of Agile change efforts, I am always on the lookout for patterns of success and failure. As in most other areas of life, I’ve seen that success with Agile requires a lot of hard work and that it helps to have someone with deep experience coaching you along the way. And similarly, I’ve seen that there are nearly endless opportunities for failure. Of course, this shouldn’t be surprising – an Agile change effort is fairly significant as it involves the complex intersection of many people, processes and tools. That’s messy!

But while there may be many different ways such an initiative could fail, there is one pattern of failure I have seen and heard of so often that it is worthy of the label, “The Failed Agile Adoption Pattern”. It is so common that I believe it needs to be more widely acknowledged and accounted for by all partaking in an Agile change initiative.

The pattern looks like this:

  1.    Workers are largely disengaged
  2.    Agile Adoption is dictated from the top down
  3.    Minimum (Not So) Viable Process is implemented
  4.    Inspecting and Adapting rarely or never occurs
  5.    Few if any tangible benefits are realized

Let’s explore each of these steps in a little more detail.

Step 1: Workers Are Largely Disengaged

Gallup’s “State of the American Workplace” in 2013 showed that7 out of every 10 workers are disengaged at work. Only 30% admit to being fully engaged at work, while 52% admit to being disengaged, and an astonishing 18% admit to being actively disengaged. Think about that. Potentially 20% of your organization is knowingly acting in ways that are counterproductive to the organization’s goals.

If you were thinking Step 1 of this pattern didn’t apply to your organization’s Agile initiative, you were likely wrong.

And that’s where the failure pattern begins – lack of awareness of this problem, lack of willingness to admit this problem is real and is affecting your organization, or lack of willingness to dig into and address this problem.

Step 2: Agile Adoption Is Dictated From The Top Down

For any number of good reasons, management decides the organization needs to pursue Agile. Unfortunately, management often sees this as primarily a team-level pursuit and so instructs those below them to “adopt Agile”. Their presence and engagement is limited to the kickoff of the initiative  while the teams are left to struggle with the challenges of the change effort.

There are two main problems with this approach:

First, your workers are already disengaged. Major change initiatives will likely be met with cynicism, if not outright, active resistance.

Second, Agile is not simply a “process for the developers and testers to adopt.” Agile will eventually require you to rethink everything from project, program and portfolio management, to staffing, to team design, to organizational alignment, to performance management, to budgeting, and beyond. Agile is a transformative journey and therefore requires active, engaged leadership from those with the positional power required to enact real change. Anything less than fully active engagement from management and the chances of success will be greatly reduced.

Even at this early point, the failure of the initiative is already highly likely. It is not the final nail in the coffin though as I have seen some cases where the principles of Agile brought about a renewed sense of autonomy, purpose, and mastery and thereby increased worker engagement. This increased engagement was enough for the organization to realize moderate team-level success. It should be noted however that these were outlier cases and the success was constrained.

Step 3: Minimum (Not So) Viable Process Is Implemented

Step 3 is the natural outcome of the previous two steps. When the workers realize that management is not willing to bear the burdens of change alongside them and actively lead, they will do the bare minimum necessary for management to be convinced the teams are “doing Agile now”. In some cases, they will actively resist and try to torpedo the initiative. Yes, this is insubordination. And, yes, I’ve seen it happen more than once.

The irony of this step is that the workers determining which practices to keep and which to throw out are the ones least qualified to make such decisions. In fact, even highly experienced Agilists tread carefully when altering known, proven frameworks and methods.

Step 4: Inspecting and Adapting rarely or never occurs

As Amber Deibert recently illuminated in her post, “Steering the Agile Ship”, a foundational principle of Agile is the need for frequent inspection of results and adaptation in order to continue improving. This cycle of inspecting and adapting cuts across both your product(s) and your process. The idea is that Agile is not so much of a destination. It is not a new process or tool you simply install, wipe your hands of, and declare, “Done!” It is more akin to an endless journey, a pursuit of a better state than where you were yesterday, a week ago, a month ago. It is animated by the guiding thought that “we can always do better.”

Unfortunately, for teams and organizations that have progressed through the first three states, this fourth state is almost guaranteed to happen. Inspecting can feel like a waste of time for those unaccustomed to regularly reflecting on their work despite research demonstrating an average of 20% performance improvements. And adapting often requires team empowerment and/or positional power to apply changes to team and organizational processes. So this part of Agile gets tossed overboard early and often. And it is usually the final nail in the coffin.

If you are currently in this state, you can be rescued through a renewed engagement of management and a vigorous commitment to frequent inspecting and adapting. But this is no small task and will usually require outside expertise (i.e. self-rescue is very difficult).

Step 5: Few if any tangible benefits are realized

Lacking an awareness of the actual root problems of the change effort, an organization having progressed through the first four steps will eventually come to believe that Agile must be a fad or that they were too unique for Agile to apply to them. Failing to see any tangible benefits they will proclaim that Agile failed. The sad reality though is just the opposite – it was their own efforts that led to the failure. In fact, most any other process, tool or methodology requiring significant change in their organization would be just as likely to fail.

In closing, there is an underlying, false belief embedded in this pattern that sets an organization up for failure from the beginning. It is the difference between an Agile adoption and an Agile transformation. Adoption implies installing and following a new process or practice whereas transformation implies leaving the old and becoming something completely new and different. Transformation speaks not just to the mechanics (process & practice) of how we work, but ultimately to how we think and talk about the work. We should look, feel, think and act fundamentally different. It might be like deciding to radically change your golf swing (transformation) versus buying a new driver (adoption).

If we understand this difference, it will lead us to think and act in much different ways than the five steps in this pattern. And that would be a much better place to start an Agile journey.

Have you seen this pattern of failure before or similar ones? Are you potentially in the middle of such a pattern right now? We would love to hear from you – please join in the conversation by commenting here or on twitter @joshfruit and @davisbase.