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.

Continuous Improvement Through Retrospectives

Agile RetrospectiveAgile teams use retrospectives in order to tune and adjust behavior, but when is the last time you’ve taken a moment to retrospect on retrospectives?  Join Leslie Morse, one of our Managing Directors, for a FREE 1-hour webinar on this very topic next Thursday, September 4th at 12:00 ET.
She will cover the importance of retrospectives, the various levels they occur, different approaches for conducting retrospectives, and recommendations for keeping track of a team’s improvement backlog.  
Attendees of this webinar will also get the first access to our new Coaching Guide for Retrospectives which includes:
  1. Why are retrospectives important?
  2. Substance and Spirit
  3. Who should participate?
  4. Preparing for a Retrospective
  5. Establishing a Safe Environment
  6. Facilitation Versus Participation
  7. Making It Happen
  8. Discovery Question for Rich and Meaningful Discussion
  9. Handling Personal Conflict
  10. Potential Pitfalls and Disruptions
  11. Retrospectives Mean a Commitment to Improve

Sign up Now!

An Intro to the Scaled Agile Framework

yogi-berra“The Future Ain’t What it Used to be!”

One of many classic quotes from the great Yogi Berra – and this one hits home when thinking about the future of Agile.

Yogi was also heard to say, “It’s tough to make predictions, especially about the future”, but Gartner and PMI may be the most credible exceptions, when it comes to prognostication in our field.

Gartner predicted that Agile methods would be used on 80 percent of all software development projects by the end of 2012, while PMI’s research shows that Agile project management tripled from December 2008 to May 2011. Top reasons cited for this growth include significant decreases in defects, improved team productivity and increased business value – Agile results, as advertised.

So, what’s next? How about planning and budgeting to effectively support this kind of growth? Enterprise-level Agile is coming your way and the Scaled Agile Framework® (SAFe) is your path to success at this level.

SAFe is the framework needed to scale Agile to the Enterprise level and effectively support teams by planning for the bigger challenges of funding, integration, architecture and role adjustments at scale. Based on proven Lean principles, further defined for Agile by Dean Leffingwell, SAFe addresses Agile at scale by enabling organizations to adopt Agile principals at the Program and Portfolio levels – beyond and in support of Team level efforts.

Successful adoption of SAFe starts with identifying a value stream, or activities sequenced to deliver consistent value to customers. An identified value stream can be worked as an Agile Release Train (ART – the vehicle that delivers value at the program level). Options to consider when identifying initial value streams may include early adopter programs with executives that are positioned and ready for transition.

The place to start exploring SAFe in more detail is http://www.scaledagileframework.com. Peruse the Big Picture. Drill down into each of the topics that pique your interest. When you’re ready for more in-depth training on SAFe, contact Davisbase. Our certified SAFe Program Consultants can get you to the next level so that you’ll be positioned for a predictable Agile future.

One last Yogi-ism as you consider SAFe and the future of Agile: “You’ve got to be very careful if you don’t know where you are going, because you might not get there”.

3 Ways to Keep Your Standup From Being a Status Report

standupThe daily standup is intended to be a planning session, not a status report. This is surprising to many since the first question is the status of what you did the day before! Many teams as a result fall into the status report habit and don’t get the benefits of an excellent standup: early impediment identification, self organization, and the efficiency of a whole-team approach.
Here are three approaches that can help break your team if they are stuck in a standup status situation:

Wear a Name tag

Have your scrum master wear a nametag to standup, but instead of their name write “DO NOT LOOK AT ME” in big letters.
People tailor their words to their audience naturally and subconsciously.  Encourage your team to talk to each other by encouraging them to look at each other at the daily standups.  Listen for “oh yeahs” here — “Oh yeah, Susan!  You’re going to want to know about this…”

Skip Roll Call

Does someone “call roll” by announcing who should speak next at your standup?  Are they the ScrumMaster?  Skip this step by having each team member ‘call on’ who should talk next.  This technique gets your team thinking about who is affected by what was shared, and since you can only call on those that haven’t spoken, keeps team members on their toes and engaged during everyone else’s updates.  This is especially effective for distributed teams doing a call-in standup!

Ask, “Who Cares?”

In order to help team members identify the right questions and the right people, try a fourth question in your standup: “Who cares about your work today?” This helps anticipate problems with handoffs and assistance.
For example, consider this interaction between Pamela the programmer, ScrumMaster Mark, and Tommy and Trisha the testers.
Pamela reports that a programming task will be completed today.  Mark prompts her to answer the fourth question: “Who cares about that?” Pamela identifies that she expects one of the team’s two testing specialists to pick up the testing that is now ready.  But Tommy and Trisha, after a glance, say that they won’t have time today or tomorrow to do that work!  Pamela realizes that her time is better spent on another more pressing task.

Trying It Out

The best way to bring these tricks into your team is at retrospective.  Ask your team: Are our standups planning sessions or status sessions?  Use the list of benefits from the top of this article (finding impediments, enabling self-organization, supporting a whole team approach) and see if they resonate.  If not, ask the team to come up with their own list of benefits from a less-status-more-planning approach. Once everyone agrees that there is a problem, then introduce these three ideas, and change them as needed or even create your own. And if you do try them, remember to review the change at your next retrospective.  And also let us know how they worked for you!

What the US Army Taught me About Agile Teams

417262_187430241371796_466345890_nQUICK: What is the first thing that comes to mind when you think about Army life?

Command? Control? Structure?

If those terms came to mind, you would be correct…to a degree. (Remind you of anything? Like, WATERFALL!)

When I enlisted, I was shipped off to the glamorous Ft. Sill, Oklahoma. Oklahoma in February is not pleasant.

My first memories of moving “across the tracks” from reception to 1/40 FA (Delta DAWGS!) consisted of freezing temps, carrying heavy duffels for what seemed like a million miles, and the shark attack.

For those of you who have never been in the military, the shark attack is something that is burned in the minds of those of us who have. The military life is new, you’re a little scared, and then these guys and gals in big brown hats start screaming at you, spitting in your face, and you’re doing a lot of pushups.  You’re not sure why, but you are doing A LOT OF PUSH-UPS!

All of the insanity is meant to do one thing: teach teamwork. The group went through something incredibly transformative together, and those experiences bonded us for life. I still keep in close contact with many of those guys today.

While it may not be quite as dramatic, new Agile teams will go through similar emotions. Teams will experience the fear of something outside of the norm, the transformational stages of forming, storming, norming, and performing. Although difficult, if the team embraces the challenge it will turn into an incredibly positive experience.

After the initial training courses, a funny thing happened: our opinions and input started to matter. Even though we were not the most experienced guys on the team, the more seasoned soldiers recognized that fresh eyes often catch things that the most seasoned guys overlooked.

Consider the similarities in the Agile model. Instead of a tech lead or senior developer assigning requirements to the team, the entire Agile team discusses and collaborates on each and every user story. The thoughts of even the most junior developers are valued and considered as much as the senior developers. Just as I have seen junior enlisted soldiers point out potential hazards (that could have cost lives if overlooked), I have seen junior developers turn complex architecture into simple solutions.

The point is: change is never easy. Regardless of if the transition is from civilian life to military, or from waterfall to Agile, the journey will be full of hard days and incredible victories. Let me assure you that it is worth it.

You will have more fun at work, you will be less stressed, and you will even stand to improve your home life as a result of a better work environment.

I challenge all new Agile teams out there to heed the words of Drill Sergeants Williams and Shoemaker: work hard, keep an open mind, respect the person next to you, and in a few months you will wonder why you ever thought ANY of this was difficult.

You can do it. Your team can do it. Hang in there.

You will be glad you did!

Agile (Cookie) Development

Can Agile Development Practices Produce a Signature Cookie Recipe?

Debbi Fields, Wally Amos, and I have something in common: we each have our own distinctive cookie recipe. Of course, their brands, Mrs. Fields and Famous Amos,are household brands; whereas, my cookie is just notorious among the relatively small number of people who have eaten my cookie.

By way of background, I’m a formally-trained chef with an economics degree and a knack for leading agile teams in designing software and solving complex problems. Software development lets me exercise both my right and left brain, but I’d really love to go the route of Debbie Fields and Wally Amos: if not with my cookie recipe, then with any of the other signature recipes I’ve got up my sleeve.

Iterating Towards a Recipe

I’ve been working on a cookie recipe for years, and it’s taken a somewhat Agile approach. You may say I’ve been working on the user story, “As a chef, I want to create a cookie that’s so delicious and distinctive that people will crave my cookies and pay me to make my cookies for them.”

I didn’t start out by doing a bunch of math formulas and writing down what I felt was the perfect recipe.

Instead, in preparation for the first batch, I weighed out the basic chocolate cookie ingredients (flour, baking soda, sugar, brown sugar, salt, vanilla, butter, eggs, and other super top secret ingredients) in grams. I made sure I had more than I needed, but minimized the amount I’d have to put back into a container or waste.

I also didn’t include chocolate chips because they’re expensive and I just needed to see how the dough portion changed in the oven: how was the spread? was it chewy enough? did it rise the right amount? The chocolate chips would contribute significant expense to my experiments without adding much information about the final output. If you consider that the chips were part of a “Chocolate Chip” user story, they were ranked lower priority; they were a feature that could be added later with minimal rework of the first set of stories.

At this point, all I had was a vision for the cookie.

Release Planning

Once I had my ingredients weighed out, I started the typical process: creamed the butter with the sugars and salt, added the wet ingredients, and then started adding the dry ingredients. I added by a fair amount of my allotted flour, mixed it in, then inspected it. I added a few spoonfuls more and inspected again. When I thought I had the right consistency, I baked it to see how it turned out. After two or three iterations of this process, I arrived at a result I liked and I wrote down the difference between the initial ingredient measurement and the remaining amount of the ingredient. This formed the basis for my recipe.

During this phase, my measurements weren’t at all precise: it was a gut feeling. If fact, I intentionally didn’t measure because I didn’t want to subconsciously add amounts that conformed to what I’ve been taught are “ideal” butter:sugar:flour ratios for different types of cookies.

At the end of this phase, I had just enough information to allow me to perfect the recipe and move to the next stage. My measurements were accurate, but not yet precise.

Sprint Planning

On the next batch, I started from my written recipe and purposefully and thoughtfully tweaked percentages of ingredients to adjust specific ratios of ingredients (flour:butter:sugar). I delved deeper into the details, and worked until I had measurements to a precision of 0.1g.

At this point, I had a very solid idea of what I wanted to make, and I was confident I had enough information to bake exactly the cookie I wanted to make.

Sprint Execution

Here’s where my current journey ends. I’ve been in sprint execution for awhile. Each time I bake a few dozen cookies for people, I’m executing sprints and doing sprint reviews with various friends, family, and coworkers. Gathering input, hearing what people believe is good or bad about the cookie, and potentially making changes in the next sprint.

Each batch is potentially shippable. I’m closer to knowing what it would take to make the cookies production ready, but I’m not quite there.

Release Overhead

If I were to take my cookies to the next level, I’d need to do some performance load testing.

The recipe is perfect right now: it’s repeatable and produces the same results. My unit tests tell me that the recipe is working on a small scale, and user acceptance tests have shown the quality is correct.

However, my ingredients have a maximum of four significant figures, because I’m only measuring less than a kilogram of any ingredient to a precision of 0.1 gram.

Let’s say my recipe calls for 302.5 grams of flour, and I want to make my cookies for the masses, so I need to make a 10,000x batch. The 302.5 grams I’m measuring may in reality be 302.5124. If I were to make a 10,000x batch, the recipe wouldn’t be right unless I used 3,025,124 grams of flour. It may be close, but it wouldn’t be perfect.

Once that final piece of testing and preparation for launch is complete, there’s only one step left: launch the product.

Agile Principles Have Broad Application Possibilities

Agile development principles can be applied to just about any problem. Even if the Scrum ceremonies aren’t present, the Agile process can be applied to iterate towards a desired end result. One of the key parallels in this analogy is that the level of precision increases at each step. With the cookie recipe, I’m getting ever closer to knowing the actual recipe with a much finer precision at each step. At some point, if I were to go into business selling my cookies, the recipe would be known.

In a software development project, we get ever closer to knowing the actual delivery date, features, and cost of the project at each step. Once the project is delivered, those three things are known. If you find yourself thinking about how many hours something will take to do during the Release Planning phase, you’re likely too deep into the weeds and it’s time to pull back. You’ll figure out how many tenths of a gram of flour belong in the recipe when it’s time. For now, just make sure your general ratio is close enough.

Scaling Agile

SAFe_BigPic_3.0_MediumAs organizations move beyond implementing Agile at the team level, the need to scale across multiple teams within a Program or Portfolio grows.  Scaling Agile requires a greater degree of structure, governance and measurement to support this effort.

This webinar introduces strategies for scaling Agile, including Scaled Agile Framework (SAFe), within an organization and how to create traceability from a business strategy to value creation at the team level.

We will take you through the origin of the Scaled Agile Framework and cover the foundations that anyone interested in scaling Agile needs to know.  These include:

  • Accelerating value delivery
  • SAFe Core Values
  • Goals: Speed, Quality, Value
  • Lean Pillars: Respect for People, Product Development Flow and Kaizen
  • Lean Foundation: Leadership
  • Scaling to the portfolio and program levels.

This event takes place at 12:00 PM EST on Thursday August 7, 2014 and is hosted by Davisbase CEO, Steve Davis.  Sign up now!

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!