10th Annual State of Agile Survey is Open!

300x250It’s hard to imagine that we’re celebrating the 10th year of the State of Agile™ survey! The annual survey has become the largest, longest-running, and most comprehensive survey serving the agile community.

Last year nearly 4,000 of your peers shared what they’ve learned through their agile experiences. The survey gives agile software professionals around the world the opportunity to provide insights on a wide range of agile topics including the benefits of agile, top tips for scaling agile, how to measure agile success, and the most popular agile project management tools. This year we will be conducting an even deeper analysis of the trends over the past 10 years.

To help celebrate the 10th anniversary, VersionOne is giving away 10 Apple Watches in a random drawing in each of the 10 weeks that the survey is open. The survey, which takes about 10 minutes to complete, is open until Oct. 2. The full report will be available in early 2016.

For the past nine years, the results from the State of Agile survey have been helping organizations realize the benefits of agile faster, easier and smarter. Help the agile community make the 10th annual State of Agile survey the most valuable report yet!

State of Agile is a registered trademark of VersionOne Inc.

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

Three Leadership “Musts” for DevOps


Three Leadership









A middle-of-the-night phone call is never a good thing – especially when the director of technology operations is on the other end. It was 2:00 a.m. in the summer of 2003 when I was abruptly awakened from my phone’s vibration.

My nightmare started as the director of technology operations reported that the system was down with no resolution in sight.

A company system outage is comparable to cutting off blood flow to the brain. When the system is down, there’s no cash and the business starts to die. No matter the size or stature of a company, technology leaders constantly carry the fear that even the smallest system outage could seriously damage their work. While this fear is hidden deep inside the psyche, it’s a reality that all tech leaders learn to live with.

My system outage was no different from eBay’s in the summer of 1999. The eBay auction site suffered from a series of system outages – the longest outage lasting 22 hours.

That outage cost eBay $5 million of transaction revenue. This $5 million may sound like a lot, but, in reality, it was nothing compared to the $4 billion drop in the company’s market value as the result of the outage.


Almost two decades later, and technology experts are still experiencing major complications in their systems.

In July 2015 alone, recent outages and system failures have affected the New York Stock Exchange, United Airlines, Department of State’s Visa system, Apple’s iStore, and – most notably – the Royal Bank of Scotland’s IT systems, which reported that a half-million financial transactions vanished from the system due to an unknown error.

They say “time heals all wounds,” but system outages may be the exception to this rule, as effects can be severe.

“For the Fortune 1000, the average total cost of unplanned application downtime per year is $1.25 billion to $2.5 billion,” says Stephen Elliot, IDC Analyst. “The average cost of a critical application failure per hour is $500,000 to $1 million.”

We are still not immune to these outages and we must take great care in avoiding these issues, or risk losing time, money and business.


Today’s systems are growing exponentially more complicated. Rising demand, volumes of aging data, patchwork of software, and network infrastructure each impact a system’s complexity and deployments. IDC estimates that the average amount of monthly deployments will double in two years.

To combat the case of system failures, technology leaders must adjust to an era of instant consumption – the “have to have it now” era. The world is no longer satisfied with singular massive updates to their systems every 12 or 6 months. Rather, we need to “deploy on demand,” where software can be updated several times per day with 100% resilience.

In other words, we need DevOps.


Simply described, DevOps is the collaboration and communication between software developers and technology professionals in the IT value chain to deploy software to customers. Gene Kim, author of The Phoenix Project refers to DevOps as “the outcome of applying Lean Principles to the IT value stream.”

To achieve greatness, DevOps demands leadership vision and involvement. This requires sponsorship, so operational and cultural norms can change. It’s likely that your company will need to incorporate all of these changes to ensure long-term success.

DevOps is successful because it dramatically reduces a company’s operational risk by creating conditions that advance company culture, interactions, and tools.

Imagine a world where product, development, QA, infosec, and operations are orchestrating together to deliver business value at the fastest pace possible in an “IT value stream.” And fast execution isn’t the only benefit here – the process also has high predictability and low risk. This symphony of establishing a reliable flow across the organization – along with cultivating the right culture – is the foundation on which change can be made.

In May 2011, LinkedIn’s valuation doubled to $9 billion on its second day after IPO. With the stock soaring and a flood of new users flocking to the professional social networking site, LinkedIn was Wall Street’s golden child. Kevin Scott, LinkedIn’s top engineer didn’t feel as confident. Scott knew that the system and its engineers were being crushed by it’s own technology infrastructure inhibiting growth.

In a bold move, Scott launched Project InVersion, an initiative where all new feature development for LinkedIn stopped so that every engineer focused on rebuilding its core technology infrastructure. “You go public, have all the world looking at you, and then we tell management we’re not going to deliver anything new while all of engineering works on this project for the next two months,” Scott says. “It was a scary thing.” This work centered on LinkedIn’s ability to build out DevOps so that it could scale and accelerate while eliminating technical risks.

This resulted in extending the company’s deployment capabilities so that it can deploy changes at a moments notice at any time of day. Further, it helped support the growth of LinkedIn’s user base to over 364 million members and a market cap of $28 billion.


Gene Kim describes DevOps as a “philosophical movement.” And he’s right. As DevOps garners more attention, experts are deliberating its “best practices” and developing tools to support those practices.

To enable success, I have found there are 3 “musts” that leadership should have when launching a DevOps movement. These “musts” are based on the premise that DevOps requires disruptive leadership.

1. Executive Involvement

Leaders, including the CTO and the CEO, must work together to make DevOps a strategic priority. Just as soldiers, airplanes, satellites, and technology are strategic assets for the military, technology leaders need to utilize DevOps assets to achieve their goals. Leaders should engage with business counterparts when harnessing the strategic value of DevOps.

Successful DevOps transformations require executive participation and understanding. With the DevOps’ unification of the technology value stream, it becomes a unique strategic capability that enables faster innovation and faster time to market.

2. Organizational Design Focused on Agile Value Delivery

DevOps transformations are not simple. They are difficult and require creativity which leads to a journey that not all people in your company are prepared to take.

Value Driven Organizations

The best way to confront this challenge is to develop a healthy organization design. Separate organizational silos split by domains may be traditional; however, they are no longer effective. Many organizations, particularly those using Agile, are experiencing success by building cross-functional teams. Each team creates work in segments of time, or “sprints.” Each sprint results in the team delivering potentially shippable increments of work product. Moreover, place more emphasis on grouping team to swarm on delivering shared objectives. This structure will have a powerful effect on your company’s ability to collaborate and build business value.

This approach places more emphasis on teamwork. The teams design, build, and test as a team. And, throughout the development process, these teams actively coordinate with Technology Operations, InfoSec, and others to ensure that their work can be deployed.

Craftsmanship & Automation

Great DevOps companies require thoughtful and deliberate decisions to encourage great engineering craftsmanship. This craftsmanship ensures software is built with practices that encourage high quality product. The practices we follow should focus on receiving fast feedback on whether or not the code really works.

Today, practices like Test Driven Development (TDD) are used to create lines of tests before the code is written. By writing the code to after the tests are created, developers create a collection of code that, by definition, is already tested before it’s finished, thus reducing errors in increasing quality.

Automation is another key element to the product development flow. Once automated, a developer can automatically test the code with a simple click. The system can test the changes across thousands of developers’ new code in a fraction of time compared to manual tests.

3. Synchronized Product Planning and DevOps Planning

Several successful DevOps groups are also accelerating their delivery capabilities with support teams. Technology operations, infosec, architecture, and risk/compliance teams are often involved in product planning.

This results in a higher degree of coordination in the product development cycle. Aspects of security, scalability, reliability, are baked into the solution from the earliest stages of planning. Moreover, by tying together areas of release management practices at the beginning, the organization’s ability to coordinate product delivery matures faster.

DevOps may seem like a lot of work, but technology leaders should consider it a smart business investment. Companies unwilling or unable to adapt will be left behind and trapped under the weight of their own antiquated practices. Those slow to react will not be able to compete due to limitations of deployment speed and resiliency. However, it’s the companies employing DevOps that will outmaneuver and outpace their competition, leaving others in the dust.

Stacey Louie is the CEO of Bratton & Company, a leading Agile Transformation consultancy based in the Silicon Valley. As an Enterprise Agile Coach, he was instrumental in PayPal’s 400 team global agile transformation as well as supporting other Fortune 500 companies including Cisco, Hewlett Packard, and eBay. He also held the position of division CTO/CIO of public companies including Verisk Analytics and Stewart Information Systems.


Posted in DevOps, Uncategorized | Leave a comment

How to Collaborate in DevOps Software Development









DevOps Software Development is new to many organizations and figuring out how to best collaborate can be challenging. One of the recurring roadblocks experienced by the organizations we serve revolves around collaboration. What are some of the difficulties they face and how can DevOps address these to help deliver great software and build systems that scale and last?

At Blue Agility, we have been leading large-scale agile transformations to help our clients align business and IT, achieve faster time-to-market, and remain competitive in the current marketplace.

DevOps Software Development

Software development is an intense collaborative process where success depends on the ability to create, share and integrate information at a very rapid pace. With globalization comes a growing need to foster highly productive software development teams that can operate successfully in this global market. Distance creates an additional challenge to development processes, as fewer opportunities exist for rich interaction and direct communication occurs less frequently.

Virtual team collaboration is the collaboration of teams that are not located in the same physical location. These teams could be either on-site, near-shore, offshore or a combination of the three types.



Whether dealing with teams collaborating in the same location or virtual teams across multiple locations, collaboration is key to a successful DevOps transformation.



DevOps is focused on improving the principles of collaboration including:

Voice of the Customer
Just in Time Requirements
Social Interaction
Fast Feedback

How to Collaborate

So how is collaboration best optimized within DevOps?

The key is to enable effective collaboration at the three following layers:

Team Collaboration: DevOps builds on the concept of small teams working together to achieve “great things.”







Team of Teams Collaboration:
A group of teams working in cadence and synchronizing often.







Intent/Idea Collaboration:
Alignment to ideas/concepts that have been identified, analyzed and approved for delivery.







With the challenges of collaboration, tooling to support the development teams becomes critical. Whichever tool is selected, it must have the ability to deliver transparent and effective collaboration for all three layers to truly be successful across the entire delivery life cycle.

Last Word

Ultimately, the improved collaboration afforded by DevOps Software Development leads to better reliability, more time to focus on the core business, faster time to market, and of course, happier clients.

Posted in DevOps, Uncategorized | 1 Comment

DevOps Culture and the Informed Workspace









While the DevOps culture has been heavily focused on what tools to use, little thought has been given to what type of workspaces are needed. Ever since the early days of agile, the importance of an informative workspace has been known. Many of the practices around working together, pair programming and the Onsite Customer from Extreme Programming were to enable the rapid flow and visualization of how the team is doing. Other aspects, such as the Big Visual Chart, were included to keep the information flowing. We have made great progress in this category, but we still have more to do.

Now, fast forward to the DevOps culture. Much like the original agile movement, DevOps is a relatively unique change in the world of work that involves both cultural and technical shifts. It’s just not enough to have cool new tools like Puppet and Chef, or any of the other cool tools that make continuous delivery “a thing.” We need to be able to think about how we are planning our stories. We need to be able to be including acceptance criteria that go beyond just “is it done,” but also all the way to “is it staying done?”

We often run into this as agile consultants. I have often gone to work with a client and their number one concern as we are going through the engagement is “ok, and what do we do on day one of the sprint when we don’t have you here coaching us?” Now, they are fine on their own, but part of the plan is to know what to do after the training wheels are off. Let’s look at that same idea in terms of DevOps Culture. Stories have a very limited life. Once the product owner has accepted the story, we tear it up and throw it away, metaphorically speaking. But that isn’t the end of the story. The software now needs to live and breathe in the big wide world. How do we do that? DevOps is of course the answer, but what exactly does that mean?

Workspaces in the DevOps Culture

As mentioned earlier in this article, the idea of an informed workspace is a valuable tool in our belt for moving deeper and wider into the DevOps culture. Think back to one of the biggest cultural changes called for in the early adoption of agile. Agile called for bringing QA into the room. We aren’t treating QA as a separate team, but part of the team. All of a sudden we are paying close attention to the number of tests that are passing. So now part of our Big Visual Chart is focused on the pass/fail rate of our tests, not just the status of the story itself. This shift took a lot of effort, and I think that if we are honest with ourselves it’s not done yet. But that is an article for another time. We want to take a deeper look at the keys to successfully affecting a further transformation to the DevOps culture. What aspects will really help us do more than just have lots of automated builds that we call done, with no thought to what happens after?

The first step is to think about the cultural changes required. What is it that we will need to change in our thinking in order to make DevOps more than just another buzzword at our shop? The first, and hardest, change is to stop thinking in terms of the “DevOps team”. The whole team is part of Dev and Ops. There just is no wall to throw “finished” product over anymore. It’s all about creating great and long lasting software. There are many steps that we have already taken to get there, but this is one of the biggest. So let’s take a look at the different activities that really make a DevOps culture thrive.

DevOps Activities

Of course, the first thing one thinks about when discussing DevOps is the activities that support continuous delivery. This means an even higher need for all tests to be automated. Unit tests are merely the start, followed closely by automating your acceptance tests. Having these tests running continuously throughout the day is basically the cost of entry into the DevOps culture. Without a strong continuous integration server, running tests all day and every day, we just can’t be sure that what we are releasing is of a high enough quality to stay healthy in the real world. After that, the art of continuous deployment becomes an additional challenge. Orchestration tools are vital to make sure the right bits get bundled with the other right bits, and then get put where they belong. And then, since we are all part of “keeping the lights on,” we need monitoring tools to help us visualize whether our software really is behaving properly. So yes, there is a definite technical aspect to DevOps.

That’s a lot of moving parts! We need to keep track of where we are. This leads to one of the cool parts of a true DevOps implementation. All those cool monitors that the Ops guys get with the fancy graphs and uptime charts? They come into the room with the Ops people. And we need to add to them. We are going to track story progress from idea to implementation, and then into the wild. My acceptance criteria are going to include things like “must have Nagios hooks” and “will use less then x% of CPU”. And now we have to live up to it. This means it is more important than ever to be able to visualize the entire flow. Our Big Visual Charts need to be able to show us not just how the current iteration is going. They must show us the state of the build server, the state of the various builds and where they are in any of the extended process, such as UAT, etc. And, in the unlikely event of a failure anywhere along the line, or in post-production, we can follow a clear chain of events back to find the problem quickly.


So now we see that, while DevOps is primarily a people problem, there are a lot of technical aspects that enable a strong DevOps culture. The key to success is the union of the people and technical aspects, which in a way make DevOps a Cyborg. In order to balance these two aspects, and in order to keep ourselves from burning countless hours and countless brain cells chasing down all of the moving parts, we need to focus on Information. The more Information that we can have at our fingertips, the more effective we will be. Each team will identify which information is the most meaningful to them, and how best to interpret it. You can bet that this will be in live charts rather than stale reports. Being able to orchestrate the entire flow of a story’s life, from inception to realization to retirement will be much easier if we can visualize each step of the way. If this means our team room might start looking like the command center in war games, what’s so bad about that?

About the Author

versionone-coaches-steve-ropaSteve Ropa
CSM, CSPO, Innovation Games Facilitator, SA
Agile Coach and Product Consultant, VersionOne

Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Posted in Uncategorized | 1 Comment

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 Services@VersionOne.com.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) 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