Five Tips for Improving Communication

Communication is the key to solving problems and successfully collaborating, but many of us still have difficulty communicating with particular team members. Why?

Because the words we use mean different things to different people in different contexts.
Matt Badgley, an agile product consultant at VersionOne, recently gave a presentation at Agile Day Atlanta about communication techniques you can use to solve problems and improve team meetings.


VersionOne: Why is it important to focus on the words we use?

Matt: We all know that collaboration is the key to success. Ultimately, solving a problem is generally done by people talking to each other and working things out. Solving problems often happens inadvertently, through conversations.

So that’s why communication is key, and communication is made up, of course, of verbal and nonverbal cues. The same goes for the role of ScrumMaster. So, if you are in the role of product owner or ScrumMaster and you’re not good at facilitating communication, you are not going to be successful. So that’s why it’s really important.

When you actually talk about what words mean, you will find that certain words in certain organizations trigger emotions. They are bad words. They are basically four-letter words that are emotional for people. So you have to be aware of that. You will also find that there are some terms that mean one thing in one context and something totally different in another context. For example, epic is a word we use all the time in agile. And even the word project means different things, and it actually evokes different feelings in people.

VersionOne: In your presentation you shared some fun facts about communication – can you share those with us?

Matt: One of the most interesting statistics is that women speak roughly twenty thousand words per day on average, while men speak on average seven thousand words per day, and we all have around twenty-five thousand words in our active vocabulary.

Generally, we say between one hundred to one hundred and seventy-five words per minute, although we can listen to up to eight hundred. That is why we can often eavesdrop on other people’s conversations and gain insight. Our conscious minds can only process about forty bits of information per second, which includes colors and things like that. However, our subconscious mind, which deals with our motor skills, processes around eleven million.

One last little fun fact: the word that has been shown through studies of the brain to be the most dangerous in the world is the word no – probably because we learn that word at a very early age and get our hands slapped. So if you say no in a conversation, that instantly turns the context of the conversation around, or changes the tone. This just goes to show that the actual words we use are often undervalued and can mean so much more.

VersionOne: What are some of the ways you suggest for people to solve that problem?

Matt: In my presentation I make five suggestions.

1) Don’t redefine the obvious.

For example, when talking about requirements, we often use the word feature or capability. Now the scaled agile framework refers to requirements as a business epic or a feature epic. You’ll hear different terms that people throw out, just simply to change the term. So, be very deliberate on whether or not you need to change a word or not.

2) Be deliberate and intentional.

If you make the decision to change a term, be deliberate and intentional about using it. For example, the Spotify model uses the word squad rather than team. Squad makes you think of the military or a small group that is a subset of a sports team. A team is a bigger composition, but a squad is a smaller and more intentional group of people. By redirecting and changing people to use that term, it has some underlying meaning that’s beyond the word team.

3) Be aware of biases around a word.

Bias is a preconceived feeling around certain words. A funny one to use is the word ScrumMaster. The term master has some bias behind it, some predefined bias that people bring into the room with them. It’s not always perceived how it is meant to be, although ScrumMaster does actually mean the master of the scrum process, the sensei. At the end of the day, that bias can be dangerous. So be aware of the bias.

4) Use domain language.

Use the words that the business uses already. This suggestion goes with number one: don’t redefine the obvious, but also don’t go out of your way to use a word that’s not unique to your industry. Accept and embrace some of the acronyms that are associated with the industry. For example, in the agile industry, we use the term product owner and sprints, so embrace those kind of words.

5) Use visual elements when defining a glossary.

It may sound strange to create a visual glossary, but the idea comes from how we learned words as kids. You learned the word apple because you saw a picture of an apple. Defining ways in which people can not only read the word, but also visualize the word helps things stick.

Check out these posts to learn more about how you can improve your communication by focusing on what words mean.

Posted in Agile Leadership, Agile Project Management, Agile Teams | Leave a comment

The One Thing You Must Do this Morning to Achieve Your Goals









We all have goals, yet many of us don’t meet them. Sometimes this is disappointing, but more often than not the bar just kind of moves down, time passes, and we become complacent.


Because it is pretty tough to stay focused for long periods of time on “Big Hairy Audacious Goals”.

So what can you do to meet your goals?

Just like it doesn’t work to wait till the end of a release to power through the requirements in a traditional waterfall, it doesn’t work to wait till the end of the day to power through your tasks. Instead of powering out of the day, focus on powering into your morning.

I once heard a CEO tell his company a story to motivate them. It was January and the year was just kicking off. He said “If we want to meet our annual goals, we have to meet our quarterly goals. If we want to meet our quarterly goals, then we have to meet our monthly goals. In order to meet our monthly goals we have to meet our weekly goals, and to meet our weekly goals we have to win each day.” He said to forget everything else and just win the day. He then went on to explain the origin of the mantra.

If you follow college football, you may be familiar with the Oregon Duck’s mantra “Win the Day.” Most football coaches at whatever level preach about just focusing on the next game and not looking past it. When Chip Kelly began coaching at Oregon, he began preaching for players to just “win the day” because he believed the team needed to strive to win at every sprint, study session and scrimmage in order to win the next game.

This story and mantra resonated with my agile roots. Agile is rooted in focusing on the day to achieve the end goal. Agile’s foundation is built around not over planning to meet the final goal, but taking each day as it comes and responding accordingly. Stand-ups are all about teams winning the day.

Truthfully, as inspiring as this story was, I had come to forget about it till the other day when I was working out at the gym and listening to a podcast in which an author was discussing their book The Miracle Morning. The book is about six practices people can do every morning to be more productive, successful and happy. During the interview, the author started talking about the “how to win the day” mantra and how, if you want to win the day, you have to win the morning.

This snapped me out of my workout. On the surface, it would seem that the author just took something successful and took it one level down, but to me it was brilliant and once again aligned to my agile roots.

At work we are so often bombarded by firefighting that we fail to focus on our original goals or tasks. Agile, of course, employs story cards and stand-ups to combat these and other distractions. Most teams hold their stand-ups in the morning to kick the day off right.

Despite all of this, I had never thought about these practices being designed to help us win the morning so that we would win the day and ultimately win the end goal, but that is what they do. So, now I want to think about other things our teams can do first thing in the morning to ensure that we win the day – because to win the day, you have to win the morning.

Posted in Agile Leadership, Agile Management, Agile Project Management | Leave a comment

A Simple Approach to Get Stronger Agile Executive Support

Exec Support








If the leading business literature from the past couple of years is to be believed, leanness and agility have become must-have characteristics of any company that expects to thrive. Yet, lack of executive support is consistently reported to be a primary reason that enterprise agile transformations are unsuccessful.

How can this be? If agility is essential to an organization’s business success, how can executive-level support of the adoption of agility throughout the enterprise not be a top priority?

As perplexing as that is, here are some things we do know:

Just the Facts

  • Executives have limited time to take on more.
    More than 60% of the executives surveyed by the Standish Group reported that they spend less than 5% of their time on executive sponsor responsibilities related to the projects that they already own.
  • Executives aren’t focused on the same things that most agile practitioners talk about.
    When is the last time you heard your CEO talk about ATDD, story point normalization, or team empowerment?
  • Executives are accountable for business outcomes.
    Growth, profitability, cost containment, and business strategy development rank high on the list of things that keep CxOs awake at night.

Missed Opportunities

The struggle these days usually isn’t in convincing executives of the general benefits of agile. By now, they’ve at least heard about it or read about it. The challenge lies in connecting agile values, principles, and practices to their needs in a compelling-enough way to convince them that leading fundamental change in the way their organization thinks about and goes about its business will be worth the effort.

Most agile champions and practitioners have limited opportunities to influence executive leadership. And when the right circumstances have presented themselves, we typically haven’t done a very good job of advocating agile as a means of achieving business outcomes. In order to gain enthusiastic executive support, we’re going to have to maximize our opportunities by effectively talking about agile in the context of their needs and responsibilities. They won’t be into agile unless there’s something in agile for them.

Reframing the Discussion

You can use the three-component approach below to help you talk about agility more effectively at the executive level. This can close the perceived gaps between agile’s capabilities and the challenges that executives are focused on. The three components are:

  • Message (a relevant statement of the challenge): says “I understand your needs”
  • Methods (what we can do to meet the challenge): says “I can help you”
  • Measures (how we’ll know that what we’re doing is working): says “I can prove it”

Here’s a familiar example from the bottom-up perspective (you can probably already do this one in your sleep):Lee's post

Message: “I understand that you’re frustrated at how we consistently plan more than we can do, which leads to unrealistic expectations and missed deliverable dates.”

Methods: “Why don’t we limit our commitment to how much we’re really getting done? That way, we can set realistic expectations as to how much we can deliver within a given time frame, at a given level of quality.”

Measures: “We can use the observed velocity trend to determine how much we can commit to. We’ll continuously update that trend, and investigate the causes of any negative trending.”

That’s just an introduction to velocity-based planning, and applicable to somebody directly involved with planning and delivering software. But in order to get the attention of executive leaders, we have to communicate in terms that really impact their world.

The skeleton of that discussion looks like this:

Message: “I understand that we are facing [higher-level business challenge]…”

Methods: “[these agile practices] can help. Here’s how it typically works [no agile jargon – use their language]. Here’s an example: [quick example of what ‘xyz company’ did]”

Measures: “These are the simple metrics we can track to know that it’s working…”

Here’s a fleshed out example:

Message: “I understand that we are facing increasing costs of developing our software, and that this is impacting our overall profitability. A significant factor in this is the amount of test and re-work churn we have during the development cycle.”

Methods: “Test-driven development and continuous integration can help reduce that expensive churn. The development teams continuously build and test small changes in a version of the finished product, allowing them to immediately catch and correct anything that isn’t working the way it should. That eliminates long, expensive integration and test phases. XYZ Company adopted these practices and reduced their overall cost of developing software, while gaining higher quality, and increased sales. And they achieved that without having to hire additional people.”

Measures: “In order to verify that our efforts are working, we can measure the trend in feature cycle time – how long is it taking us to get features completed and delivered to our customers? We can also track the trend of how many defects we are releasing to our customers. Both trends should go down.”


Now I realize that some might see this as a myopic approach, too focused on a particular set of practices and not focused enough on the values and principles behind them. Remember, though, that if questions are asked, there’s nothing preventing me from, say, further explaining the impact of these practices on throughput and how that affects both the revenue and cost components of the ROI equation. What I’m trying to accomplish here is simply flip the light switch on. We can talk about voltage, current, resistance, and luminosity later.

Of course, the flawless execution of this technique won’t guarantee that the executives in your organization will become agile fanatics. But they certainly won’t embrace agile if they don’t perceive it as a means of meeting their business challenges.
The point here is to be prepared with the right message, and with the methods and measures to back it up, when the opportunity to influence your executive leadership presents itself. Give it a try, and let me know how it goes!

Posted in Agile Benefits, Agile Executive, Agile Leadership, Agile Project Management, Agile Teams | 1 Comment

An Agile Team Task by Any Other Name – A To Do

Sprint Planning HellLet me first say, I know the idea of task decomposition is fairly well covered and some might call it a basic practice of any team; however, as a coach helping teams to adopt agile software development, I don’t always see teams finding this practice of defining “how to get to done” as a natural team planning activity. Instead, I see teams getting frustrated with a clunky approach or a high-level of disengaged team members or a member of the process police controlling the meeting that is distinctly a team meeting or I still see the “lead” define the tasks and simply dole them out.

Defining “How” to get stuff done as a team should be the straightforward activity around software development. It should be an engaging activity of brainstorming, learning, sometimes arguing, and ultimately a good feeling of “let’s git’r done.” All-too-often it seems like a torture technique riddled with challenges. These challenges are often rooted simply in poor practices, some of which include:

  • Creating faux work breakdown structures (yes, I said it — WBS) of standard tasks (e.g. each story has “Design”, “Code”, “Review”, “Test”, “Deploy” tasks). Some would argue this is not a poor practice, but tasks should have context and be relative. Not to mention, this is kind of mundane, requires no thought, and is flat out lazy and contrived.
  • Focusing on the accuracy of hour level estimation. If we are consistent with relative estimation and looking at cycle time, we can come up with the “low risk” and lean approach to determine which stories to work on. Estimation at this level is more of a measure of certainty.
  • Creating tasks and tests that are ginormous — like a 40 hour task for a two week iteration. If someone tells me that it’s going to take 40 hours, then I view that as high risk and we need to keep talking about it to better understand it.
  • On the other hand, creating micro tasks — yes, so many that the Task board looks like a sticky note factory exploded on the wall or invoke pagination within the tool.
  • Having the developer and tester creating tasks and tests in isolation without any conversation with each other or the rest of the team.
  • Oh yeah, let’s not forget when I get asked about reports that measure how underutilized people might be. Often the focus of understanding “How” becomes simply an exercise to maximize utilization.

That last point about utilization, it seems like a frequent driver of the planning exercise. It’s odd in that sometimes people think that if we don’t have a plan with everything defined that we are going to do before we go do it; well — when the stuff we do get done is complete, we’ll simply stop working and sit there and stare at each other. I’m pretty sure that this is never the case and if it is, either get new people or look in the mirror.

Does any of this sound familiar? Does any of this frustrate you?

Well, I have a few ideas for you to try — most of these are common sense and talked about by others, but it’s always good to mix it up and try something different to get out of the rut or remove the pain associated with planning.

First, abandon planning using ideal hours — I know, I’m crazy — but hear me out. The common rule for any to do or task is that it should take no more than a day to get completed, ideally less. Tobias Mayer’s book called The People’s Scrum contains a curated set of his past blog posts, one in particular called, “When is Scrum not Scrum?” explains his reasoning for non-estimated, day or less tasks — (1) eases tracking – just burndown tasks — the burndown is number of remaining open tasks and (2) it helps to unearth unforeseen impediments that are often just part of what we normally do. While these are great, I would add that focusing on estimates and accuracy of the estimates actually just results in taking the eye off quality and flow of value.

SPECIAL NOTE – If you are a VersionOne user and worried about not getting a burndown, try using just a “1” in for the Detailed Estimate and To Do.  This will, in essence, create a task count burndown.

Next, decompose just enough stories to commit to the goal and get started. The Scrum Guide is pretty clear about this:

… enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting.

Now, new teams may need to decompose all stories during a sprint planning, but teams that have been together for a while may be able to quickly determine what stories to do in the next two weeks, how they fit an incremental goal, and then just go. Don’t make your sprint planning meetings more painful — if you are planning for 2 hours and you have enough work to start the sprint, then go start.

Try different techniques for this meeting that encourage engagement. For example:

Taskstorming. A simple approach where the team selects which stories they are going to work on based on past velocity and then, interviews the Product Owner on each. During the interview, the teams is noting on sticky notes the tests and tasks. Once a goal emerges, then it’s time to task [and test] storm. On a whiteboard, write the title and draw a large box for each story. Now have the team place their sticky notes up on each story. Duplicates can be discussed as well as someone can put up something that doesn’t make sense to anyone else — well discuss it. Through this process, let the conversations flow – observe a story with a ton of task, then maybe it should be broken apart? Taskstorming not only makes the meeting more efficient, but it’ll make it more effective because everyone is involved and engaged in the process. At the end, have folks pair up and help get the data captured in your favorite tool (which means VersionOne).

Other techniques you can try include Task-n-Tell and Test First Tasking.

Finally, as I’ve mentioned in a couple past blogs, put this on the team – this is a team activity. If you are a team member, take ownership of this meeting and you lead it. The Scrum Master or Lead or Facilitator of the team would typically do this, but if you find them directing or assigning tasks out without engagement. Well you have a problem and the best way to change it is for a team member to take over. If you are a Scrum Master or Lead and you are struggling with getting the team engaged, try something new — don’t be insane. Try introducing a facilitation game or asking someone else to facilitate (not the product owner or anyone else in a position of authority).

No one should suffer through a sprint planning meeting. Yes they can be hard, but they shouldn’t be torture — so, inspect and adapt. Time to make them fun and effective.

Remember that at the end of the day, tasking is simply defining the proverbial “To Do” list to get a story done.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Project Management, Agile Teams, Scrum Development | Leave a comment

Succeed Strategically with Your Agile Product Vision and Strategy Planning Playbook









In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.  In the second blog post, I explained the four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.

In this third blog post, I describe how to do Product Vision and Strategy planning (the top level in the four-level planning).  At this planning level, the planning horizon is typically for one to three years, and business initiatives or strategic themes serve as the planning unit which may take several months to complete.   Product Vision specifies the What and Why of the product, while Product Strategy elaborates how to realize the vision with a specific approach, and provides a roadmap showing a timeline for executing the strategy.  Product vision is the guiding North Star, and does not change much, if at all.   Once the product strategy is prepared, it may undergo adjustments and refinements over a period of time, but not too frequently.  If it were to change frequently and/or radically, probably the necessary strategy development homework was not done properly or the product may still be in an early startup phase.

As outlined in the second blog post, there are four objectives at the Product Vision and Strategy planning level.

  1. Choose appropriate Product Vision and Strategy framework and its methods for application in your Agile Product Vision and Strategy Planning Playbook
  2. Complete preparation for Product Vision and Strategy planning
  3. Develop Agile Product Vision and Strategy plan
  4. Re-Plan and improve the Product Vision and Strategy planning process

Associated with these four objectives, there are four practices, identified as Practices 1.1 through 1.4 in Table 1 of the second blog post.   I now elaborate on these four practices in this blog post.

Practice 1.1: Choose appropriate Product Vision and Strategy Planning Framework 

As explained in the first blog post, my focus is on the lifecycle of software products or services or embedded software products that are intended for multiple customers in their chosen market segment.  With appropriate modifications, you can use the Agile Planning Framework for different situations, which I will point out briefly; their details are outside the scope of this blog series.  If you are interested in applying the Agile Planning Framework to client-specific projects (either internal or external clients), please contact me.

I first briefly review three well-known strategy frameworks that can be used for Product Vision and Strategy planning.   When market or customer needs are reasonably well known, either Competition-based strategy framework (also called “Red Ocean” strategy framework) or “Blue Ocean” strategy framework can be used.  When market or customer needs are unclear, or when it is not clear who the real customers or users are, “Lean startup” strategy framework can be used.  It is not my intent to cover these frameworks in any depth in this blog series, as many books, published reports, and reviews and critiques, are available on the subject (start with Wikipedia, if you are interested).  By no means, these three strategy frameworks form an exhaustive list.  Many other product strategy frameworks exist.  A good reference on high-tech product strategy development is the book Product Strategy for High Technology Companies by Michael McGrath.  My goal is to emphasize that you should use a product strategy framework that is appropriate to your product business.

Competition-based (aka “Red Ocean”) Strategy Framework:  This framework is applicable to product vision and strategy planning when a product is to be offered in a known, established market space, where the boundaries of the market or market segments are well-defined and accepted, and competitive rules of the game are well understood. Product strategy is based on outperforming competition in order to grab a greater share of existing demand. As the space gets more and more crowded with competitors, prospects for profits and growth are reduced.  Products turn into commodities, and increasing cut-throat competition turns the water bloody – hence the name “Red Ocean”.

In this strategy, competitive advantage is based on either value advantage (such as features, ease of use, total experience, service, quality, performance, etc.) OR cost advantage (initial cost of purchase, cost of service, life cycle cost of ownership).  You have to choose either value advantage or cost advantage as your product strategy.  Compared to competition, a product must create either greater value for customers at a higher cost, or must create reasonable value at a lower cost in order to gain competitive advantage.  This classic strategy framework is rooted in Professor Michael Porter’s seminal work at the Harvard Business School and is the staple of business school courses on strategy.  In this framework, not only product competition (direct and indirect) needs to be considered, but also the bargaining power of suppliers and customers as “competitive threats”.  A very good reference for this strategy framework is Prof. Michael Porter’s Competitive Strategy book, and his other books and articles on the subject.

Blue Ocean Strategy Framework: Blue Ocean strategy framework was developed by W. Chan Kim and Renée Mauborgne, professors at INSEAD and Co-Directors of the INSEAD Blue Ocean Strategy Institute. The Blue Ocean strategy framework rejects the fundamental tenet of Red Ocean strategy framework that a trade-off exists between value and cost.  This strategic approach requires that a product strategy break away from the red ocean of bloody competition by creating uncontested market space that makes competition irrelevant. Instead of dividing up existing demand, blue ocean strategy is about growing demand and breaking away from competition.  A very good reference for this strategy framework is Profs.  Kim and Mauborgne’s Blue Ocean Strategy book, and their articles on the subject.

This strategy framework requires value innovation in the region where a company’s actions affect both the product cost structure and its value proposition to buyers.  New value creation is accomplished through one (or more) of four perspectives: eliminating, reducing, raising or creating.  Cost savings are achieved by eliminating and reducing the factors the product competes on.  Buyer value is lifted by raising and creating elements that the industry has never offered (hence the name ERRC).  Over time, costs are further reduced as scale economies and learning curve kick in.  This approach results in what Blue Ocean strategy framework calls an ERRC Action Grid.  Product strategists need to identify specific factors to eliminate, reduce, raise and create in order to create a blue ocean of value innovation.

An example of applying the ERRC Action Grid to Southwest airline which succeeded in creating a blue ocean of new market demand is shown in Figure 4.  Southwest’s Strategy Canvas and Value Curve are shown in Figure 5.  Data used in Figure 4 and Figure 5 are based on the information in the Blue Ocean Strategy book.


Figure 4: Blue Ocean Strategy ERRC Action Grid and
application to Southwest Airline’s Service Strategy


Figure 5: Blue Ocean Strategy Canvas and Value Curve for Southwest Airline

Southwest Airline created a blue ocean of demand by offering much higher value in friendly service, speed, and frequent point-to-point departures at a lower cost.  Its value innovation offered both value as well as cost advantages.  Southwest Airlines essentially offered flexibility of bus travel at the speed of air travel using secondary airports.  Many additional examples of blue ocean creation are given by Kim and Mauborgne in their Blue Ocean Strategy book and papers.

Lean Startup Strategy Framework:  The Lean startup is a method for developing businesses and products first proposed in 2011 by Eric Ries.    The Lean Startup method teaches you how to drive a startup-how to steer, when to turn, and when to persevere-and grow a business with maximum acceleration. It is a principled approach to new product development. Lean startup method is good at answering key questions that may come up at an early stage of developing Product Vision and Strategy, such as who are the real customers/users, what are their real needs, what should be the key features that the product must provide to meet those needs, etc.  This is the case with many start-ups of entrepreneurial as well as intrapreneurial variety.  These questions are answered and assumptions are validated (or refuted) by means of a series of small, inexpensive experiments and so-called Minimum Viable Products (MVPs).

Based on the results of such experiments and feedback from MVPs, a lean startup either adjusts its approach or does a strategic shift (called pivot).   I propose the phrase Lean Startup Strategy Framework to denote the lean startup-based approach of small, inexpensive experiments and MVPs to address strategic questions and to validate/refute key assumptions.  So-called A/B testing methods can be considered as part of the Lean Startup Strategy Framework.  When there are two options, A and B, available to implement something (a feature or a story or a user interface), both options are offered to a select set of users that are statistically significant and meaningful, and their feedback is collected and analyzed rapidly to decide whether option A or B is better.  A very good reference for the Lean Startup method is Eric Ries’ The Lean Startup book, and his articles on the subject.   A good source to get started on A/B testing is the Wikipedia page on the topic.

Comparison between Red Ocean and Blue Ocean Strategy Frameworks and Connection to Lean Startup Strategy Framework

Table 2 shows comparison between the Red and Blue Ocean Strategy Frameworks, and suggests their connection to the Lean Startup Strategy Framework.  I hope this helps you make your decision about which framework to use for your specific situation.  Once a startup demonstrates that it is a commercially viable venture, it can follow either Red Ocean or Blue Ocean Strategy Framework to develop its Product Vision and Strategy plan when it grows and tries to scale up.  It may continue to use Lean startup method to validate or refute assumptions even in its growth phase (when it’s no longer a startup).   This is indicated by two thick yellow arrows from the Lean Startup Strategy Framework to Red Ocean and Blue Ocean Strategy Frameworks in Table 2.

Profs. Kim and Mauborgne point out (in their Harvard Business Review, October 2014 article) that the incumbents often create blue oceans—and usually within their core businesses.  Within an enterprise, both red and blue oceans can co-exist for different products.  “The Japanese automakers, and Chrysler were established players when they created blue oceans in the auto industry.  So were CTR and its later incarnation, IBM, and Compaq in the computer industry.  And in the cinema industry, the same can be said of palace theaters and AMC.”  This is indicated by the thick yellow arrow from the Red Ocean Strategic Framework to Blue Ocean Strategy Framework, which delivers much higher profitability (as pointed out in Table 2) due to largely uncontested new markets.

Table 2: Red Ocean, Blue Ocean and Lean Startup Strategy Frameworks


Practice 1.2: Complete Product Vision and Strategy planning preparation

Based on the strategy framework selected in Practice 1.1, necessary inputs for product strategy planning should to be collected and preparatory steps should be completed before the planning sessions or workshops.  These inputs and preparatory steps are listed below. If these steps are not properly completed, actual planning (Practice 1.3) will not be very effective and/or efficient.  Note that many inputs and preparatory steps are common to both Red and Blue Ocean Strategy Frameworks.  Their key differences are in terms of markets and competition, as pointed out below.

Inputs and preparatory steps common to both Red and Blue Ocean Strategy Framework-based planning

  • Get business strategy inputs that will drive the Product Vision and Strategy planning
  • Prepare a draft list of key market segment(s) and key customers
  • Prepare a draft list of business initiatives, strategic themes, key milestones
  • Decide rough timeframe to realize the product vision
  • Identify people required for Product Vision and Strategy planning, their specific role and responsibilities, and get their buy-in to carry out this work
  • Determine various planning sessions and their schedule, and invite the required people to those sessions

Inputs and preparatory steps for Red Ocean Strategy Framework-based planning

  • Collect inputs on strengths and weaknesses of major competitors (direct and indirect) and information about all competitive threats

Inputs and preparatory steps for Blue Ocean Strategy Framework-based planning

  • Collect inputs on where the Blue Ocean of new market demand will need to be created
  • Prepare draft inputs for the ERRC Action Grid: what needs to be Eliminated, Reduced, Raised and Created in order to develop a Blue Ocean demand without much competition

Practice 1.3: Develop Product Vision and Strategy agile plan 

As pointed out above in this blog post, many seminal books exist on Competition-based (Red Ocean) Strategy, Blue Ocean Strategy, Lean Startup, and product strategy.  Plenty of material is also readily available on-line, along with training, coaching and consulting services from experts in those areas.  In this practice, you should use the nuts and bolts from an appropriate book or related material applicable to your chosen strategy framework after you have completed Practices 1.1 and 1.2 above.    

Product Vision and Strategy planning effort may span over several calendar weeks with a series of meetings and workshops attended by senior executives, product management team, and appropriate stake holders invited for specific meetings or workshops (senior technologists, and senior representatives from marketing, sales, manufacturing, etc.)  As pointed out in the first blog post, three to nine days of total planning effort is typically required depending on the product size, duration and complexity for a one to three year product horizon (240 workdays per year).  A product vision and strategy plan should be revised or fine-tuned at the end of each release cycle.  If you consider additional two to five days of effort to prepare for planning (Practice 1.2), and two to five days of effort to revise and maintain the Product Vision and Strategy Plan, it still amounts to only 3% of total time for planners at this planning level.

The end results of Product Vision and Strategy planning is a set of key artifacts listed below.  Many artifacts are common to both Red Ocean and Blue Ocean Strategy Frameworks, with some key differences as noted below.

Product Vision and Strategy Plan (elements common to both Red and Blue Ocean Strategy Frameworks)

  • Business needs the product will fulfill
  • Target customers and users
  • Key capabilities of the product that will meet the business needs of target customers and users
  • Technology platform and stack to be used: such as three-tier web, or mobile clients and cloud-based servers, Java stack or .Net stack, etc.
  • Key components to be licensed from third parties (Buy vs Build decisions)
  • Major architectural considerations and high-level product architecture
  • Value offered by the product to customers and users
  • Value offered by the product to you (product vendor)
  • Budget for the product allocated by major business initiatives or strategic themes or release cycles. The budget is agile as these numbers are revised (ramped up or down) based on project execution results, customer feedback, and inputs from the environment (changes in market and economic conditions, competitive response, etc.)
  • Product sales method
    • Direct?
    • Through distribution channels?
    • Bundled with other products or services?
  • Target price for the product
  • Sources of revenue and the business model: license fee, subscription fee, support and maintenance fee, volume discount, etc.
  • Service and support model for the product
  • Business case for the product: return on investment
  • Risks and the risk mitigation plan
  • Assumptions and experiments needed to validate/refute them (may use Lean Startup method)
  • Action items

Product Vision and Strategy Plan (elements applicable only to Red Ocean Strategy Framework)

  • SWOT matrix: strengths, weaknesses, opportunities and threats from your direct and indirect competitors compared to your product
  • Your sustainable competitive advantage: Specify whether and how it is based on either Value advantage OR Cost advantage (initial cost of purchase, cost of service and life cycle cost of ownership).

Product Vision and Strategy Plan (elements applicable only to Blue Ocean Strategy Framework)

  • ERRC Action Grid: What needs to be eliminated, reduced, raised and created for your product to develop a Blue Ocean of new demand without much competition
  • Strategy Canvas and Value Curve for your product illustrating how it will create a blue ocean of new demand
  • Your sustainable competitive advantage based on both value advantage AND cost advantage (initial cost of purchase, cost of service and life cycle cost of ownership).

List of key business initiatives and Strategic themes: These initiatives and themes (often modeled as large epics) may take several months to complete and deliver.  They seed the product backlog and will be broken down into features (often called epics) that fit in success release cycles.  Later on features will be broken down into stories to fit in successive sprints of release cycles.  The items in this list are prioritized (rank-ordered).  This list is dynamically maintained by adding, deleting, revising, refining, and re-prioritizing items it by the product management team based on project execution feedback and inputs from the environment (market, business, customer feedback, competitive response, etc.).

Product Roadmap:  This artifact shows how the key business initiatives and strategic themes (represented as major features or epics and feature groups) will be realized over a time line, typically organized by the next 3 to 4 quarters or release cycles, as illustrated in Figure 6.  The roadmap is dynamic; when a quarter ends, it is retired from the roadmap and a new quarter is added.  Features may be categorized in three swim lanes, typically basic, differentiated and delighters (game changers).  Additionally, a roadmap may capture key milestones, such as product demos in major tradeshows, filing patents, etc.


Figure 6: Product Roadmap

Workflow for monitoring Product Vision and Strategy plan execution:  A Kanban workflow is designed to help visually monitor the execution of Product Vision and Strategy plan as illustrated in Figure 7.  Optionally, Work-in-Process (WIP) limits can be placed on the workflow status columns, cycle time can be measured (for example, cycle time from “Approve and Fund” status to “Measure ROI” status), and swimlanes can be added to the workflow (based on a suitable criteria, such as priority or source of work items).  Then appropriate steps can be taken to reduce the cycle time as part of continuous improvements.  The workflow also helps align the release planning and release plan execution (the next lower level of planning) as explained in the next blog post in this series.


Figure 7: Workflow Design for Monitoring the Execution of
Product Vision and Strategy Plan

Wasteful activities to be avoided during Product Vision and Strategy Planning:  Activities that do not produce adequate value or represent opportunity costs should be avoided or minimized.  Some examples:

  • Annual budgets: they encourage a “Spend or lose” mindset that is counterproductive for agile projects.  It is better to commit budget tied to key initiatives or to the next one or two release cycles, and adjust the budget based on project results.  The budgeting process itself needs to be agile.
  • Details at the level of stories: At the Product Vision and Strategy planning level, this level of detail is unnecessary and represents waste; moreover, these details will invariably change with the passage of time.
  • Planning a roadmap for more than four quarters: there is not much to gain in projecting a roadmap more than four quarters in future; it is also wasteful as those details will change with time.
  • Overly complicated workflows for monitoring the plan execution: few status columns (4 to 6) and at most few swimlanes (2 to 4) is adequate in most situations.

Practice 1.4: Re-Plan and improve the Product Vision and Strategy planning process

A Product Vision and Strategy plan is not static or frozen.  You will need to revise it based on:

  • Release reviews and retrospectives
  • Key feedback from sprint reviews
  • Key feedback from customers
  • Inputs from the environment (changing market and business conditions, and competitive response).

You should improve the Product Vision and Strategy planning process itself as well as your Agile Product Vision and Strategy Planning Playbook based on the derivative feedback from production use of your product, release reviews and retrospectives, and inputs from the environment.  Derivative feedback means second-order feedback or feedback derived from primary feedback flow.  If desired business results are less than expected over 2 or 3 release cycles, it is derivative feedback based on the sequence of feedback from multiple release cycles.  As it is likely to represent a trend, it warrants a fundamental reexamination of the product strategy, and make adjustments as required.  Agile Product Vision and Strategy Planning Playbook used to capture the strategic planning process will then need a revision too.

If your business is not product-based, but is driven by client-specific projects (either internal clients or external clients), the nature of competitive dynamics changes.  For internal clients (typical of an IT organization inside an enterprise), the competition is more likely to be “build vs buy” choices.  For client-specific projects, you will need to make the fundamental choice between Fixed Price / Flexible Scope, or Fixed Scope / Flexible Price as your strategy.  For external clients (typical of IT service providers in open market), there is still the option for selecting and applying either the Red Ocean or Blue Ocean Strategy framework to the overall service business.  Most of these vendors today are swimming in the Red Ocean, but once in a while value innovation is created with a blue ocean of new demand.  This happened during 2000-2010 with phenomenal growth of Indian IT companies, such as TCS, Infosys, Wipro, etc.

The past two blogs of this blog series:

  • Blog 1:Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels
  • Blog 2: Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Objectives

The next three blogs of this blog series:  In the following three blogs (Blog 4 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 4: Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at

Your feedback: I would love to hear from the readers of this blog either here or by e-mail ( or on Twitter (@smthatte).

About the Author

versionone-coaches-satish-thatteDr. Satish Thatte

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne.  He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level.   He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute.   Learn more about Satish and his blogs at LinkedIn and blogs.


Posted in Agile Management, Agile Methodologies, agile program, agile program management, Agile Project Management, agile prorgram | Leave a comment

6 Awesome Resources to Help You Be a Better Executive Sponsor

Executive Resources.docx









74% of projects are successful at companies where sponsors have expert or advanced project management knowledge, yet the 62% of companies do not provide executive sponsor education.

Make sure your next project is successful by reviewing these six resources for executive sponsors.

Executive Sponsor Engagement

An in-depth research report from the Project Management Institute uncovering the three primary factors that can limit or inhibit executive sponsors’ ability to be effective.

How to Be an Effective Executive Sponsor

This Harvard Business Review article describes the keys to communication between the executive sponsor and project manager.

A Sponsor’s 12 “P’s” to Deliver Successful Strategic Execution

In this article Jon Hughes, Head of Program Management Consulting at Cognizant describes the twelve personal traits of a successful executive sponsor.

7 Tips for Communicating with Executive Sponsors and Stakeholders

This blog post highlights seven tips for communicating with executive sponsors and stakeholders that will help your team engage with the key leaders of the organization.

How an Executive Sponsor Contributes to Project Management

This article discusses what an executive sponsor can do to ensure the success of projects.

How to Innovate with an Executive Sponsor

This Harvard Business Review article explains how to garner sponsorship but avoid being steered toward experimenting in a large, public, fashion that failure results in shuttering the innovation effort.

What are some other good resources you would recommend?

Posted in Agile Leadership, Agile Project Management, Uncategorized | Leave a comment

5 Best Practices of Successful Executive Sponsors


Exec Sponsor









It is well know that executive sponsors can help a project to be successful, but not all projects with an executive sponsor succeed.

Why don’t they?

It is because there isn’t necessarily a training manual for how to be an executive sponsor or what pitfalls one must avoid.

So, how do you become a successful executive sponsor?

Build Trust & Communication

While the project manager is responsible for ensuring that the necessary work is being done so that a project will be successful, an executive sponsor’s role is to ensure the project is successful. While those may sound like the same thing, they are vastly different.

The project manager must focus on the day-to-day execution, while the executive sponsor should focus on the bigger picture, ensuring that the project stays aligned to the strategic goal and is being supported by other stakeholders and removing roadblocks.

In order to do this, the executive sponsor and project manager must have a candid relationship built on trust. Too often projects fail because people tend to hope for the best-case scenario and rely too much on best-case status updates. The communication between project manager and executive sponsor should be about openly discussing risks that the executive sponsor can help the team navigate.

Make Realistic Commitments

It goes without saying that commitment is a key component of being an executive sponsor, yet countless projects that have executive sponsors fail nevertheless. This isn’t to say that the failure is necessarily due to the executive sponsor, but as obvious as the importance of commitment is, there are many cases where the executive sponsor had an unrealistic expectation of their commitment. According to PMI’s annual Pulse of the Profession survey, one-third of projects fail because executive sponsors are unengaged.

Sometimes this has less to do with the individual and more to do with the organization. As more and more studies come out showing how executive sponsors increase the success of projects, companies want more executive sponsorship of projects. This has led to many executives being overextended across too many projects.

Before taking on a new project, sit down and determine the required time commitment and whether you have the bandwidth to meet that commitment. Your organization may be pressuring you to step up and take another project, but it won’t do them or you any good if the project fails.

Avoid Getting Overextended

We already discussed that the success of having an executive sponsor has led to many organizations overextending their executives. An in-depth study by the Project Management Institute found that executives sponsor three projects on average at any one time and they report spending an average of 13 hours per week per project, on top of their normal work.

Obviously, this isn’t sustainable and isn’t a recipe for success. The same study found several negative impacts from executive sponsors being overextended.

Project Mgt Statistics








The solution here is simple; you have to learn how to say no. That is, of course, easier said than done when you’re being pressured to take on a new project, but again, it won’t do them or you any good if the project fails.

Develop Project Management Knowledge

According to a PMI study, 74% of projects are successful at companies where sponsors have expert or advanced project management knowledge. Unfortunately, only 62% of companies provide executive sponsor education and development. Not every executive has necessarily been a project manager or gone through project management training.

The results speak for themselves; having advanced project management knowledge makes it far more likely that you will be successful. If your organization doesn’t provide executive sponsor development, take it upon yourself to become a project management expert. It will help your team, company and self. The Boston Consulting Group has found that successful executive sponsors focus on improving their skills in change leadership, influencing stakeholders and issue resolution.


I hope this has inspired you to develop your executive sponsor skills. While it may be difficult to find the time, the payoff will be well worth it for you, your team and your company!

What are some other important keys to being a successful executive sponsor?

Posted in executive sponsor best practices, Uncategorized | 1 Comment

Sketch Your Way to Faster Consensus and Better Products

This meeting is a waste of my time. When was the last time you had that thought? Was it because the conversation wasn’t focused, or people couldn’t agree, or maybe they were in violent agreement, but couldn’t see it?

We recently spoke with Jeremy Kriegel, an independent UX consultant, at Agile Day Atlanta, about a sketching technique you can use to get your meetings back on track, get to consensus faster, and deliver better products.

VersionOne: Why is sketching so important to agile teams?

Jeremy: It’s not so much about sketching per se. It’s about moving agile teams forward and getting to decisions faster. Sketching is one great way to do that, because people think in multiple ways. When you’re just talking, it’s just words and concepts, but when you add pictures, the communication becomes a lot clearer.

VersionOne: How do you respond when people say “I can’t draw”?

One of the barriers to doing sketch facilitation is that most people think they can’t draw. They’re thinking about sketching in terms of creating art. There’s a difference between sketching as art, and sketching as communication. When you’re sketching as communication, you only need some rudimentary drawing skills and a few basic techniques in order to communicate an idea and collaborate with people.

VersionOne: Are there any particular sketches or symbols that would be helpful for people to learn? Or do people just need to get over worrying about whether or not their sketches look good?

Jeremy: It’s a little bit of both. In my workshops, I start out by showing a beautiful wireframe that I found online that has crosshatching and perfectly straight lines that looks like someone took a lot of time and effort to create. Most people would agree it’s a beautiful sketch, but it takes a lot of time, and you just don’t have that kind of time in a meeting. Then I show people my version of that same wireframe, which is a really messy, squiggly, drawing, but it has all the right elements. That’s the first time people start to go, “Oh, I could do that.”

Then I start to break it down in terms of showing them a screen, like a regular web page, and say, “Okay now here’s a sketch version of that screen. Look at the elements and just draw a bar for the navigation bar and box with an x in it is an image place holder, etc. When they see it step by step, I think it starts to make sketching more comfortable.











Once I’ve demonstrated a number of techniques on how to represent text, people can start with very basic sketches with a couple of squiggly lines representing a line of text or a paragraph. Then they can move on to more advanced sketches that include details on different content, like a product description or directional text like “sign up for a newsletter” or “buy our product now,” to give people a better idea of what the content is intended to be.

The bottom line is if you can draw a straight line, a circle, a squiggly line, and the alphabet, that’s really all you need in order to do sketching for communication.

The next step is to break down this barrier between what they think they can do, and being able to do it. I start with a fairly simple webpage and give people a minute to sketch that page. Then I show them more complicated page and give them a minute to sketch that page. Then I show them a mobile app, and give them a minute to sketch that. That way they get some practice sketching different types of pages and content, and they have to do it really fast.

The point of sketching quickly is not to prove how fast you can go, but if you’re trying to facilitate a group discussion, the ideas are usually coming fairly rapidly and you have to be able to keep up with the conversation. This also helps you move away from this notion of being perfect. You just don’t have time to be perfect when you’re trying to capture a lot of input quickly.

Now that they’ve copied a few pages of sketches, then I ask them to take a common page type that they’re all familiar with, typically an e-commerce check out page, and sketch that from memory. That way I can ease them into the process from seeing what’s involved and seeing some examples, to sketching a page in front of them, and then creating their own sketches. That starts to get people over this fear of sketching.

In the last exercise, I ask people to pair up. One person plays a product owner and the other person plays the graphic facilitator. The first half of the exercise the product owner says, “We’re going to complete this checkout process. Here’s what I need on my shipping page.” The sketch facilitator visually captures the input in words to make sure they have their shared understanding of what they’re going to design. He captures the words that product owner is saying and writes the words down so the product owner can see and agree to them. Once they’ve done that they’ll move on to sketching with the sketch facilitator driving with input in real time from the other person. Then they’ll switch roles and go through the exercise again.

VersionOne: Have you seen examples when a team is having a difficult time communicating and then they start sketching and everything becomes better?

Jeremy: In my almost 20 years of being in this industry, sketching is one of the most powerful tools to help move teams forward quickly.

Years ago when I was at a big agency we always kicked off projects with these big workshops with stakeholders. We always took notes on the whiteboard, so that all the stakeholders and the team members could see, and agree, on what was being discussed. If people see the input in real time you can avoid issues later. If someone disagrees with something that you’ve written, they’ll say it right away.

Sketching saves a lot of back and forth time. You can discuss conceptually what you’re looking for, and then collaboratively visualize the project.

I’ve really seen the difference when I’ve worked with other teams where either no one was taking notes or someone sent notes in a follow-up email that no one actually looked at it.

VersionOne: Do you have any advice to help people get over their fear of sketching in front of a team?

Jeremy: Many people are nervous about getting up in front of their team, and doing something new. To help them get over this fear, I suggest that they try progressive desensitization. It’s a technique that people might be familiar with if they, or someone they know, is afraid to fly. The airlines have these programs that you can go through to help you get you over that fear.

The first step for someone who is afraid of flying might be to just drive by an airport. They know they’re not going to go in and they might feel a little anxious about it, so they just drive by an airport until that feels comfortable. Then they’ll go into the ticketing area. They know they’re not going any further, and they can just go in until that’s comfortable. They might come in and leave the first couple of times and might not go in any farther. When they’re comfortable in the ticketing area, they might go through security, and go to a gate. They’ll do that over and over again until they’re comfortable. Then they eventually feel comfortable to fly.

I suggest a similar approach with sketching. The first step could be taking notes privately, just so you get a sense that you can keep up with capturing the conversation. Then when you feel like you are getting good enough at that, then get up and take notes on a whiteboard that everyone can see, but maybe you don’t try and facilitate the meeting. Once you feel comfortable with capturing the conversation it will naturally progress to facilitation. People will look to you as the leader, and you’ll be able to take on more of a facilitator role. One of my caveats is you have to be aware of the power of the pen, because it’s very easy to control what gets captured if you’re the one writing it down.

Another way to get there is to fake it. There’s research around the impact that power poses have on your state of mind. Putting yourself in a confident pose will make you feel more confident. I demonstrate this by having people sit with their legs together, their knees together; their arms crossed, and put their head and chin in their chest. I ask them to get really small and whisper to themselves, “I’m a rock star.” People giggle a little bit, because it’s funny, you don’t feel like a rock star when you’re small like that. Then I have them stand up, and put their arms in the air, or stand in a Superman pose, with their hands on their hips, lift their chest up, hold their high, and say, “I’m incompetent.” Of course everyone laughs, because again it doesn’t work. Your mind wants to mimic the position that you put your body into.

Even if you’re a little bit nervous, just walk confidently to the front of the room with your body language saying you’re going to take charge and you’re going to be responsible for the team getting something done today. Then it’ll happen.

Click here to learn more.

Posted in Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, collaboration | 2 Comments

3 Keys to Mastering Responsibility

Far too many good, motivated, hard-working people get stuck in jobs they don’t want, projects gone bad, work problems and careers they don’t enjoy. It happens to individual contributors and it happens to leaders.

We recently spoke with Christopher Avery, the CEO of Partnerwerks, Inc., at Agile Day Atlanta, who shared the three keys to mastering responsibility and achieving much greater happiness, freedom and choice for yourself and for your team.







VersionOne: Why is mastering responsibility so important?

Christopher: I think the main reason we should be talking about mastering responsibility is because we know that leadership is innate in all of us. It has to do with the mental process we call The Responsibility Process® by which we can take 100% ownership for our lives, situations and challenges.

The reason that we should be talking about mastering responsibility is to simply help people who may have an inkling that their lives could be better and they could do something about it.

The other reason we should be talking about mastering responsibility is that people who practice this process, start enjoying greater fulfillment, lower stress, and higher engagement. They start applying this to self-leadership in their own lives, as well as use the tools to create better teams, better organizations, better cultures, and respond much more successfully to change.

The third reason is that the research on The Responsibility Process is only three decades old and not widely known.

VersionOne: Is the outcome of The Responsibility Process that people discover their passion and end up with a renewed focus on what they’re currently doing?

Christopher: Part of the process of taking responsibility has to do with understanding your own inspirations, desires, dreams, and your own definition of who you are when you’re most fulfilled. The other is true also. You may simply find profound acceptance in the life that you have.

One is an acceptance that what you’re trying to do or be isn’t who you are. The other is an acceptance that it is exactly who you are

The Responsibility Process is a framework for how we process thoughts about stuff going wrong in our lives. If we get good at the framework, then we can use it as a GPS to steer us towards greater fulfillment. If we’re not good at this framework, then we end up getting stuck.

VersionOne: What problems are typically driving people to contact you to find out about the responsibility process?

Christopher: The majority of the people who contact us are in a leadership positions who are feeling somewhat trapped and they don’t know how to get un-trapped.

The have the responsibility process in them. My process is to simply recondition them on how to think when they’re experiencing a problem, so they will get stuck in those mental states less often and for shorter times. They’re able to think more clearly about what they want and what the next steps should be.

Click here for learn more about The Responsibility Process.


Posted in Agile Leadership, agile program management, Agile Teams, Uncategorized | 1 Comment

What Kind of Agile Are You?









As many as 94% of organizations are practicing some form of agile according to 9th annual State of Agile survey™, yet I have first-hand experience seeing countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach.

So how can you tell if your organization is doing agile right?

The Top 1% of the Top 1%

There is a vast difference between the way Olympic sprinter and world record holder Usain Bolt approaches his goals and how an everyday person trying to lose weight by running approaches their goals. Usain Bolt is the elite of the elite, in the top 1% of the top 1%. His approach to training is irrelevant and unrealistic for an everyday person trying to lose weight.

Your organization isn’t like an everyday person trying to lose weight. Whether you’re a startup or a Fortune 50 company, you’re striving to be or maintain being in the top 1% of the top 1%. You can’t afford to approach anything like an everyday person. You must have the same fierce focus as Usain Bolt.

So, let’s go back to the question. What kind of agile are you, or better stated, what kind of agile is your organization? Is your organization truly agile or just superficially so?

I’ve put together some comparisons of the approaches of Usain Bolt, everyday people and agile organizations.











Usain Bolt and his team of coaches, managers and agents have a single vision—­for Usain Bolt to be one of the greatest athletes of all time. To do this he must win medals and break world records. If he is breaking world records, then everything else falls into place. Usain Bolt isn’t focused on beating the competition; he is focused on continually improving in order to break his own world records.

“If I want to be among the greats of [Muhammad] Ali and Pele and all these guys, I have to continue dominating until I retire” – Bolt










Most everyday people trying to lose weight don’t have a true vision. Yes, they wish they could lose some weight, but most everyday people don’t have the fierce focus on meeting their running goals. Nor, necessarily, should they. Most of us everyday Joes have other things to focus on like family, work and paying the bills. While our health is utterly important, it gets deprioritized because our commitment is superficial and we skip runs and sneak snacks.









Is your organization truly agile or just superficially so?

Saying you’re agile isn’t enough to be truly agile. Having teams that do stand ups isn’t enough to be truly agile. Having a Kanban board isn’t enough to be truly agile. True agile is about organizational agility and organizational agility starts with a vision: a vision from the top that is burned into the hearts and minds of the entire organization.










Your agile transformation must be aligned to your strategic goals. Both must support a single vision that pumps through the veins of your organization. If you don’t have that, then you’re just a guy running through the motions so that you feel a little less guilty the next time you have a bag of chips.









The Litmus Test

If you’re ready to face the truth and find out whether your organization is truly agile or just superficially so, try exploring the following six questions.

  1. What is your organization’s vision?
  2. What are your organization’s strategic goals?
  3. What are your organization’s agile vision and goals?
  4. On a scale of 1 to 10, how aligned are the organization’s vision and strategic goals with your agile vision and goals?
  5. On a scale of 1 to 10, how well does the organization understand this vision and these goals? This includes executives, program managers, project managers, dev managers and dev team members.
  6. On a scale of 1 to 10, how strong is the executive support of the agile vision and goals?


While 94% of organizations are practicing some form of agile, according to 9th annual State of Agile survey, I have witnessed first-hand countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach. Don’t get caught in the trap of thinking you’re agile just because you’re doing stand ups or have a Kanban board. I hope this has inspired you to take a few minutes to really reflect on whether your organization is truly agile or just superficially so.

 What are some other ways to tell whether your organization is truly agile or just superficially so?

 State of Agile is a trademark of VersionOne Inc.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Project Management, Uncategorized | Leave a comment