I think I’ve come to the conclusion that ‘agile’ as we know it isn’t the best starting place for everyone that wants to adopt agile. Some folks, sure… everyone, probably not.
For many companies something closer to a ‘team-based, iterative and incremental delivery approach, using some agile tools and techniques, wrapped within a highly-governed Lean/Kanban based program and portfolio management framework’ is actually a better place to start.
Well, many organizations really struggle forming complete cross-functional teams, building backlogs, producing working tested software on regular intervals, and breaking dependencies. In the absence of these, agile is pretty much impossible.
Scrum isn’t impossible, mind you.
Agile is impossible.
So how does a ‘team-based, iterative and incremental delivery approach, using some agile tools and techniques, wrapped within a highly-governed Lean/Kanban based program and portfolio management framework’ actually work?
Let me explain.
First, I want to form Scrum-like teams around as much of the delivery organization as I can. I’ll form teams around shared components, feature teams, services teams, etc. Ideally, I’d like to form teams around objects that would be end up being real Scrum teams in some future state.
These Scrum-like teams operate under the same rules as a normal Scrum team, they are complete and cross-functional, internally self-organizing, same roles, ceremonies, and artifacts as a normal Scrum team, but with much higher focus on stabilizing velocity and less on adaptation.
Why ‘Scrum-like’ teams?
These teams have business process and requirements dependencies all around them. They have architectural dependencies between them. They have organizational dependencies due to the current management structure and likely some degree of matrixing.
Until those dependencies are broken, it’s tough to operate as a small independent Scrum team that can inspect and adapt their way into success. Those dependencies have to be managed until they can be broken. We can’t pretend they aren’t there.
How do I manage dependencies?
This is where the ‘Lean/Kanban’ based program and portfolio governance comes in. Explicitly model the value stream from requirements identification all the way through delivery. Anyone that can’t be on a Scrum team gets modeled in this value stream.
We like to form small, dedicated, cross-functional teams (explicitly not Scrum teams) to decompose requirements, deal with cross-cutting concerns, flow work into the Scrum-like teams, and coordinate batch size along with all the upstream and downstream coordination.
Early on, we might be doing 3-6-9 even 12-18 month roadmapping, creating 3-6 month feature level release plans, and fine grained, risk adjusted release backlogs at the story level. The goal is to nail quarterly commitments and to start driving visibility for longer term planning.
Don’t really care, this is a great first step toward untangling a legacy organization that is struggling to get a foot hold adopting agile. Many companies we work with, this is agile enough, but ideally this is only the first step toward greater levels of agile maturity.
How do I increase maturity?
Goal #1 was to stabilize the system and build trust with the organization. This isn’t us against them, it’s not management against the people, it’s working within the constraints of the existing system to get better business results… and fast.
Over time, you want to continue working to reduce batch size at the enterprise level, you want to progressively reduce dependencies between teams, you want to start funding teams and business capabilities rather than projects, you want to invest to learn.
Lofty goals, huh?
That said, those are lofty goals for an organization that can’t form a team, build a backlog, or produce working tested software every few weeks. Those are lofty goals for an organization that is so mired in dependencies they can’t move, let alone self-organize.
Our belief is that we are past the early adopters. We are past the small project teams in big companies. We are past simply telling people to self-organize and inspect and adapt. We need a way to crack companies apart, to systematically refactor them into agile organizations.
Once we have the foundational structures, principles, guidelines in place, and a sufficient threshold of people is bought into the new system and understands how it operates, then we can start letting go, deprecating control structures, and really living the promise of agile.
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.
We launched the wildly successful #ItWasNeverADress campaign to inspire the next generation of women to pursue STEAM (science, technology, engineering, arts, and mathematics) fields. To continue this movement, we created a conference for girls between the ages of 12 and 17 and worked with local schools and nonprofit organizations to hand select 50 girls to attend.
Over the course of two days, these girls will learn valuable tools to take on the tech world and the challenges that surround it with gusto! The conference will be hosted at Axosoft Headquarters and feature renowned speakers and community leaders teaching cutting edge curriculum and hands-on, interactive workshops. Girls will learn programming skills from David Dodge, Founder of CodaKid; how to “reprogram” their inner critic and build confidence from Hilary Weber, CEO of Opportu; socially conscious marketing from Evan Clark, Founder and Creative Director of Spectrum Experience; identity development and anti-bullying tactics from Melissa Medvin, Associate Director of the Anti-Defamation League; engineering skills to create wearable technology (capes!) by Artist and Professor of Art at ASU, Hilary Harp; and more!
At the end of the conference, the girls will leave with a business plan and resources to go back into their schools and start a STEAM focused club, organization, and/or be able to help infuse STEAM into the curriculum at their schools. As an #ItWasNeverADress Ambassador, they will also receive the support of an advisory board made up of influential community leaders who will contact them quarterly to offer guidance.
And, to offer future opportunities to girls pursuing a degree in the STEAM fields, we started a scholarship for need-based, under-represented individuals through ASU. We’re taking the profits from #ItWasNeverADress merchandise sales and putting them directly into the scholarship!
The only thing left to say is… FULL STEAM AHEAD!
Which form of industry growth would you prefer - why?
Which path leads toward the culture you desire in a software development organization?
This is a wonderful article on the topic - read it and discuss with your colleagues.
Programmers don’t need a union. We need a profession. BY MICHAELOCHURCH
"Unions work best for commodity labor, and I use that term non-pejoratively. Commodity work is easily measurable and people can often be individually evaluated for performance. For example, a fishing boat operator is measured according to the quantity of fish she procures. A lot of very important work is commodity labor, so I don’t intend to disparage anyone by using that term. Commodity work can be unionized because there aren’t large and often intangible discrepancies in quality of output, and collective bargaining is often the best way to ensure that the workers are fairly compensated for the value they produce. Software is not commodity work, however. It’s difficult to measure quality, and the field is so specialized that engineers are not remotely interchangeable. When the work is difficult to measure and large disparities of quality exist, you have a situation in which a certain less-egalitarian (in the sense of allowing top performers to receive high compensation, because it’s essential to encourage people to improve themselves) and more self-regulatory structure is required: a profession.""A profession is an attempt to impose global structure over a category of specialized, cognitively intensive work where the quality of output has substantial ramifications, but is difficult (if not, in the short term, impossible) to measure, giving ethics and competence primary importance. A profession is needed when it’s clear that not everyone can perform the work well, especially without specialized training. Here are some traits that signify the existence of a profession."1) Ethical obligations that supersede managerial authority.
2) Weak power relationships.
3) Continuing improvement and self-direction as requirements.
4) Allowance for self-direction.
5) Except in egregious cases, an agreement between employee and firm to serve each others’ interests, even after employment ends.
I published my most recent newsletter, Creating Trustworthy Estimates, this past week. I also noted on Twitter that one person said his estimates created trust in his organization. (He was responding to a #noestimate post that I had retweeted.)
Sometimes, estimates do create trust. They provide a comfortable feeling to many people that you have an idea of what size this beast is. That’s why I offer solutions for a gross estimate in Predicting the Unpredictable. I have nothing against gross estimates.
I don’t like gross estimates (or even detailed estimates) as a way to evaluate projects in the project portfolio because estimates are guesses. Estimates are not a great way to understand and discuss the value of a project. They might be one piece of the valuation discussion, but if you use them as the only way to value a project, you are missing the value discussion you need to have. See Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.
I have not found that only estimates create trust. I have found that delivering the product (or interim product) creates more trust.
Way back, when I was a software developer, I had a difficult machine vision project. Back then, we invented as we went. We had some in-house libraries, but we had to develop new solutions for each customer.
I had an estimate of 8 weeks for that project. I prototyped and tried a gazillion things. Finally, at 6 weeks, I had a working prototype. I showed it to my managers and other interested people. I finished the project and we shipped it.
Many years later, when I was a consultant, I encountered one of those managers. He said to me, “We held our breath for 6 weeks until you showed us a prototype. You had gone dark and we were worried. We had no idea if you would finish.”
By that time, I had managed people like me. I asked them for visual updates on their status each week or two. I had learned from my experiences.
I asked that manager why they held their breath. I always used an engineering notebook. I could have explained my status at any time to anyone who wanted it. He replied, “We so desperately wanted your estimate to be true. We were so afraid it wasn’t. We had no idea what to do. When you showed us a working prototype, that’s when we started to believe you could finish the project.”
They trusted my initial estimate. It’s a good thing they didn’t ask for updated estimates each week. I remember that project as a series of highs and lows.
That’s the problem with invention/innovation. You can keep track of your progress. You can determine ways to make progress. And, with the highs, your meet or beat your estimate. With the lows, you extend your estimate. I remember that at the beginning of week 5 I was sure I was not going to meet my date. Then, I discovered a way to make the project work. I remember my surprise that it was something “that easy.” It wasn’t easy. I had tracked my experiments in my notebook. There wasn’t much more I could do.
Since then, I asked my managers, “When do you want to know my project is in trouble? As soon as it I think I’m not going to meet my date; after I do some experiments; or the last possible moment?” I create trust when I ask that question because it shows I’m taking their concerns seriously.
After that project, here is what I did to create trust:
- Created a first draft estimate.
- Tracked my work so I could show visible progress and what didn’t work.
- Delivered often. That is why I like inch-pebbles. Yes, after that project, I often had one- or two-day deliverables.
- If I thought I wasn’t going to make it, use the questions above to decide when to say, “I’m in trouble.”
- Delivered a working product.
Estimates can be useful. They can show you the risks. And, I’m sure that only having estimates is insufficient for building trust. If you want to learn more about estimation, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.
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.
Everyone talks about the importance of collaboration in our projects. Collaboration is defined as “the action of working with someone to produce or create something,” but it is also defined as “traitorous cooperation with an enemy.” Oops. What are we talking about here? We all know it is the former, not the latter! But seriously, haven’t we been collaborating on projects for decades? Well, yes and no. We have been “collaborating,” but we can and should be doing a better job at it, with the tools we have now that weren’t really available before. A file drawer in the project manager’s office or cubicle is not a real collaborative tool – especially if it’s a locked cabinet and only the PM has the key and he/she is traveling or on vacation. So the PM of the ’80s and even ’90s was not truly collaborative and desired ‘collaboration’ wasn’t really feasible. Now it is – on the cheap… and sometimes even for free.
So what does it mean to be collaborative? In my book – for the purposes of project management – these are three key concepts of project team/customer collaboration:
Sharing all project documents. All key project documents – the statement of work (SOW), charter, communication plan, design documents, requirements documents, risk register and log, issues list, status reports, current and past versions of the project schedule and just about anything else relevant to the project – should be shared. That can be through a file management software, inside a collaborative project management software tool, on a shared drive – cloud or otherwise – that each team member (and, for some docs, maybe the customer) can access at any time from any place. Or, for a smaller project, document sharing may occur through a social media group (e.g., a closed Facebook group with docs stored for the group). The sharing environment must be one where docs can be retrieved, revised, etc. The key is to not hold up peer reviews of deliverables and revisions of assigned documents but rather to speed up that process and make it more visible and openly accountable for the assigned person or persons.
Making joint project decisions and sharing information. A central communication tool is critical here for full and useful project collaboration. Depending on the size of the project, this may be a collaborative project management tool, or it may be a social media group or private chat area, or all of the above. The key is to enable – not hinder – swift and open communication between individuals and/or to the entire group depending on the topic and need at any moment. Again, you may want to include the project customer in this collaboration as a helpful and easy way to keep them engaged – but be careful. Too much visible communication between project team members on possible options and decisions can make a customer anxious, so use this at your own discretion.
Working closely in real time with the project team and customer. Again, this can be accomplished through a collaborative project tool, a closed social media group, or some tool that allows for real-time discussion and sharing of information. The key concept here is “real time.” Email – while great – often isn’t real time due to delays or recipients’ lack of availability. Also, believe it or not, some people still don’t have email on their smart phones because it’s not the easiest thing to setup and some people just don’t want it.
What is collaboration? It is what we need to share information and documents quickly and accurately. It is what we need to share information and feedback in real time. Some projects are small or not mission critical, and in such cases it’s ok to have a day’s delay in responding. However, this is rarely the case nowadays. Real-time communication and the ability to respond quickly is ideal for collaboration, and will make for the happiest project client possible. Plus, the cohesiveness of the team is only strengthened with such collaborative tools and the abilities they provide teams and customers alike.
Axosoft is a tool that project management teams use for real-time communication and genuine collaboration. Axosoft provides wiki pages which are a great solution for sharing documentation and keeping everyone on the latest version. Their branded Customer Portal offers a way to publicize specific projects, releases, wiki pages, and other development information that’s necessary for making joint decisions. You can also opt to engage customers by sharing certain project data through public dashboards. And although email isn’t always the best solution for team communication, Axosoft’s customizable email notifications serve as a helpful extra layer of communication to push critical project information to the right people. You can also integrate Axosoft with tools like Slack to communicate in real-time.
I’m happy to announce that Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule is done and available. It’s available in electronic and print formats. If you need a little help explaining your estimates or how to use estimation (even #noestimate), read this book.
“The Emperor’s New Clothes” is a short tale by Hans Christian Andersen about two weavers who promise an Emperor a new suit of clothes that is invisible to those who are unfit for their positions, stupid, or incompetent. When the Emperor parades before his subjects in his new clothes, no one dares to say that he doesn’t see any suit of clothes until a child cries out, “But he isn’t wearing anything at all!”
Something has been nagging at me for a while. You’ll see shades of it underlying the themes in my last several blog posts. You’ll see it embodied in the messaging on our website. You’ll see it in the very fabric of our company and how we approach our work.
It’s this notion that if agile doesn’t work it’s somehow your fault.
Everything we read and hear about agile is that we are supposed to empower people, let them self-organize, that the people closest to the work are best at deciding how to do the work. If only us managers would get out of the way, that would solve everything.
That sounds great… until it doesn’t work.
What’s the story told to us when it doesn’t work? We are told that maybe we just didn’t get it? That we weren’t agile enough? Maybe it’s that our culture is broken or that our leadership is too command and control? If we just had the right mindset, all would be right with the world? Call me when you’re actually ready to change. Right?
Do we ever question if self-organization really works?
Everyone has all these great success stories with agile. If I’m the guy that says agile doesn’t work, I must be the one that doesn’t get it? Maybe the culture I created is broken? Maybe I’m the one who is too command and control? Maybe it’s me that doesn’t have the right mindset? Maybe… but, I think there is more to the story.
It dawned on me the other day ‘the emperor has no clothes’.
Self-organization works in the context of small, cross-functional teams, teams that have clarity of purpose, teams that have everything and everyone necessary to deliver a working tested increment of the product on regular intervals. It works when the team has the autonomy to decide.
The question is this… will people self-organize into teams and systems that support this kind of delivery model? There are many things about this kind of system that are counter-intuitive. They definitely go against how people are used to working. Maybe someday… but probably not right out of the gate… at least not enough of them.
Many of us are selling something that just isn’t true.
I don’t mean that in an ugly way… I think many of us have ultimate faith in human potential and want to believe this will work. I think that’s good. I might even allow that in certain contexts, under the right conditions, fully self-organizing systems actually could work. The problem is that it doesn’t work in enough contexts enough of the time. I’ve seen too many data points to the contrary.
Let’s just say it… the emperor has no clothes
The problem is that many folks think very linearly. Many folks are married to old beliefs. Many folks are not systems thinkers. Many folks want to locally optimize. Some of us bring personal agendas, individual goals. Some of us are narcissistic sociopaths. Some are just scared to change.
It’s not that we are all bad people… we just think differently.
I do not believe that self-organization will work in organizations when there is misalignment between the technology organization and the business. I do not believe that self-organization will trump legacy financial controls and crushing dependencies between systems. The forces working against change are too great.
Because we believe so deeply that self-organization works. Because it’s not popular to think that anything less than total empowerment of the individual could possibly make a difference or be of value… because we don’t want to be accused of being ‘command and control’… we do nothing.
Revolution or evolution… it’s your call
The real problems facing companies today can’t be solved by self-organization alone. We are talking about a major architectural refactoring in many companies. We have to address business architecture… technology architecture… organizational architecture. We have to create alignment between these three.
We have to redesign how work get’s funded. We have to redesign how commitments are made. We have to redesign how we make economic tradeoffs in the face of limited resources to do the work… all while we manage to stay in business. These are not cultural problems, they are systems problems.
Most of us don’t operate with a fundamental theory of how organizations are supposed to work. How can we be expected to self-organize this kind of system?
Rest assured, these are solvable problems… but first you have to buy into the nature of the problem.
If we define it as a culture problem or a process problem… we fail.
If we recognize it as a systems problem… we have a shot at fixing it.
In the absence of simply telling folks to self-organize, where do you start?
Understand where you are and where you want to go
I’ve been speaking publicly the last year or so around a model we created to help companies sort out their goals and objectives, to help them decide what they want to be as a company and to understand where their markets want them to be.
We call this model ’The LeadingAgile Compass’
Here is a link to the full explanation of the compass:
We’ve also been using the metaphor of expeditions and basecamps to explain the incremental and iterative nature of transformation. Basically you start with a subset of the organization, get it working quickly in an agile framework, and improve agility over time. Wash, rinse, repeat.
We call this model ‘The LeadingAgile Journey’
Here is a link to the full explanation of the LeadingAgile Journey:
Finally, we’ve been articulating an execution strategy that starts with defining a structure, governance, and metrics framework for the organization… piloting that framework on a single expedition, taking that expedition to the first basecamp, and then broadening the transformation to the larger enterprise.
We call this model ‘The LeadingAgile Roadmap’
Here is a link to the full explanation of the LeadingAgile Roadmap:
Taken together, these models articulate a strategy for planning, executing, and controlling an agile transformation. The hard, cold reality is that many companies will never become more agile unless we can demonstrate early BUSINESS FOCUSED results and a plan for continuous improvement.
The big win here, is that the teams achieve a fairly high level of agility right out of the gate. They get better using team-based, iterative and incremental techniques, while learning the basics of agile early in the process. The organization will quickly stabilize and become predictable.
As your overall understanding of the underlying mechanisms of agility matures, and real impediments are removed, as dependencies are broken, business agility will improve across the entire enterprise.
Does this necessarily preclude self-organization?
Not really. The actual implementation of this transformation framework isn’t dictated by a few consultants or a few executives from some smoky conference room somewhere, it’s done collaboratively with the people involved in the change.
Maybe all we are doing here is giving structure and guidance for self-organization to take place. Maybe.
For me… implementing agile is about forming teams, defining backlogs, and producing increments of working tested products on regular intervals. Breaking dependencies over time is key. Anything that get’s in the way of that is an impediment. Period.
The patterns are well understood, implementation of those patterns is tough. Non-trivial problems I like to say.
Teaching people the basics of Scrum and telling them to self-organize, except in possibly the smallest of organizations, is irresponsible. I think most companies will need more guidance.
Creating the preconditions for agile to thrive is a science that can be understood, planned, executed and measured… even if you let your people self-organize around it. It’s not magic.
Agile fails because the underlying preconditions to do agile well are not clear. You might not have the right mindset, and maybe you are a little too command and control, but that’s not your biggest problem.
Don’t be afraid to speak up when the emperor isn’t wearing any clothes.
The post The Emperor Has No Clothes: A Theory of Transformation appeared first on LeadingAgile.
I was talking with a colleague about project planning and I thought she was asking about projecting an end date for an upcoming development effort. I said, “That’s easy, backlog story points divided by capacity equals days to complete.”
I made a couple of additional comments about dependency management and PTO, then she interrupted my monologue, “the question is not, when will we be done, it’s how do we meet a fixed delivery date.”
“Well, since we’re doing development in sprints, we are always working towards a fixed date.”
She gave me a pained smile, “Okay, wise guy. I guess I really want to know how do we plan to a hard deadline when the release backlog has more story points than the team has capacity. ”
“Well… your backlog is in value order so the pieces with the best return will be at the top of the list. Burn through it and when the delivery date arrives you deliver the most value for the time allowed.”
“That’s still not good enough; we don’t have the capacity to get all the must have stories done. There’s got to be some stuff that’s not so critical. Hopefully we can shave enough points to save the release. But how do we find the extra ones and get them out?”
We took the problem to our resident expert and got this advice: “You need to slice and dice your backlog.”
It’s a given that your backlog has well-groomed features and they have well-groomed stories. But which stories are absolutely critical to the upcoming release? Assigning business value is a necessary starting point, but you need the least amount of capability that makes your product useful. What you’re looking for is the set of Minimally Marketable Features (MMF) and the Minimum Viable Product (MVP). Story mapping is a technique to “experiment” with your backlog and find the MMF and MVP for your product.
Here’s an overview of the process. Find a wall with lots of space for sticky notes. Make a sticky-note for each feature. Leaving space on the left for a column of notes, post the features in a row toward the top of the wall. Now make a sticky for each story and line them up in columns under their respective feature. Finally, select the personas that will use this release of your product. Make a sticky for each and put them in a column to the left of your feature and story grid.
Now it’s time to “connect the dots”. Make a sticky that describes one of the actions and related outcome that a persona takes to engage with your system. Put it to the left of that persona’s sticky and then trace the path through the stories that accomplishes the goal. Have the team in the room to validate the paths and make sure all the steps necessary to complete the action are identified. You’re done for an action when a verified path exists. If you identify a hole in your backlog then write a story, get it into the backlog and onto the board. And remember that some stories may provide more capability than necessary to complete the users’ action. Split that story. Leverage this new understanding; take a moment to try and slice the story even finer. Remind folks of the goal, MMF, MVP.
Repeat the process for each persona and action. Count up the story points that deliver the required actions. Are you still over capacity? If no, you’re done mapping. But if yes, then you have to visit every action again and ask some questions. Do we really have to have this for the release? Can we simplify the approach; do we need all the fields, does the user need a given option on day one? Does completing the actions touch on one or two stories of a given feature; can we leave that one for next time? The plan may include stories to implement an architectural feature. Is this a nice to have platform enhancement that’s lurking in the backlog as a must have?
While the technique can not guarantee you can trim your backlog to fit a fixed release date, the map can let you focus your resources on the few specific stories necessary to delivery the MMF and MVP.
Consultants and tool vendors seem to have a penchant for making things complicated. It seems the more complicated we make things, the more our clients need us. And that sells tools and services, I suppose.
On the other hand, I find unnecessary complexity extremely frustrating. It’s like the novel I read this week by a first-time author. It was good, but it had too many minor characters who complicated the plot and made the book hard to follow.
The same thing happens when people introduce complicated hierarchies or taxonomies for user stories like this:
You don’t need this. When teams are forced to use complicated taxonomies for their stories, they spend time worrying about whether a particular story is an epic, a saga or merely a headline. That discussion is like the minor character who walks into the novel and needlessly complicates the plot.
But, Mike -- I can hear you asking -- you’ve written about epics and themes before.
Yes, but those are labels. A story is a story so my recommended story taxonomy is this:
A story is a story is a story.
Some stories are big and they can be labeled as epics. I’ve used the analogy of movies before. All movies are movies but some movies are romantic comedies—that’s a label, just like epic is.
Similarly, theme refers to a group of related stories, but not does have to work within a hierarchy. Again using movies, I could have a group of spy movies that would include the James Bond movies and the Austin Powers movies. But a group of comedy movies would include Austin Powers but not James Bond.
So, again, theme and epic are labels not an implied hierarchy. Don’t make things more complicated than they need to be. I haven’t come across any reasons to have fancy story hierarchies or taxonomies.
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.