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.
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?
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.
- Choose appropriate Product Vision and Strategy framework and its methods for application in your Agile Product Vision and Strategy Planning Playbook
- Complete preparation for Product Vision and Strategy planning
- Develop Agile Product Vision and Strategy plan
- 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. A very good reference for the Lean Startup method is Eric Ries’ The Lean Startup book, and his articles on the subject.
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
- 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, and swimlanes can be added to the workflow (based on a suitable criteria, such as priority or source of work items). 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 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
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.
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.
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.
A good key indicator for measuring how well your agile team is performing is the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. Of course, there will be days when progress is not as expected or tasks end up larger than originally estimated. A burndown can help your team reset and keep stakeholders in the loop.
Over the years, I’ve had a number of articles in Crosstalk magazine (hosted out of Hill Air Force Base). I’ve included some on my web site, but their formatting is frankly better. Try reading these:
(Note 2011 – they moved all their articles! trying to track them down)Date Article Oct, 2002 Learning from Agile Development - Part One Nov, 2002 Learning from Agile Development - Part Two Nov, 2004 What the Agile Toolbox Contains Feb, 2006 A Governance Model for Incremental, Concurrent, or Agile Projects April, 2007 What Engineering Has in Common With Manufacturing and Why It Matters May, 2008 Using Both Incremental and Iterative Development Aug, 2008 Good Old Advice Jan, 2009 "Spending" Efficiency to Go Faster July, 2014 Disciplined Learning: The Successor to Risk Management
As real and daunting as scheduling pressures can be, they have to be balanced with the consequences of a potentially disastrous premature go-live. Don’t let all the reasons a system simply "must" be implemented by a target date overwhelm compelling evidence that it is not ready. Consider these eight questions honestly first.
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.
I’m interested in learning about the Crystal methodologies, especially for the Crystal Clear
I need to select the methodology for developing my undergraduate thesis.
-by Giuliana Collantes on 6/15/2015 at 12:01 PM
Hi, Giuliana, thank you. The book is available on Amazon, it explains everything.
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.
- What is your organization’s vision?
- What are your organization’s strategic goals?
- What are your organization’s agile vision and goals?
- On a scale of 1 to 10, how aligned are the organization’s vision and strategic goals with your agile vision and goals?
- 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.
- 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.
Agile at scale essentially boils down to this: Agile teams working with the business to deliver value to market fast and predictably. Though the principles of Agile development — cadence, collaboration, synchronization, etc. — remain the same, planning and delivery are different at scale.
Coordinating complex development across teams requires a different approach. It means putting business value first and coordinating that work across multiple teams. Rather than try to dissect the work in process team by team, delivery leaders need an at-a-glance view of the overall progress of the release and the features planned — plus the ability to identify problems quickly so they know what conversations to have and what roadblocks to clear. Rally’s powerful new Release Tracking page provides just this — a bird’s eye view of where your release is and the problems you need to manage.How It Works:
Scoped to a specified release, the Release Tracking page shows all the features planned and the teams working on them.
Select a Feature to see which teams are working on it and its development progress.
Rally’s %done indicator highlights the overall progress of a feature and shows each team’s progress in any iteration. Color-coded progress indicators signify whether a team or feature is on track for delivery by the planned end date. Red means potential trouble, and an area to explore further.
Dependencies across teams often derail progress. On the Release Tracking page, dependency lines quickly indicate when teams are misaligned on dependent work.
The page also includes a warning indicator to communicate several potential issues with a feature that may delay its completion — including blocks and dependencies.
With Rally’s Release Tracking page, it’s easy to keep tabs on overall progress and identify problem areas. You’ll see when teams are on track, so you don’t bother them with questions about their progress. And when issues do arise, you’ll know the right conversations to have at the right time to resolve dependencies, mitigate risks, and keep the delivery group humming.Get Started Now
As of June 17, all Rally Portfolio Manager customers using our enterprise SaaS platform have access to the new Release Tracking Page in open beta. Use it during your next Big Room Planning event to see how your plan is coming together, in realtime, in a single view. And keep using it to help steer your release on time, as planned.
To learn more about the Release Tracking page in the Rally platform, watch the demo video below, reach out to your Rally Solution Architect, or take a Rally product tour.
We are thrilled to announce the availability of Rally’s capacity planning capability — built for the program and portfolio level of enterprise scale Agile. With the new Capacity Planning page in the Rally platform, strategic planners can rapidly translate their business initiatives into realistic and adaptable action plans, without relying on disconnected, manually updated spreadsheets.
The new Portfolio > Capacity Planning page provides a staging environment for portfolio, product, and engineering leaders to collaborate ahead of release planning — without impacting the productivity of Agile teams that are busy delivering on the current quarter’s commitments.
Planners can play what-if scenarios to optimize the value of their near-term delivery plans, as well as create longer-term plans to inform hiring decisions. By creating multiple scenarios, business and technology leaders can review the realistic options of turning business initiatives into action before deciding on the final game plan.Less is More
It’s hard for businesses to accept the paradox that the less you do, the more you actually get done. Working on 10 different things at once is the recipe for delivering none of them.
The magic of the new Capacity Planning page is its sheer simplicity in visually identifying the right teams and the right scope — and right amount of scope — to bring into a quarterly release planning event. The page is instrumental in helping organizations build the predictability their business expects, and that predictability only comes when the right work and the right amount of work flows through coordinated, stable teams that have learned to work together to deliver quality, fast.
The Portfolio > Capacity Planning page
The new page is driven by four inputs:
Planning timebox: To adapt quickly to market and business changes, planners should have defined their continuous planning cadence. Using the planning timebox, they can select the time span for their capacity plans — from a single quarter or release for near-term planning, to multiple releases.
Prioritized feature backlog: Product managers should have validated a clear and ranked list of coarsely described features deemed most valuable to the business, tolerating incomplete data by delaying more detailed feature descriptions until what fits in a release is identified with the capacity planning cut line.
Rough estimates: Estimation teams — typically comprising team leads, architects, and other experts — should have provided roughly right estimates, tolerating incomplete data until release planning when those doing the work can provide more-refined estimates without impacting team productivity.
Teams: Engineering directors should have identified the teams involved in the capacity plan, following the team as the resource unit recommendation over individual roles and skill sets that provide a false sense of precision and accuracy.
The Rally Capacity Planning page delivers immediate benefits:
Limit WiP: Being able to see when capacity is reached ensures planners only schedule the work that matters most, and delivery teams can focus on delivering the plan faster.
Delivery predictability: By focusing on fewer features that matter most (as opposed to constantly context switching), teams can build delivery plans with predictable outcomes.
No time wasted detailing features for which teams don’t have capacity.
A solid, realistic plan to bring into release planning that optimizes the business investment in that event.
The Capacity Planning page has even more benefits that become obvious after you start using it. Our early adopters found the page instrumental in removing the emotions from deciding what Agile teams should work on by matching demand and supply in a visual, data-driven, quantitative way.
Quantitatively matching actual capacity to business demand with a dynamic cut line
When business leaders were too busy to collaborate in release planning, early adopters used the new page to present different scenarios instead of saying “We can’t do it all.” Executives were more engaged and appreciated the opportunity to review alternate, realistic options.
Last but not least, there’s an acute shortage of skilled development professionals. Businesses seeking to retain existing talent and attract new talent need to create an inviting development environment that respectfully balances employees’ time and capacity.
The capacity planning capability is the result of a year-long engagement with customers to understand how to best support Agile organizations in effectively leveraging the power of stable, cross-functional teams to meet growing and changing business demand. We’d like to extend a heartfelt thank you to the customers who helped us validate this functionality over the past year.
On June 17, Rally® Unlimited Edition customers will have access to the new Capacity Planning page and all the benefits that come with it — just contact your Rally Solution Architect to get the capability enabled in your subscription.
For more information about capacity planning for the fast-paced world, download the white paper.
This article details a team’s experience in implementing pair programming as a way to get work done as part of its agile transformation. It delves into the many positive results from the pairing experiment, as well as some of the negatives that were encountered, and weighs whether developers think pair programming is a worthwhile endeavor.