Release Planning

Maximize your return on investment by:

working on one project at a time;
releasing early and often;
adapting your plans;
keeping your options open; and
planning at the last responsible moment.
Use timeboxing to control your schedule. Set the release date, then manage scope to meet that date. This forces important prioritization decisions and makes the endpoint clear.

Prioritized Minimum Marketable Features (MMFs) and stories form the body of your plan. Demonstrate your progress as you develop and use that feedback to revise your plan.

To minimize rework, develop the details of your requirements at the last responsible moment.

Resource: The Art of Agile Development: Release Planning

Posted in Project Management, Agile, SDLC, Continuous Improvement, Continuous Delivery, Incremental, Iterative, Planning | Leave a comment

What Is a Customer Need?

Much of the confusion concerning the proper role of
customer needs in the innovation process stems from an
unclear understanding of what a customer need is. Solutions,
features and product requirements are not customer needs,
and yet they have all been treated as such at one time or
another.

There are two forms in which customer needs may be
stated that properly reflect the customer’s definition of value.
First, there are job statements. A job is a fundamental goal
that customers are trying to accomplish or a problem they
are trying to resolve in a given situation (e.g., prevent cavities,
learn to play guitar or hang a picture). Second, there are
outcome statements. A desired outcome is a metric that is
used by customers to measure success when getting a job
done. Customers hire particular solutions to get a job done,
and they choose among competing solutions in order to ensure
that their priority outcomes in getting a job done are satisfied.
(For more detailed discussion of jobs and outcomes and their
role in the innovation process, see Anthony W. Ulwick, “Turn
Customer Input into Innovation,” Harvard Business Review,
January 2002; Lance A. Bettencourt and Anthony W. Ulwick,
“The Customer-Centered Innovation Map,” Harvard Business
Review, May 2008; and Anthony W. Ulwick and Lance A. Bettencourt,
“Giving Customers a Fair Hearing,” Sloan Management
Review, Spring 2008.)

Although jobs and outcomes share several characteristics
that enable them to be properly valued in the innovation
process, two in particular are worth noting. First, a good job or
outcome statement does not include any references to how the
customer need might be satisfied. This seems simple enough,
but it is challenging in practice—as it means stripping away
reference to the way things are currently done (as those merely
represent the current solution). Second, a good job or outcome
statement uses unambiguous language that will lead to a common
understanding by anyone who reads it. Thus, imprecise
words such as “reliable,” “durable” and “easy to use” must be
avoided. Such imprecision introduces variation in interpretation
that hampers innovation.

When customer needs are defined as jobs and outcomes
with these two characteristics in mind, they can become the
basis for capturing need statements that customers are able to
articulate, that are relevant across geographies and time and
that are useful for decision making by diverse stakeholders
within the organization.

Resource: What Is a Customer Need?

Posted in Innovation, Jobs-to-be-done, Problem Solving, Productivity, Project Management, Requirements, SDLC | Leave a comment

5 Myths of Customer Needs

Customer needs can and should guide innovation. So where does
the problem lie?
The answer is both simple and profound: It is the failure to understand exactly what a customer need is.

Five myths that have a particularly pernicious effect.
Like all myths, they have a basis in reality, but their unquestioned acceptance as truth is leading many companies astray—leading to wasted resources, disjointed innovation executions, missed growth opportunities, and product concepts that miss the mark with customers.

Myth No. 1: Customers Can’t Articulate Their Needs

“Ignore Your Customer!” This provocative title for a 1995 article published in Fortune magazine has become the mantra of a generation of product managers who operate under the mistaken belief that customers cannot articulate their needs. Customers will mislead you if you ask them about their needs—or so the thinking goes.

“If you had asked customers, they couldn’t have told you they needed the iPhone. Therefore, it must be true that customers cannot articulate what they need.”
But there’s the rub: However brilliant it may be, the iPhone
is not a customer need. The iPhone—like the microwave and
Walkman before it—is a solution to a customer need. When
companies get solutions and customer needs confused, it confuses
the role of the customer and the company in the innovation
process. Customers articulate their needs; it is up to the
company to create a solution.
It is not the role of the customer to provide technology
ideas to the company, or even to evaluate the potential for a
new technology to satisfy their unmet needs. How would they
know? They are not technology experts.
When customer needs are defined in a manner that distinguishes them
from solutions, not only can customers articulate their needs,
but those needs become the valued foundation the innovation
process requires.

Myth No. 2: Customers Don’t Know What They Need

It is this myth that leads many product managers to conclude—incorrectly—that innovation is the process of “creating a customer need.”
“If the solution we’re going to propose does not yet exist,” the
managers say, “then how can customers possibly know that
they need it?” But again, the managers are confusing solutions
with needs. A product or service may do something that has
never been done before, but the needs it addresses will have
been long-standing.
If a company can learn how customers evaluate how well they’re
able to get jobs done using today’s solutions, then it can learn
precisely where customers have needs that are currently unmet
by any solutions.

Myth No. 3: Different Customers, Different Needs

“If you’ve seen one hospital, you’ve seen one hospital!” This humorous comment captured the recognition that every hospital has its own way of doing things. But it would be dangerous to conclude that because each hospital has its own way of doing things, each hospital is trying to satisfy a different set of needs.
Why this myth, because they are looking at the solutions
customers are currently using—rather than at the job the
customer is trying to get done.
There may be any number of possible solutions to the problems a job presents, but that doesn’t mean that there is more than one job.
If the innovation team focuses on the solution that customers are using, it will limit how they perceive the customers’ actual needs.

Myth No. 4: Customer Needs Change Quickly Over Time

Solutions come and go. Many believe that customer needs change quickly over time. Unfortunately, this mistaken belief leads many to downplay the role of customer needs in guiding strategy and long-term product planning.
If solutions and customer needs are not properly distinguished, companies can mistakenly conclude that needs change rapidly over time.
The reality is that customer needs are quite stable when
properly defined around the job the customer is trying to get
done.
If customer needs do not reference particular
solutions—such as financial planning software—they have a relevance that spans years and decades. It is true that the priorities people attach to these needs will vary over time, as society changes and new solutions are introduced. However, the underlying needs remain
the same.

Myth No. 5: Customer Needs Differ by Org. Purpose

The primary reason for these internal coordination problems
is the absence of a precise and shared language for speaking
about customer needs.
All must first agree on what a good customer need statement is—one that will inform the varied purposes of all.

Resource: Debunking Myths about Customer Needs

Posted in Creativity, Innovation, Jobs-to-be-done, Productivity, Requirements, SDLC | Leave a comment

Jobs-To-Be-Done Theory

All you should find out is what the customers’ ultimate output goal is: WHAT they want the product or service to do for them (Needs), not HOW it should do it (Solution).

People do not want a software, they want their job to be done.

While software come and go, the underlying job-to-be-done does not go away.

Instead of trying to improve your existing software, the innovation process is dramatically improved by instead trying to find better ways to get the job done.

Stop studying the software and instead study the job that people are trying to get done.

Analyze the job, not the customer or the software.

By focusing on the job-to-be-done, it becomes possible, for the first time, to know all the customer’s needs and determine which are unmet. It turns out that when customers are executing a job, they have a set of metrics in mind that define the successful execution of that job. These metrics (or desired outcomes) can be captured as actionable customer need statements that replace the customer inputs companies ordinarily capture and use to create new products.

Analyzing the job to discover where customers struggle to get the job done, rather than analyzing the software they use for that purpose.

Software evolve over time to help people get more jobs done. Jobs-to-be-done theory tells us that the more jobs a software can help a customer get done, the more valuable that product is as a software platform in that space.

Always be focused on creating the solutions that will get the job done best.

Focus on helping customers get a job done better.

What software will win in the future? The software that help customers get the job done better. Knowing where customers struggle today to execute the job-to-be-done indicates what a software has to do in the future to win.

We all know that people “hire” products to get jobs done. Office workers hire word-processing software to create documents.

For innovative ideas, first break down the job that customers want done into discrete steps. Then brainstorm ways to make steps easier, faster, or unnecessary.

Validating Questions
Defining the execution step: what are the most central tasks that must be accomplished in getting the job done?
Defining pre-execution steps: what must happen before the core execution step to ensure the job is successfully carried out?
Defining post-execution steps: what must happen after the core execution step to ensure the job is successfully carried out?

Opportunities at the job level
Can the job be executed in a more efficient or effective sequence?
Do some customers struggle more with executing the job than others (for instance, novices versus experts, older versus younger?)
What struggles or inconveniences do customers experience because they must rely on multiple solutions to get the job done?
Is it possible to eliminate the need for particular inputs or outputs from the job?
Is it necessary that the customers execute all steps for which they are currently responsible? Can the burden be automated or shifted to someone else?
How many trends affect the way the job is executed in the future?
In what contexts do customers most struggle with executing the job today? Where else or when else might customers want to execute the job?

Opportunities at the step level
What causes variability (or unreliability) in executing this step? What causes execution to go off track?
Do some customers struggle more than others with this step?
What does this step’s ideal output look like (and in what ways is the current output less than ideal?)
Is this step more difficult to execute successfully in some contexts than others?
What are the biggest drawbacks of current solutions used to execute this step?
What makes executing this step time-consuming or inconvenient?

Defining the job-to-be-done correctly is a prerequisite to predictable success in innovation, because the job becomes the focal point around which the entire innovation process is executed.

Focus on customers that are struggling to get the job done.

The job must be defined as a process; an activity that consists of a series of steps that customers take to complete a task or achieve a goal or objective. This means that the job-to-be-done is always a functional job; not an emotional job.

Rules that define the job correctly:

1. Think about the job from the customer’s perspective.
So don’t ask “what job are people want software for”, rather ask, “what job is the customer trying to get done”. Because customers often cobble together many solutions to try and get the entire job done.

2. Think big; to encompass the entire job, not just a piece of it. A narrow focus will hurt you because customers are looking for products and services that help them get the entire job done better.

To create more value for customers. This means better satisfying the customers’ unmet needs.

Examining customer needs through a jobs-to-be-done lens, a customer need must relate to helping customers get a job done better.

5 Myths of Customer Needs
1. Customers have latent needs; needs they don’t even know they have.
2. Customers struggle to articulate their needs.
3. Customers’ needs change quickly over time.
4. Customers won’t know what they want until they see it.
5. It is impossible to ever know all the customers’ needs.

A customer need is not a solution, product feature, or idea. Nor is it a statement that describes how to make products easier to purchase, set up, install, or interface with. Customers don’t buy products and services to set them up or to interface with them. They buy products and services to get a job done.

Customers don’t know what solutions they want, but a solution is not a need. Customer needs are the metrics customers use to measure how well they’re executing the job-to-be-done.

When we define needs this way, we can readily identify all of them because customers know perfectly well what success means to them when getting a job done.

This perspective changes everything. When needs are thought of in this way, there is no such thing as a latent need or a need a customer can’t articulate. Furthermore, these needs are stable over time: they often don’t change for decades because the job-to-be-done remains the same.

Having a full set of customer needs, defined around the job-to-be-done, impacts all aspects of innovation, including the way opportunities are defined, and the way ideas are constructed, tested and positioned.

Customer needs analysis:

Four-step approach.

1- conduct personal interviews in order to dissect the job the customer is trying to get done into process steps. We call this process “job mapping.” The job map is created so the company and the interviewer have a clear understanding of what job the customer is trying to get done.

2- conduct one or more ethnographic or observational interviews with customers to gain insight into the context in which the job is getting done. This helps the interviewer be more effective at capturing and refining desired outcome statements in subsequent interviews. These interviews also may be used to better flesh out the job map and begin the outcome gathering effort.

3- conduct personal, group or observational interviews to elicit from customers what metrics they use to measure success in executing each step of the job. This is where the bulk of the desired outcome statements are captured and the heart of the customer needs analysis discipline.

4- conduct one-on-one interviews or literature searches if needed to fill in any missing details that remain after completing the first three steps.

Resource: Jobs-To-Be-Done

Posted in Creativity, Innovation, Interviews, Jobs-to-be-done, Productivity, Requirements | Leave a comment

Mob Programming

Pair programming keeps two eyes on the code at all times and increases the ability to communicate to each other about the code. Mob programming extends that out just a little bit to a whole team. So essentially everybody working on the same code, the same problem, at the same time, in the same space and on the same computer. Being on the same computer is what sort of makes it a little bit different than the way a lot of teams work.

Any concept that is going to go into code is discussed, as it is going into the code base. So anything that we want to do, has to be verbalized and so we use this role we call driver navigator. The driver is sort of a smart input device. He or she is working at the keyboard taking information from the navigators, who are discussing how we want the code to look, what do we want the objects to do. And that means we have to express it well verbally. We have to understand it well and everybody is watching it at the same time. So if the understanding isn’t there, that’s clear to us, it’s transparent. So we pretty much go from a good idea to vetting it, to getting into the code base and reviewing the code all at the same time.

Every 15 minutes we change. So we keep this roundory we call it or rotation going throughout the day, where everybody is at the keyboard for no more than 15 minutes. And the keyboard is not the seat of honor. It’s just, you are the current input device and we switch it up, so that you can get back to being a navigator as quick as possible.

The value here isn’t, that I have got an idea and therefore I key it in, it’s I have got an idea an therefore I need to be able to express it. And it’s that forcing ourselves to express it in human terms, that really clears the air. We all get to understand it. There is a lot of benefits to this.

Everybody on the team is a coder. But somebody coming on the team might not be a very accomplished coder, but they’ll become one pretty quickly. Because there is this concept of continuous learning that happens and it accelerates your learning. So if you kind of can code a little bit, you’ll become better very quickly, when you work in this situation, because you are constantly exposed to a good way to do your work. All the shortcuts become apparent, all the IDEs we work with, the coding conventions, how code itself works, it’s all exposed and shown continuously. So when you are working alone, you often go: there must be a shortcut for this. You search around on the internet, you don’t know the right keywords to find it. Here you just ask “Hey, is there a shortcut for this”? Or you see someone use one, you go “What did you just do there”? And, we learn quickly. So we’ve got a couple of guys on the team who really started out in the QA world and a couple of us, who started out more coding, but we all have to code and we all have to do QA on this team. So those with the QA skills have become much better coders and those with the coding skills have become much better QA people.

We all get in about the same time, eight o’clock. We spend an hour studying every morning, then we work the rest of the day till five o’clock and then we go home. During the day, we are interacting all day long and as often as not we take a hike at lunch together. We could pass a sandwich shop on the way and pick up something, but our hikes aren’t just a little walk up and down the street, we are actually getting into some hilly areas, dirt trails, and we all seem to enjoy it.

The basic idea though is that, if we’re turning out code and we are delivering projects, everybody is happy. It’s way more important to see that code in use, than anything else. So, it’s kind of a problem, when we see two or three people huddled around doing the same thing and we think, maybe they are redundant, we don’t need them all doing that same thing, but the results are what counts. And I think my manager or my boss, once he saw how serious we were, he just supported it 100%. It didn’t take him long to see that. A matter of fact, can I tell a little bit of the story of how we started doing it?

Resource: Woody Zuill on Mob Programming and No Estimates

Posted in Agile | Leave a comment

Planning

Rather than try to plan for every eventuality, embrace the possibilities that change brings you. This approach may sound like it’s out of control. It would be, except for eight practices that allow you to control the chaos of endless possibility.

1- Vision : reveals where the project is going and why it’s going there.

2- Release Planning : provides a roadmap for reaching your destination.

3- The Planning Game : combines the expertise of the whole team to create achievable plans.

4- Risk Management : allows the team to make and meet long-term commitments.

5- Iteration Planning : provides structure to the team’s daily activities.

6- Slack : allows the team to reliably deliver results every iteration.

7- Stories : form the line items in the team’s plan.

8- Estimating : enables the team to predict how long their work will take.

Resource: The Art of Agile Development: Chapter 8: Planning

Posted in Agile, Planning, XP | Leave a comment

Incremental versus Iterative Development

Incremental fundamentally means add onto. Incremental development helps you progress.

Iterative fundamentally means re-do. Iterative development helps you improve your product.

Incremental means new features because you add-on.

Iterative means quality because you re-work.

Increment new requirements for progress.

Iterate old requirements for quality.

Incremental involves breaking a large system into smaller systems.

Iterative embraces feedback and learning because it is very difficult to know upfront exactly what the final product should look like and builds in as many learning opportunities as possible.

Increments lets you fix process: build/deliver/learn .. build/deliver/learn

Iterations lets you fix ignorance: build/examine/learn/rebiuld/ship ..

I (Alistair) visited a 200-person project team, where, as one manager put it when he finally saw the difference, “We’re iterating when we should be incrementing !!” You can imagine the feeling of helplessness on that project as the developers saw the same requirements coming at them over and over again in slightly different forms, and no plan for making progress through the requirements set. At that time, the lesson was: be sure to increment; yes you will iterate anyway.

First you increment to progress with the basics of the first system’s module, then iterate for quality, then release 1. Secondly, you increment to progress with the basics of the first system’s module, then iterate for quality, then release 2.

Resource: Incremental versus iterative development

Posted in Agile, Incremental, Iterative | Leave a comment

Safety Development Environment

Learning is the biggest single base part of software development, whether we’re using Agile or Waterfall or anything else, we learn and the faster we learn the faster we produce software.

Agile, when it works really well, those teams that get it, they get those 200, 400, 500% improvement in their productivity, those teams have figured out how to learn and they learn from failure. Agile, whether it’s Scrum, Kanban, XP, any of them, it’s all about iterative loops and experimentation and doing something and failing and learning from it and doing something and failing and learning from it.

In the Agile world the idea is we keep those experiments small so we have small failures. And we look at them, we confront those failed experiments and we say “Oh, OK. I wanted this over here, I didn’t get it so let me inspect and adapt and try to solve it again from that new information that I’ve learnt from the failure”, that’s when things go right and when teams can learn from failure, nothing can stop them.

If we’re afraid, if we’re unsafe, then we can’t learn. We can do experiments but we won’t get any of the benefit because what happens is teams end up going through the motion. Some examples: there are teams that when they do Scrum the say “alright, we are going to do these five things this iteration” and they get three of them done and they say “alright, good job team, we did our best” or if they are doing two week iteration they say “let’s do another third week so we don’t actually call it a failure” or there are teams that do daily work, daily cycles and say “alright, we are going to up the level of quality” yet by the end of the iteration, when the deadline comes, they don’t, they cut corners and they call it a success. Teams and individuals are very uncomfortable with failure, they feel unsafe to fail, and if they feel unsafe to fail, they game the system and they don’t get any of the benefit.

Safety is emotional. And the thing is we dismiss it because it’s emotional, yet it undermines us. If we don’t focus on creating safety, it undermines our ability to do great work.

If you can get yourself in the mindset of ownership, “I own what happens to me”, that’s a safe place to be, that means if something happens around me I don’t feel helpless, I can choose to respond to that.

Being aware of our intentions and each other’s feelings creates a safe place. I don’t have to guess your emotion, I know your emotional state and I know why.

Without verbally announcing what you are doing and feeling, it leaves us to guess and when we start guessing that has a good chance to create lack of safety. So announcing, in general, announcing your intentions and feelings is a great way to create interpersonal safety.

Resource: Amr Elssamadisy – Safety

Posted in Agile, Learning, Productivity, Safety | Leave a comment

Seven Traits of Effective Programmers

1. Learn new tech and everything around it

Bad programmers learn new technical skills just in time. Good programmers learn the skill a year before. Great programmers learn new technical skills and all skills, technology, design, paradigm around it a year before.

2. Produce a working application, not technical perfection

There will be times you will write code that you would not show someone else as an example of how things should be done. It’s not bad code if there’s only way to write it — just make sure you have exhausted your other possibilities.

3. Know how to research for answers

Know how to find answers or discover root causes.
Many problems are situational, and if you depend on search engines and forums, you can waste a lot of time going down a rabbit hole and possibly never getting a solution. Learn to perform root cause analysis, learn enough about the underlying system to look for other clues and solutions, and learn to take a long distance view of an issue before deep diving into it.

4. Have passion

You must be passionate about more than programming — you must also be excited about your job, the technology you are using, your employer, your project, and so on.

5. Leave their egos at the door

Many developers have huge egos. Being smarter, more knowledgeable, or more experienced than someone else does not mean you are better than that person. You need to treat people with respect, listen and truly consider another person’s ideas, ask for help when needed, and don’t look down on anyone else. You should also care more about whether the team succeeds than if you get credit for your work.

6. Have entrepreneurial spirits

The best developers are not drones. They have a true sense of entrepreneurship and feel ownership in the product. To them, the product’s success means more than just the continuation of their paychecks. Because they have emotional skin in the game, they work for the good of the project, and go the distance.

7. Measure twice, cut once… but do not measure more than three times

The best of the best developers do not let themselves get sucked into the “analysis paralysis” trap. They know to be more cautious about some things, which is why I say it is fine to “measure three times.” Anything past three times, and you are just wasting your time

It’s important to stop planning after a certain point and start coding, and then see where you need to adjust your plans. Incidentally, this is one reason why I’ve become a big fan of Agile. The best developers I know are willing to sacrifice a plan if the plan is no longer suitable or is discovered to be flawed.

Resource: Seven traits of effective programmers

Posted in Agile, Coders, Programmers, Skills, SoftwareCraftsmanship, Super | 2 Comments

BDD and Feature Injection

Most of the time when business domain experts come and ask for something they very rarely tell you and express it in terms of the value they want, they often come up with a half-baked solution. What we actually want though is something which is a set of examples that can drive the Agile development process but driven by value. Feature injection has three very simple steps, first step is find the value, second step is inject the features, as we call it, and the third step is break the model. What that means is a business person comes to you and says “I want a tea bag”, well, no one has ever wanted a tea bag, what they really want is a cup of tea, so when they ask for a tea bag, we say “why do you want a tea bag?”, “well, I want a cup of tea”, once they’ve asked for a cup of tea we can say “why do you want a cup of tea?”, and they go “well, because I’m thirsty”. We can now present them with a number of different options in terms of how to make them un-thirsty, how to quench their thirst and the value is in the quenching of the thirst. So we practically decide on the value is the quenching the thirst, we want to have a cup of tea which is the output of our system, once that we’ve done that, we’ve done the first step, we’ve identified the value.

The next step is to inject the features. This really is a case of rather than saying “let’s build the tea bag” and then when you deliver the tea bag the user says “well, now I need some hot water” and when you’ve delivered the hot water, they go “well, where is the cup to put it in?” What we do is say “right, we want a cup of tea, in order to get a cup of tea, what do we need?”, that’s a much easier question than simply just delivering the tea cup and going through that iterative steps. You go “right, I want a cup of tea, to make a cup of tea I need to have these features in my system: I need tea bags or perhaps tea leaves, I need hot water, I need a cup and I need milk”. That is injecting the features into the system; it’s the Kanban cards flowing backwards across the factory in order to pull the values out that we need. That is the second step which is you start with the output and you work back to the input. If you ever do analysis and you start with the inputs, it’s a very painful process and you end up in analysis paralysis. If you start with the outputs and move towards the inputs, it’s a very simple process and you know at each stage what is needed.

The third step is you ask for a cup of tea, well, what if we ask for other things, what about a cup of coffee, is a cup of coffee similar to a cup of tea and it is, we don’t need anything new in the process; how about a hot chocolate, that’s the same; but then we get to things like a can of coke, is a can of coke the same as a cup of tea and what we’ve done is we’ve broken our model because in order to deliver a can of coke it needs to be cold, so we need a fridge or a chiller of some kind. And so that is the third step of feature injection, which is break the model, find different examples that actually break your processing model and as a result you can fix it and improve it.

Resource: Chris Matts on BDD, Feature Injection and Commitment

Posted in Agile, BDD, Feature Injection | Leave a comment