We have an interesting problem in some projects. Agencies, consulting organizations, and consultants help their clients understand what the client needs in a product. Often, these people and their organizations then implement what the client and agency develop as ideas.
As the project continues, the agency manager continues to help the client identify and update the requirements. Because this a limited time contract, the client doesn’t have a product manager or product owner. The agency person—often the owner—acts as a product owner.
This is why Marcus Blankenship and I have teamed up to offer Product Owner Training for Agencies.
If you are an agency/consultant/outside your client’s organization and you act as a product owner, this training is for you. It’s based on my workshop Agile and Lean Product Ownership. We won’t do everything in that workshop. Because it’s an online workshop, you’ll work on your projects/programs in between our meetings.
If you are not part of an organization and you find yourself acting as a product owner, this training is for you. See Product Owner Training for Agencies.
This question begs to be answered. Especially in the wake of the recent breaches in digital security across just about every government agency. So, how important is security on the projects that we manage? Well, that depends on several variables:
- Who’s projects are you managing?
- What type of data are you handling?
- Are you working on government or private sector projects?
- If customers are external to your organization, do they care enough to spend money on the risk and security planning?
Security is important no matter the project
The real answer to the question this article asks should always be “yes.” It really shouldn’t matter what type of data you’re managing on your project, you need to protect it. And even if you are managing nothing of any real sensitivity, paying attention to security will only help your organization and your customer. You don’t want your project to be the weak link into sensitive data your company handles or your customer is storing. You never know what window of opportunity your project might open into other sensitive data and information that may have nothing at all to do with the current project.
So, we’ve established that we should care about security…now what do we do?
Plan, plan, plan
To start with, plan like crazy…but don’t take too long. The problem with risk planning – and that is really what I’m talking about here – is something that little, if any, thought is really given to at the project level. And if risk planning is part of the project process and timeline, too often security is given almost no attention at all.
Make sure others are paying attention to your project
Data security…that’s the IT Director’s problem, right? Ummm…could be. But would you trust someone else with your sensitive data? I’m not saying IT directors and security analysts aren’t doing their jobs, but they may not have a vested interest in YOUR project. Your project may get protected by whatever security measures they have taken, but there is no guarantee of that. Meet with them…make your project important to them. Scream loud…if you aren’t heard and nothing is done, then it’s all on you. It’s not about the blame game here – but you do need to consider the consequences as a project manager and as part of your overall risk management.
Educate those on the project about the need for data protection, the potential consequences, and the sensitive nature of what your project is handling. Educate and inform the team, educate and inform the customer, and educate and inform your senior management. You may be overly concerned, you may be blowing it out of proportion, you may be screaming too loud…but the house with the outside lights, locked doors and several cars on the driveway is not the house that is going to get broken into randomly in the middle of the night. The potential perpetrators will move on to the next house. Trust me. Some security can go a long way in thwarting 90% of the threats.
The best thing you can do for your project and for the integrity and safety of your project’s data – sensitive or otherwise – is to plan, be aware, make others aware, and educate. The bottom line is that it’s all about communication. Security is important so you can’t assume these things are happening. I’m sure that these federal agencies didn’t see this huge data breach coming, but it did. Find out what security measures your organization takes for such data breaches and figure out where project dollars need to be spent in order to protect your project. You won’t be sorry.
74% of projects are successful at companies where sponsors have expert or advanced project management knowledge, yet the 62% of companies do not provide executive sponsor education.
Make sure your next project is successful by reviewing these six resources for executive sponsors.
An in-depth research report from the Project Management Institute uncovering the three primary factors that can limit or inhibit executive sponsors’ ability to be effective.
This Harvard Business Review article describes the keys to communication between the executive sponsor and project manager.
In this article Jon Hughes, Head of Program Management Consulting at Cognizant describes the twelve personal traits of a successful executive sponsor.
This blog post highlights seven tips for communicating with executive sponsors and stakeholders that will help your team engage with the key leaders of the organization.
This article discusses what an executive sponsor can do to ensure the success of projects.
This Harvard Business Review article explains how to garner sponsorship but avoid being steered toward experimenting in a large, public, fashion that failure results in shuttering the innovation effort.
What are some other good resources you would recommend?
Welcome to Axosoft’s SECRET MENU! Each new menu item is a special blend of Axosoft that will show you how to use our tool to accomplish very specific things. It’s kind of like going to In-N-Out and ordering your burger “animal style,” except our Secret Menu items make you feel far more accomplished and a lot less guilty.
Our first Secret Menu item is highly requested: EPICS. Epics are a popular agile approach for tackling larger endeavors that can span over multiple sprints. While different sources define epics in different flavors, we can essentially just think of them as large user stories.
So what’s the best way to organize your epics in Axosoft?
Create an epic backlog with a subfolder.
Axosoft lets you nest as many subfolders as you need within the projects tree of the Organize panel. As a result, many of our agile customers have come to include all the user stories that span over multiple sprints in a defined epic backlog.How to delegate epic user stories Plan out your epic timeline.
First create a subfolder by selecting the target project folder in the Organize panel and then clicking Add. This will allow you to nest a subfolder. You can even nest a subfolder under the subfolder and still have all your items roll up to the parent project folder.After clicking the highlighted Add button, add your subfolder
Splendid, you now have your epic backlog. From here your team may create, import, or reassign user stories to this epic folder for grooming. Consider breaking your user stories down further into subitems as you groom your items. Your epic backlog has access to all the ranking, grouping, and filtering capabilities you’ve come to know with any of your other product backlogs, so make gratuitous use of them. Furthermore, because your epic backlog is nested underneath the parent project, you can rank your epic items against all the other user stories your team is responsible for completing. Just select the parent project and get ranking.Rank epic backlog items against other items in your product backlog. Note the epic items we marked with a blue star.
At this point, we recommend assigning your ranked epic items across multiple sprints or releases (along with the other backlog items that make the cut). You may find your team either assigning all the epic items well in advance, or with one sprint planning meeting at a time. Axosoft can handle either approach.By grouping by release, we can see where all our epic items have been assigned.
The image above groups all the items in my backlog by release, which makes it great for seeing the totals for time worked, time remaining, and percent complete. Consider taking this same view but with Card View to include a more visual picture of where items are in the workflow. This view makes it easy to reassign unfinished user stories to the next sprint with a simple drag and drop.What about themes?
You may have noticed that you can use subfolders for another agile approach; themes. Themes are similar but take a different approach to epics. Themes are groups of user stories that are related but can be completed together within one sprint cycle. You can definitely take advantage of subfolders for theming items, or alternatively use the Related Items feature in Axosoft.
Keep in mind that epics, user stories, and themes are all agile buzzwords. The true goal is to get your software, product, or service out the door and delight your customers. That said, we’re proud to mix up this custom flavor of Axosoft to meet your epic needs.
Let us know what Secret Menu item you’d like to order next! Or stay tuned to see what we add to the menu next.
There is so much I’ve been wanting to write the past year or so about the business of LeadingAgile. Those of you following our blog for a while will know that it wasn’t all that long ago that I was working at VersionOne, left for Pillar, and then started out as an independent consultant and formed LeadingAgile.
I got really busy really fast and quickly started selling more work than I could do alone. So I began growing the team. Over the past few years we’ve built a really awesome group of consultants and an equally awesome group of support staff to help us run our operations. There are about 40 of us now and we are still growing.
I’ve always felt that our approach was unique enough that we needed a team of dedicated folks that were totally bought into our system, could grow with us as we evolved our understanding of our models, and were readily available when we needed them. For those reasons, we’ve always hired rather than using subcontractors.
People ask me all the time how we hire at LeadingAgile given that many of our contracts are short term and we never quite know where the work is going to come from. Lot’s of companies use subcontractors to mitigate that risk, but since we’ve decided to absorb that risk internally, we have to have a plan.
That’s a little of what I want to share with you today.
We started LeadingAgile with effectively no money in the bank. There was no venture funding, no nest egg to draw on, not even a credit card to live off of when I got this started. Risk management went something like this… how much do I need to pay my bills and where do I think I can go to get that work.
I was fortunate to have friends in the industry that said they could subcontract work to me if I needed it… and that was my safety net. By that time I was pretty well networked here in Atlanta, so I took a chance. Fortunately for my wife and kids… everything worked out. We didn’t go bankrupt.
I started earning more money than we were spending, so we used the extra to get out of debt and build working capital. After about a year and a half, we used some of that working capital to hire our first consultant. Having someone to share the workload allowed me to write more, speak more, and sell more.
As our client list grew, we began hiring more consultants and building our staff. Over time we’ve gotten LeadingAgile to the size it is today, and we’ve built a foundation that can support doubling or tripling our consulting team as demand continues to rise. We’ve learned a lot doing it.
Over time, I’ve learned that we have four major risk areas… variables maybe… that we have to constantly manage in order to successfully run our company.
1. Working Capital – at any given time we need to have sufficient working capital avaiable to weather a storm or to invest in new opportunities. As we make hiring and growth decisions, we never know which of those new opportunities are going to play out. Understanding how long we can maintain the company without having to let anyone go, or adjust our strategy, is a key factor in decision making.
2. Utilization – We always have the choice to deliver work or to hold off. We can often work with our clients to go faster or slower depending on what they are trying to accomplish and the availability of our team. Understanding the rate we want to burn down our backlog of work is critical. Consultants on the bench are like spoiled inventory. Once a day is passed, you can never bill for it.
3. Sales – We are constantly marketing LeadingAgile and our ideas. We are constantly building relationships with people that might buy from us now or someday in the future. We can attempt to accelerate our sales pipeline or slow it down. Sometimes we don’t want a deal to close because we can’t effectively service it. Other times we need deals to close because we have people on the bench.
4. Growth – If we sell more business than we have staff to deliver, then we have to think about growing our team. We can’t grow our team just in time, so we have to invest, bringing people in early, getting them up to speed with our approach, and having them shadow our current consultants, so they are fully prepared to be part of a transformation team if and when the new business gets signed.
If you graph these variables, it looks something like this…
The green line represents the maximum revenue we could realize in a given month. The red line represents our break even revenue for the month. The blue line shows what we are actually expecting to deliver in any given month. The general theory is that if we stay in between the maximum and minimum every month, we are in a good place and can sustain the company.
But here is the deal… we know our fixed cost, we know our variable costs, we sometimes can predict utilization in a given month, but more than a month or two out is a crap shoot. Even within a given month lots of things can happen. We never know exactly what deals are going to sell, what deals or going to continue, or what deals are going to end. The uncertainty at times can be mind-numbing.
One of my folks said yesterday, it feels like we are always on the verge of having 10 people on the bench or hiring 10 people, we just don’t know which.
So here is how we think about managing the company in the face of this kind of extreme uncertainty.
Our job is make sure that we have as many options available as possible at all times to maximize the chances of good stuff happening. We always want to have a fall back plan if something bad happens.
For us that means the following…
1. Working Capital – We always want to have enough working capital to survive if our revenue falls below the break even threshold in a given month. Ideally, I’d like to be able to survive 6-12 months running at a loss. Now granted, if that happened there would be other fundamentals to work on, and maybe we’d have to acknowledge we were spending too hot or had a bad strategy, but having financial safety prevents you from making rash decisions.
2. Utilization – We try to create options with our clients so we have some room on existing engagements in case one clients slows down and another client needs some extra help. We encourage and support our consultants bringing other team members into their engagements whenever possible, even if it’s not in a billable capacity, so that there is greater familiarity with each other and we all know how each other work. The better we work together, the more portable we are between accounts.
3. Sales – We try to maintain about four times the level of active business development than we think we could ever win, or that we think we could even do, because you never know when something is going to fall through. You can never directly influence the buying cycle of a client, so having lots of opportunities in the pipeline at any one time increases the chances that something will work out when you need it. We spend a ton of time educating folks on our approach before the sale, so managing the pipe is a lot of work.
4. Growth – And when we are really good at all this, firing on all cylinders, and everything closes at once, we might find ourselves with more work than we can actually do. We maintain relationships with a ton of great consultants out in the industry, and are always on the lookout for more great people to add to the team. When we need to hire, it’s important that we have a list of folks that are ready to come work for us when we need them. Our people (and our approach) are fundamentally what we sell.
What this basically means is that we are constantly forecasting forward, assessing the probability that utilization is going to be high, that clients are going to continue, or that new deals are going to close. We assess our level of working capital and regularly place bets on future outcomes. We bet on deals, we bet on people, we bet on cash flow. The goal is to manage risk such that we make more good bets than bad.
Our experience has been that if we do the right things with our money, we are constantly doing the right things for our clients, we are super diligent about managing the sales process and making sure we are talking to new companies all the time, and we always have a solid pipeline of great people to come work for us… we have a shot at making all this work. So far, we’ve had a good run.
The key point in all of this, is that nothing in anything we do is actually knowable. We can model it. We can make informed predictions. But we can never know it for sure. We live in a world of creating options, managing risk, making good decisions, and having safety in the bank if things don’t play out like we’ve planned. Having more options than we need is they key to sustaining and growing our company.
As I take a step back and look at where we’ve been over the past five years, it’s a really fascinating journey. Applying concepts like Lean Startup and Real Options when you’ve got the livelihood of forty families, and the trust of a hundred or more clients, riding on your success is pretty sobering. For me it’s a testament to how powerful these concepts are when you strive to authentically apply them to your work.
A lot of agile literature stresses that product owners must prioritize the delivery of value. I’m not going to argue with that. But I am going to argue that product owners need to optimize over a slightly longer horizon than a single sprint.
A product owner’s goal is to maximize the amount of value delivered over the life a product. If the product owner shows up at each sprint planning meeting focused on maximizing the value delivered in only that one sprint, the product owner will never choose to invest in the system’s future.
The product owner will instead always choose to deliver the feature that delivers the most value in the immediate future regardless of the long-term benefit. Such a product owner is like the pleasure-seeking student who parties every night during the semester but fails, and has to repeat the course during the summer.
A product owner with a short time horizon may have the team work on features A1, B1, C1 and D1 in four different parts of the application this sprint because those are the highest valued features.
A product owner with a more appropriate, longer view of the product will instead have the team work on A1, A2, A3 and A4 in the first sprint because there are synergies to working on all the features in area A at the same time.
Agile is still about focusing on value. And it’s still about making sure we deliver value in the short term. We just don’t want to become shortsighted about it.
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?
I don’t always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know. But I can put here what comes to mind at the moment:
Look at your acceptance criteria. There is often some aspect of business value in each acceptance criteria that can be split out into a separate story that is valuable to the Product Owner.
Consider the tasks that need to be done. Can any of them be deferred (to a later sprint)? (And no, testing is not a task that can be deferred to a later sprint.) If so, then consider whether any of them are separately valuable to the Product Owner. If so, perhaps that would be a good story to split out.
If there are lots of unknowns, if it’s a 13 point story because of unanswered questions, make a list of the questions and uncertainties. For each, ask whether it’s a Business Analyst (BA) to-do or a Tech to-do. Also ask for each whether it’s easy and should be considered “grooming”. If it’s significant enough and technical, maybe you should split that out as a Research Spike. Then make an assumption about the likely outcome of the spike, or the desired outcome of the spike, note the assumption in the original story, and reestimate the original story given the assumption.
Look in the story description for conjunctions since and’s and or’s are a clue that the story may be doing too much. Consider whether you can split the story along the lines of the conjunctions.Other Story Splitting ideas:
- Workflow steps: Identify specific steps that a user takes to accomplish the specific workflow, and then implement the work flow in incremental stages
- Business Rule Variations
- Happy path versus error paths
- Simple approach versus more and more complex approaches
- Variations in data entry methods or sources
- Support simple data 1st, then more complex data later
- Variations in output formatting, simple first, then complex
- Defer some system quality (an “ility”). Estimate or interpolate first, do real-time later. Support a speedier response later.
- Split out parts of CRUD. Do you really really really need to be able to Delete if you can Update or Deactivate? Do you really really really need to Update if you can Create and Delete? Sure, you may need those functions, but you don’t have to have them all in the same sprint or in the same story.
Some of the phrases in the above list may be direct quotes or paraphrases from Dean Leffingwell’s book “Agile Software Requirements”.
At my current company I’ve been going out to lunch pretty much every day I’m in the office. I know a lot of developers bring their lunches and like to eat alone in silence, but I’m probably less on the introvert side. I’ve always made it a point to have lunches with developers on a regular basis, but my current standing lunches with have been an evolution of that.
Breaking bread and catching up on stories, families, etc are a great way to bond with developers you don’t work with on a regular basis. Most of the engineers I go to lunch with work on another team, so I’m constantly keeping up to date with their current work and letting them know about what my team is doing. As a bonus I get out of the office and eat some hot food, though not necessarily the healthiest fare. Sharing and communication between teams really helps even in a flat startup organization like ours. I know some companies have meals catered in the office which works as well, but if you’re at a regular place, lunch out can work just as well.
As a suggestion if you tend to eat your lunches alone or at your desk, try to make a habit of eating out with some other devs or even other employees at least once a week.
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.