In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful.
"My light bulb moment was during the product demo in the Sprint Review Meeting, when the state of Washington Appellate Clerk of Court told me he and the courts had been waiting 20 years for the feature that our team had just delivered. In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful. He later sent me the requirement spec for the 20-year-old feature and it read just like our epic story and its children we discovered. Yes, this was a completely different system than the previous retired system - yet it had the same customer needs. We had transitioned from a deadlocked in analysis paralysis development group to a Scrum team in under 3 months, delivering into production every month new features, bug fixes, and tested working software." -- David Koontz
See other Light Bulb Moments at Sliger Consulting Light Bulb Moments
Have you seen in other collections of Light Bulb Moments? Please comment below.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Axosoft is dedicated to helping the development community advance by providing quality tools for developers, amongst other initiatives. We know that in order for our community to grow, we need to ensure the next generation of developers like you have the support and tools you need to advance your skills.
So, let’s talk about why students love using Axosoft, and how you can get a free Axosoft student account!Why do students use Axosoft?
Student developers are almost always required to do a capstone project, research project or some sort of group project. Because students oftentimes choose to take online classes, or have to do work remotely (meaning, at home, at the library, or anywhere outside of your classroom), collaboration software is essential to getting these projects completed successfully.UAT students using Axosoft | Photo by Jake Turocy
Students need to be able to communicate and sync up on projects regardless of location. This is where hosted Scrum project management software comes in handy!“Axosoft is a great tool for keeping communication flowing through development teams.”Game Developer Student, UAT Game Studios
Axosoft empowers students to share team goals, assign tasks and keep team members accountable for their work.Why learn Scrum?
Many schools like the University of Advancing Technology (UAT) use the Scrum framework and agile methodologies to teach their students best practices for software development. Scrum and agile have become increasingly popular amongst tech companies, so student developers with an understanding of these concepts have a huge advantage upon entering the workforce.
We’ve created Learn Scrum in Under 10 Minutes, a video which has now been viewed over 1.5 million times (making it the most popular Scrum learning video). It’s used by many Computer Science professors across the world to teach students Scrum. Moreover, our site is dedicated to helping developers learn Scrum in 6 steps.
Professors at UAT and other universities see great success in teaching students Scrum while also having them use Axosoft.How do students use Axosoft?
In general, students find it easy to follow our tutorials and Scrum learning resources to quickly get started working on their projects in Axosoft.UAT students use Axosoft | Photo by Jake Turocy “All students enrolled in the UAT Game Studios track their weekly sprint progress using Axosoft.”Game Developer Student, UAT Game Studios
Students at UAT Game Studios are required to submit screenshots of their Axosoft Release Planners and team burndown charts. This helps students and professors determine each team’s velocity of game production.
It’s easy to know if your project can be completed on time with Axosoft’s custom dashboards, which include burndown charts, velocity calculations and projected ship date widgets.
The kanban board in Axosoft allows students to visualize tasks easily, and know who’s working on what. Plus, you can simply drag and drop items through the workflow steps.
There are many more features that make Axosoft a great, free Scrum project management tool for student developers, such as release planning, task prioritization, team capacity calculations and work logs!How do I get a free student account?
It’s easy to get started with a free Axosoft account for one year! Simply click below to create your free account.
[For the nature of confusion around this terms compare and contrast these: Agile Alliance Glossary; Six Sigma; KanbanTool.com; Lean Glossary.]
The team I'm working with had a toy basket ball goal over their Scrum board... like many cheep toys the rim broke. Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy. The team used "Command Strips" to mount it but they didn't hold for long.
The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart. Not cause and effect, but correlation; have you ever stopped to think what that really means? Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?
I asked the head person at the site for advice, how could we get the goal mounted in our area? He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips. Yes, great minds... but what about getting fired after putting holes in the walls scares one from doing the right thing? How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?
The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done. That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation). Are you starting the clock? It's Dec 7th, lead time starts when Mike agreed to the team's request.
The team was excited, it looked like their desire was going to be granted. Productive would flourish again.
Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor. There were about 4 of these meetings each very short and not always the same people. Team members would come up to me afterwards and ask... "are we still getting the goal?"... "when are they going to bring a drill?"... "what's taking so long?"
Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill. It took about 20 minutes. Basketball goal mounted (Dec 13th) - which clock did you stop? All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).
I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered. In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.
In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary). And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount the goal (100 minutes). Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.
Lead time: Dec 13th minus Dec 7th = 5 work days
Cycle time: hash marks //// (4) one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill; total 100 minutes
Lead Time 5 days; Cycle Time 100 minutes
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements. How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy. Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time. The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.
But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy? Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?
Well it's January 5th and this example came up in a Scrum Master's Forum meeting. After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time. Maybe this is much harder than I thought. Turns out I'm in the minority of opinions - I'm doing it wrong!
Could you help me figure out why my view point is wrong? Comment below, please.
LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time. I see no 'per unit' in their definition of cycle time. The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releaseshttps://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth_Sr.
In a previous post about productivity patterns, I wrote about how I tried countless systems to improve my productivity. I tried everything from having a Franklin Planner, to using GTD, to Personal Kanban and the Pomodoro Technique. I asked myself why some methods worked and some did not. Why did I abandon two systems when I knew so many others have been successful with them? Why has Personal Kanban worked for me for the last 7 years? I started listing common traits and saw relationships and discovered patterns. Not only are there three things I believe every system needs to work, I also see three things that are necessary to prevent you from abandoning that system.
Every personal or professional thing we do is part of a system or subsystem. Those systems have both success and failure patterns.Success Patterns
For a system (defined as a set of principles or procedures to get something done or accomplished) to be successful, you always need ritual and habit.
- A ritual is a series of actions or type of behavior regularly and invariably followed by someone.
- A habit is a regular tendency or practice, especially one that is hard to give up. You need to be habitual with your rituals, as part of your system.
Early indicators that your system will fail include a lack of clarity, progress, or commitment(Very similar to Mike Cottmeyer’s “Why Agile Fails)
- Lack of clarity creates confusion and waste. Each step of a system should be actionable and repeatable. In order to ensure certainty around your system steps, write them down.
- If you lack progress, you will lose momentum. If you lose momentum, you will lose commitment to the system.
- Lack of commitment to the system results in you no longer using the system. You move on to something new to get the results you seek.
After I identified the patterns, I wanted to present a useful model to visualize the indicators that will, in time, cause the system to fail. I decided to base my model on the Business Model Canvas by Alex Osterwalder. Below you will see the five areas that need to be considered. Once complete, if you notice one or more of the sections is ambiguous or short on details, you should view that as a warning.
Scrum Framework Success Patterns
By using the Scrum Framework as an example system, I completed my system design canvas. Upon completion of the worksheet below, I can see if there are any “gaps” in the system. As you may have guessed, there are no gaps, if Scrum is properly implemented and followed. But if it was modified without expert guidance, a gap will become visible and provide an indication that the system is at risk of failure.
Because you may have a large organization where you are dealing with different kinds of dependencies, you may need to create “sub” system design canvases to account for organizational complexity. Scrum may not be enough. Don’t worry. The same rules apply.Free Download
Interested in testing your system or subsystems? Download a free copy of the System Design Canvas and see if you are at risk of failure. Because I am providing this under a Creative Commons Attribution-Share Alike 3.0 Unported license, I welcome you to download it and modify it to meet your needs.
Wondering what other books I should read concurrently with the philosophy of this book, Other Minds, on the mind of our alien ancestors. In chapter one Peter is already mashing up Ismael and Darwin, so I feel it appropriate to do a bit of mix-in myself. I'm thinking Seven Brief Lessons on Physics will add spice. To bad I recycled How to build a Mind at Half Price Books.
I've also got to read Coaching Agile Teams by Lyssa Adkins for work's book club. And I may mix-in a bit of LEGO Serious Play, because I cannot get serious about coaching - seems like a play activity to me.
Maybe I will devise a quadrant model of these books. A Venn diagram of their overlapping topics.
One thousand Words on Metrics
Here's a quote to get you even more interested in clicking that link...
ConclusionIn short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? Well - will you look at that! Yareev's even willing to apply his own metric to his work. What a great example of a leader...
Let’s try that againNew metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.Can you give me some better ideas?Here's my very special response to his request for comments.
I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...
I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD). MTD is calculated much like the old factory sign that said:
"its been 1023 days since we killed someone at this factory, please be safe." So let's start counting (I suggest in weeks) the time between a major disruption to the team. For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).
Let's start at the beginning and count weeks between Forming and ReForming. You know like when you move a person on/off a team. When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.
The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with. And Mr. VP says they desire persistent teams.
I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).
Agile in 3 Minutes a podcast that discusses a journey toward agility (each episode in exactly 3 minutes). I'm pondering... why does the magic number 3 come up in the Agile community so often? Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)
A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.
One of the (very sharp) fellows in the audience asked this question:
As you grow, don’t you need component teams?
I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.
If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.
Some organizations attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.
When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.
You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)
When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)
What can you do?
- Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise, flow work through the experts (not the teams).
- Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
- Visualize the flow of work. Consider a kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
- Rearrange backlog ranking, so you have fewer teams waiting for the scarcity.
Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.
Visualizing the work helps.
Flowing the work through the constrained people will show you your real capacity.
Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.
If you can’t hire, you have several choices:
- Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
- Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
- Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, more MVPs before you invest a ton of time in work you might not need.
I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.
When I go in to do large scale transformations I’m invariably asked the question, “should the PMO go away?’ The reasoning is that going agile should get rid of all of the oversight, the Gantt Charts, the weekly status meetings, release scheduling. The list goes on.
Before I address the question I want to give you some background as to what we typically see when we hit the ground from a coaching standpoint. The company is in an ad hoc state. They may be delivering but it isn’t always on time. Scope creep is inevitable in this environment as they schedule 3,6, and maybe even 12 month releases. As much as the teams try to be agile there are a number of processes in place to make sure the product actually gets out the door. There’s some release planning up front, expectations are set. Development may occur in sprints but integration testing and acceptance testing lag behind. Sometimes it is so complicated to do integration testing it has to happen in a big time box towards the end. The business becomes disengaged while development is off sprinting. This process isn’t agile and if you did lay it out in a Gantt chart it would present very much like waterfall.
Now think about all the stage gates you have in your organization. Release planning sign off. Weekly change control. Release scheduling. Release sign off. Deployment planning. Deployment change control. Some organizations I’ve seen have 20 people on the phone during an overnight deployment. So why is this? The answer is simple. Over time the organization has created an environment of mistrust. Promises have been broken. Buggy software has been delivered to customers. Fingers pointed; “Requirements were bad”, “Development is slow”, “Too many last minute changes.” A number of reasons have caused the need for the stage gates. Once a stage gate exists it’s difficult to remove.
To get the organization back on track we need to refocus on the 3 things that make up an agile process; backlog, team and working tested software. In essence, clarity, accountability and measurable progress. In order to do this, we need governance, structure and metrics. These things will get us to a predictable state. Once we get predictable we can begin to rebuild the trust in the organization.
To get an organization back on track we need to focus on the 3 things that make up an agile process; backlog, team and working tested software.
The governance model must slice through the organization from the top to the bottom. In many organizations this will be in the form of at least 3 layers; Portfolio, Program, and Team. The Portfolio layer will deal with the creation, definition and prioritization of themes and epics. The Program layer will create define, and prioritize features. The Team level is responsible for the implementation of the user stories derived from the features. This governance model will further define the process flows to go from inception to deployment.
What I have briefly described here is an initial step towards a logically planned out transformation strategy. As you can see, in this first step we clearly define a structure and a governance model that leads to a predictable process. We can’t just teach agile practices and hope everybody sees the light. There are a number of manual orchestration activities in the organization to keep everything moving forward. As the organization moves further along the scale towards a more decoupled system of delivery then the manual orchestration will diminish. I refer to this manual orchestration and stabilization processes as scaffolding. As manual orchestration diminishes the scaffolding can begin to come down. It is important in your transformation to identify the scaffolding and plan as part of your future transformation efforts to remove it.
Once we get predictable we can begin to rebuild the trust in the organization.
So, “Should the PMO go away?” Not in this scenario. Some part of the organization needs to facilitate the manual orchestration at this stage of the transformation. If your organization already has a PMO then these are the type of people you need to facilitate.
Can the PMO go away one day? The only responsible answer I can give is, “When your organization is ready.”
One last caveat. I’ve seen some organizations that are split, some parts need the PMO due to organizational and technical debt, and other parts have been built to be decoupled and on a continuous delivery cycle eliminating the need for manual orchestration.
Custom Request Types
Custom Request types increase the number of scenarios that the Service Desk can be used for. For example, you could add "Project Request" if you're doing Portfolio Management, "IT request" for infrastructure guys, and much more. Alternatively, you can simplify Idea Management by removing all Request types except for "Idea".
- Requiring a comment for state transfers is now supported in Boards and Lists. If checked, users are requested to input a comment before moving an entity to the selected state.
- Fixed: Non-admin user could change their team role without 'add/edit team' permissions
- POP plugin won't create a requester if a Targetprocess User with the same email already exists
- Fixed email notification duplicates in the case of reply-to comments where the same person is mentioned and addressed
- REST api/v1: InboundAssignables, OutboundAssignables endpoints with CustomField collection included returned empty value
Assumptions are interesting things – we all make them all the time, and we rarely acknowledge that we’re doing it. When it comes to developing a product strategy – or even making decisions about how best to create a product, one of these assumptions is likely to be what causes us to fail. We can, however, reduce the chance of that happening.Being Wrong
What does it feel like to be wrong? Watch about 25 seconds of this TED talk from Kathryn Schultz, starting at 4:09
Go back later and watch her entire talk – it is really worth it. But stay with me for now. All you need for this article is the 25 seconds, and the realization that you don’t know you are wrong until you know you’re wrong.Hidden in Plain Sight
Assumptions are like being wrong. But with an added degree of difficulty. Not only do you not know you’re wrong – but you didn’t realize you were incorrectly asserting something, and then betting on it to be right.
Every strategy, every product idea, every design approach, and every planned implementation is built upon a pile of assumptions. Those assumptions are there, if you just look at them. But you have to look for them in order to see them. They are hidden in plain sight.
The only question is if they are going to cause you any trouble. You might not be wrong, in the assumptions that really matter.
Wouldn’t it be nice to know when you are wrong? Before it’s too late? Before it’s really expensive? Before your window of opportunity closes?Identifying Risky Assumptions
Laura Klein spoke at the Lean Startup Conference about identifying risky assumptions and her talk was published in Dec 2014. Laura is also rapidly becoming on of my favorite gurus. I just wish I’d become aware of her work sooner.
Laura identifies that every product has at least three different classes of assumptions.
- Problem Assumptions – we assume there is a market-viable problem worth solving.
- Solution Assumptions – we assume our approach to addressing the problem is the right one.
- Implementation Assumptions – we assume we can execute to make our solution a reality, such that it solves the problem and we succeed.
Hold onto this thought – I need to segue and dust off a tool I found five years ago, and some work I’ve done with clients over the last couple of years. We’ll look at how to incorporate some of those ideas with the ones Laura shared. And eventually, the whack-a-mole reference will make sense.Hypotheses and Assumptions
With a client last year, I ran a workshop to elicit assumptions on our project. We were working to develop what Harry Max calls the theory of our product. Basically, we were working to develop the vision, the value propositions (for a two-sided market problem), the business model that would enable a credible market entry strategy given the company’s current situation, and a viable solution approach. Essentially, product strategy and product ideation.
My assertion in that workshop was that assumptions and hypotheses, practically speaking, are risks.
Product strategy and product design are a formulated plan of action, built upon a set of beliefs – assumptions and hypotheses. The risk is that those beliefs are wrong. And we don’t realize it. Materially, the only difference between an assumption and a hypothesis is that the assumption is something no one has said out loud. It represents an implicit risk. Once you acknowledge the assumption, you can then treat it explicitly – and explicitly decide to do something about it or not. In the workshop I prompted the participants (senior executives, domain experts, product stakeholders and team members) to identify their assumptions and hypotheses. I started by presenting several hypotheses and assumptions that had been part of conversations prior to the workshop. This helped elicit ideas from the group, but it wasn’t really enough. What did get things moving was some prompts from Harry, such as the suggestion to complete the sentence “It will never work because..” or “The only way it will work is if…” We were able to elicit and then organize (affinity mapping) the inputs into a collection of testable hypotheses. What To Do With a Pile of Hypotheses? Now, armed with a list of hypotheses, and limited time and resources to go test them all, we were faced with the challenge of determining which risk to address first. Remember – hypotheses and assumptions are risks. Risks of being wrong (and not knowing it). Risks of product failure. I’ve historically used potential impact and likelihood of happening to manage risks. I first learned to assign a score from 1 to 3 for likelihood of the risky thing happening, and a score from 1 to 3 of how bad would it be if it did happen. Multiply the two together, and you get a score from 1 to 9 (1,2,3,4,6,9). I learned this from PMO-trained people in the late 1990’s. Maybe their thinking has evolved since then. There are two problems with creating a score like this.
- Likelihood of occurrence and potential impact are treated as equally important factors. An unlikely but major impact risk would be “as important” as a likely risk with minimal impact. Each particular approach to risk management will value these differently.
- Combining the two pieces of information into a single piece of information is discarding useful information. If I tell you one risk is a “3” and the other is a “4”, you cannot know which risk is more important to you. The “4” is something that reasonably could happen, and would be “bad.” Would that be more important than understanding the risk of an unlikely, but company-ending risk? Would it be more important than a very likely annoyance – one which may cause death by a thousand cuts for your company is large volumes of support costs absorb profits.
The reason you test a hypothesis is to reduce a risk. I think Laura used the phrase “to de-risk” the risk. To de-risk the risk, the first think you need to do is remove the uncertainty you have about how bad things could really possibly be. You need to run an experiment. In the example above, you would prefer to test hypothesis 7 first if you can – it is the uppiest and rightiest. You would not be far wrong if you tested 4 or 8 first (assuming it is easier, faster, or cheaper to test one of those). If you were to first test anything other than 4,8,7, you really should have a good reason. Once you run your experiment and determine that the risk is not a risk, go back and address the next-most-important risk. This is a game of whack-a-mole. You will never run out of testable risks. You will only eventually reach a point where the economic value of delaying your product to keep testing risks no longer makes sense. Note that an experiment could result in multiple outcomes and next steps. Here are a couple
- This risk is not as impactful as we thought, we won’t address it with product changes, we will absorb those costs into our profitability model and revisit pricing to assure the business case still holds up.
- This risk is every bit as likely as we were afraid. Let’s determine a problem restatement (or solution design approach) where this risk no longer has the impact or likelihood it did before. As an example – a risk of users not adopting a product with an inelegant experience may justify rethinking the approach and investing to improve the user experience.
Trying to tackle all the ways you can respond to risks (and de-risked risks) would make this overly long article ridiculously long.Validation Board
n 2012 I came across the hypothesis board from leanstartupmachine.com. At the time, it was free for use by consultants :) I don’t believe it has gained widespread adoption. At least people look at me funny when I mention it. Maybe now, more people will know about it. I personally never used it because something felt not-quite-helpful enough for me, for the problems I was helping my clients to solve. I could never figure out why, however. The board has many of the important components. In hindsight, this is an indicator that the validation board is likely solving a problem I don’t have (as opposed to being a bad solution to a problem I do have). The validation board is structured more for early-startup customer-discovery work – with three categories of hypotheses to track – customer, problem, and solution
- How big is the potential market?
- How valuable is the problem we would solve?
- Are we able to solve the problem for these people?
I don't usually have patience to watch a 45 minute video, but I had to watch this one to the end!