Being Agile When The Business Isn’t – Requirements

If you’re moving toward being Agile and the business still thinks Command & Control and Waterfall, what can you do? What often happens is the customer and the value of the project’s outcome are lost to the plan and the plan’s execution. I’ve tried to capture below a way to begin the movement toward customers and delivered customer value while still maintaining a Waterfall model.

Customer & Value focused

In an Agile environment, the primary focus is delivering value to the customer. The first two Agile principles make this very clear.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

It would be hard to interpret these two principles as anything other than the customer is king.

In the Waterfall model, the project is usually considered a success once the project plan is complete; if the customer’s happy, all the better. In the Agile model, the project is a success when the customer’s problem is actually solved. However, whether the company is Agile or Waterfall, the basic steps for a project don’t differ much at the high level. What the business does in many cases is first name a business problem or goal, such as sell more units of product. The next step is finding out why customers and potential customer are not buying your product. The third step is making changes to the product (new feature or new product lines) to try to solve the customer problem. The fourth step is to put this new feature or product in front of customers and see if actually solves the customer problem, which if solved, also solves the business goal of selling more product.

The difference between an Agile and Waterfall is how we achieve these basic steps and what project success means. In classic Waterfall, customer involvement occurs during requirements gathering phase and again after the project is over, when they give feedback. Let’s take a look at the requirements gathering step and see how we can inject some Agile practices into a Waterfall environment.

Requirements gathering

Gathering requirements is more than just the basic written requirement, its understanding the customer’s pain in doing whatever the business needs them to do. Whether its buying the product or clicking on links to secure advertiser revenue, understanding why a customer does or doesn’t do this is critical information. The written requirement just doesn’t capture this nuance, you need to see and hear it from the customer’s perspective to fully understand. In Waterfall, this level of understanding isn’t always achieved and if achieved, it’s not always shared with the development teams.

In the Waterfall environment the business directs the product manager to do something to meet the business goal. The product manager and possibly a business analyst review customer comments, feedback, outstanding bugs, and may even talk to some customers about their experiences with the product. The product manager also provides their own insights and intuition. From this knowledge, comes all the requirements thought necessary to meet the business goal. And from these requirements, comes the project plan. The project plan defines all the steps necessary to implement all the requirements which, in turn, are necessary to achieve the business goal, so say the product and project managers. The plan driven project is ready to begin.

In Agile, it’s assumed that the business doesn’t have the complete picture at the beginning. The one or two-week iterations of Scrum are a tool to do small amounts of work and then fact-check with the customer at a review. The review helps the team decide if they’re on the right track. Requirements will evolve and be discovered as the project progresses.

So, how can a Waterfall environment embrace Agile principles to improve requirements? If the business isn’t embracing Agile as much as is properly Agile, the Agile Project Manager or Scrummaster, along with the product manager, can arrange customer interviews with the development team and business stakeholders. When I was at a product company, I had done this to great effect by first arranging through the company’s sales people, to find a customer who was willing to spend 30-minutes to discuss their experiences with the product, good and bad. We also asked what improvements the customer would be happiest to see. The interview was held over the phone with about 30 people who quietly listened to the customer answer the questions I asked. At the end we had a very quick Q&A from anyone in room. The result was an insight to the customer’s world that most everyone, other than the product manager and sales people, would normally not see.

If you’re in the digital space, a variation is to use user testing as the vehicle to gain customer insight. I’ve also done this with a large group of passive viewers. The product manager and a development team member conducted user testing in a small room using a shared screen with a potential customer. In another, larger room, the development teams and business stakeholders watched and listened as the customer put the product through its paces. Only one person spoke with the customer, asking questions to keep the customer talking. This had a great impact upon people as they realized what on the web page customers ignored, areas that confused, and areas the customer was intently focused on. Good stuff when you’re looking to build the right product.

Both customer engagement scenarios work whether you’re Agile or Waterfall. Both these firmly embrace the customer and focus on adding customer value. However, you may need to overcome two big obstacles: first is the business doesn’t think the cost of involving the team is worth it and the second, possibly more difficult obstacle, is the product manager (or equivalent) being reluctance to share responsibility of customer contact.

The first issue, the business thinking its wasteful of money to involve the team, is the easier of the two to overcome. Nothing will help success more than being successful. If the project team, even following Waterfall, can get the customer actively engaged with the development team early, it’s more likely that the customer will continue involvement with the project throughout it’s life. If the customer takes the project journey with the team then it’s very likely the outcome of the project will be what the customer wants. If a customer gets what they want once, they’re likely to return again and again. Start with key members of each team that will work the project. Getting several people involve will help bring objectivity and varied opinions. Customer interviews and user testing should not stop with one customer. Customer interviews will involve the product manager every time but a second pair of eyes and ears comes from the development teams. Slowly build to having an Inception Workshop involving the development team, stakeholders, and business managers.

The second obstacle, bruising egos, might be more difficult to spot as no one usually admits this. The clear sign is a reluctance by a product manager to involve development team members at the customer level. The thing that’s needed is trust. The product manager needs to trust the development representative will not “blow the deal” with an inappropriate phrase or comment. What I’ve done with some success is getting the product manager to allow one or more persons into the room while they speak to customers on the phone, possibly arranging a face-to-face. This helps build that trust as the product manager gets used to the idea of someone else at the interview but more importantly, the product manager sees that the development team representative is not speaking or otherwise interfering. A second aspect is the product manager feeling exposed. They may not have all the necessary self-confidence or perhaps they’re still learning techniques. Again this comes back to trust. The product manager and development team member need to have a plan and in developing that plan, have an understanding of what signs to look for if the interview is not going well. By planning together, they both share the outcome equally, good or bad.

Summary

It’s very possible to use Agile practices, especially getting prolonged customer involvement, when your business is running a Waterfall model. Getting and keeping your customers engaged throughout a project is a risk reduction strategy against building the wrong product. Getting more people involved with the customer is also a risk reduction strategy against a single point of failure. Having only one person’s interpretation of customer wants and needs is not a good idea.

The Big Picture Through Agile Inception Planning

When I was a kid, our family would go for drives out of the city to the countryside. These were more often a prison sentence for me in the crowded backseat with my two sisters. The only consolation was sitting next to a window but being the youngest, well, you can imagine I had the middle seat a lot. If there was a specific destination I was not aware of it until we got there. I was not happy sitting in the middle, the seat was hard as a rock and my sisters pointing out to me that they had the windows. It was sometimes miserable. So when the car got to a special place like the lake, I was already determined not to enjoy myself or at least, I took a while to lose the attitude. But I wonder what would have happened if in the beginning, my parents told me we were going to the lake for a picnic?

When the business starts a project, the project too can be either a prison sentence or an exciting adventure. While there’s no guarantee that everyone will be happy, there are steps the Agile Project Manager can take to help bring everyone on board, answer their questions, and give them an opportunity to participate and contribute toward a successful project. Giving the project team a complete picture of the business reasons for the project is good for business. To make the project goals be meaningful and effective in motivating the project team, they must be tied to larger business ambitions.  Team members who don’t understand the role they play in the business’s success are more likely to become disenchanted and look upon the project as a prison sentence. If however, the team members understand the business goals and how the project will help achieve them, they are more likely to be engaged and equipped to make better trade-off decisions when the project doesn’t go as planned.

An inception workshop is an ideal event that can help give everyone the big picture. The workshop gets the project team members thinking and can set the groundwork for them to make good decisions throughout the project.

Setup the Big Picture Workshop

An inception workshop can be thought of as a two part event. The first part is understanding the ‘why’ of the project from a business and customer perspective. The second part of the inception workshop will deal more with the planning aspects. Setting up understanding the Big Picture happens in the first half of the workshop.

There are several questions that everyone on the team will need to be able to answer at the beginning of the project to give them a better, more complete big picture. These questions are:

  • Why are we here?
  • What will we do?
  • What won’t we do?
  • What trade-offs will we have?
  • Who are our customers/users?
  • Who are our stakeholders?

The inception workshop attempts to get the project team to answer these questions without intimidation. The project team’s participation is essential. To maximize that participation requires openness, trust, respect, and courage to speak one’s thoughts out loud and to listen while others speak.

The inception workshop brings the project team into a large room where people can easily move about. They do not need to bring laptops, pens, paper, or books; they only need to be physically there. The facilitators bring tons of sticky notes, sharpies, flip charts, lots of wall space, phones to speak with customers or stakeholders, projectors, and strong time-boxing skills.

Why are we here

When the project team understands why they are working on the project, it can help make teams do the following things better:

  • making informed decisions
  • making trade-offs
  • being innovative

Getting the CEO or other business officers to describe why the business wants the project and what they hope to achieve, it helps focus the project. If for example the intent is to increase the number of people buying the product, it’s useful to know why they’re not buying it now. Depending on your business, the inception workshop facilitators bring in the CEO, head of Marketing, Sales, HR, Product, Development, and Support to discuss their business goals and outcomes the project will bring them.

When the team understands the intent of the project, they can make decisions based on that intent. To increase the number of buyers might require that customer  testimonials be made more prominent on the home page. If the user story comes up to add additional ad space, the team can decide that this story doesn’t immediately contribute to increasing the number of paying customers and prioritize it lower. Without knowing the intent, they probably would not make good decisions on priorities.

What will we do

During the inception planning workshop, the project team prioritizes business goals and objectives. Creating the elevator pitch is a lean way to get everyone sharply focused on the business intent and be very clear on what’s important.

Source: Dave Gray, Sunni Brown, and James Macanufo. “Gamestorming”. O’Reilly Media.

An elevator pitch is a description of the problem you’re solving, who you’ll solve it for, and the one key benefit that distinguishes it from other ideas. The project team collaboratively defines this pitch during the inception planning workshop. The product manager and Scrummaster/Agile Project Manager, get the group to answer these questions:

  • Who is the target customer?
  • What is the customer need?
  • What is the product name?
  • What is its market category?
  • What is its key benefit?
  • Who or what is the competition?
  • What is the product’s unique differentiator?

The full group starts by brainstorming ideas on sticky notes for each of the categories. There’s no discussion at first but everyone shares their ideas freely and largely silently. Use a large wall or whiteboard for the project team to stick their ideas for each category.

Once the ideas are up, break into smaller groups of 4-5 to develop an elevator pitch sentence. This is complete when the group reaches consensus. Each blank in the sentence contains at most one idea.

The last step is to finalize the pitch from the group inputs. Although important, it’s not critical to finalize this now, especially if there’s a large number of groups. The important part is the group as a whole have decided what the pitch consists of. The product owner can create the finalized version off-line if necessary.

What won’t we do?

When thinking about the project, we usually think in terms of the future product and new product features. We usually don’t think about what the project won’t do. Listing what features or capabilities the project will not do sends a crystal clear message to customers and stakeholders alike. What the “not in scope” list does is help define and manage expectations in an open way. The “not in scope” list can be the catalyst of conversations for future projects.

This is best achieved if the group uses a prioritization tool such as the MoSCoW prioritization method (Must have, Should have, Could have, and Won’t have). The group is asked to identify the features and capabilities the project could do and place these into one of the four columns. The elevator pitch would have identified the benefits and potential benefits of the product. The product manager will have a list of high-level feature work from the roadmap for the project. The project team spends 10-15 minutes sorting through the items silently or creating their own ideas of what should or shouldn’t be done, placing them into one of the four columns. What results is an MVP from the “Must have” column. The “Should have” column items can be considered for inclusion in the MVP but probably require more information before a decision can be made. The items in the “Could have” and “Won’t have” columns are considered out of scope for now. All of this may change over the course of the inception workshop but initial focus is placed on the “Must haves”.

What trade-offs will we have?

Trade-offs at the project level can become strong influences on how the project team approaches their work. It places priorities on those things that matter and de-emphasizes those things that matter less.

Get the project team to first decide what the sliders are. The example sliders above are probably the most used but the team may have others. The group then silently spends 5 minutes placing sticky notes on the sliders where they feel the trade-off is. “On” means most important and less negotiable while “Off” means less important but more negotiable. The consensus opinion will drive the results. After all the sliders are annotated, there is a discussion of the meaning of each slider selection for 10-15 minutes.

Who are our customers/users?

Understanding who your customers are means more than just having a customer’s name. It’s about understanding their motivations, desires, and pain points. Creating an Empathy Map is a quick and easy way to build a persona and get “inside your customer’s head.”

The product manager starts by conducting customer interviews live or plays recordings of customer interviews prior to doing this empathy map. Most likely these will be recordings as a live interview might be difficult. However, having live interviews with your sales or support team members might help a lot. They can bring to the project team their own experiences and understanding of customers and users. Once these interviews are complete, the group is ready to build empathy maps.

The person in the empathy map is fictional but based on understanding of the business’s customers. Ask the group to give this person a name and define their role with the product. The group will describe what the customer’s experience in each of the categories. Not everyone in the group will define something for each category but if a category is left blank, have a quick group discussion to try and fill it. It should take about 10-15 minutes for each customer/user profile.

The goal is for the project team to form some degree of empathy for the person, understanding at some level: What does this person want? What forces are motivating this person? What can we do for this person?

 

Who are our stakeholders?

Although the project team has met some stakeholders at the opening, the team will now identify all the stakeholders that have a direct interest in the project and those people needed to make the project successful. This can be by individuals or roles.

The project team members build a list of ‘Who’ and what they do or need to do to help make the project a success.

The group will spend 5-10 minutes defining this list. Have people fill out sticky notes and place these on the wall. Ask a volunteer to do some affinity mapping to group the item by the do’s.

Summary

The steps above can be reordered to suit your specific inception workshop need and your team’s baseline knowledge levels. If for example, the team knows nothing about customers, getting a base understanding of the customers through user journeys or empathy mapping before developing the elevator pitch might be the appropriate thing to do.

The steps above define the first half of the inception workshop. The second half has the team using the information gathered here to add detail for project planning and will include: Story Mapping to define the releases, provide high level estimates, identify areas of concerns and risks in Speedboats and Anchors, and provide the project team’s presentation back to the business leaders of what they can expect (and not expect) to happen during the course of the project.

Getting everyone on the same page and understanding the big picture doesn’t guarantee success but doing this can reduce truck loads of risk.

Some resources that can help you include:

Warning: You’re Losing Money by Not Using the right Agile Metrics

The Agile metrics you use to measure Agile teams matters. A lot.

What makes a great Agile team? While there’s the idea of self-organizing, continuous improvement, and ever increasing technological growth, there’s really not a universal way to tell if a Agile team is ‘great’. For example, the business wants to release capabilities A, B, and C by June 30 and the Agile team doesn’t meet this date because the stories blew out, is this a great Agile team? Or how about the team that’s meets every business delivery date but the product doesn’t attract the number of paying customers hoped for, is this a great Agile team?

In truth, there are as many ways to measure an Agile team’s success as there are Agile teams. So if it’s impossible to have a standard measure then what’s a business to do?

The best answer is to tie the success of the Agile team to the success of the business. If the business’s strategy is to grow the number of customers then measure the number of new customers the Agile teams’ latest product features attract. Even if there are 20 teams working on one product, each team can work their new features to attract more customers. Infrastructure teams make the product faster, more robust, and multi-platformed in the back-end. Although customers can’t directly touch these changes, they can sense or ‘feel’ these improvements. The Unique Value Proposition might be, “our product is 3x faster than our nearest competitor!”

A very common occurrence is the scrum master finds initial measures that other scrum teams use, for example, on this site. Although this sounds OK i.e. “we’ll use velocity”, the measure may not fit the business. I was working in a company where teams often received new ‘business critical’ work from outside the current sprint or project. This was work to help secure new customers or address customer requests immediately. The team used velocity to measure performance even when the team, from a project point of view, was having their sprint plans negated through these requests. This should have rendered velocity moot. What would have better suited the team and the business was a measure of how quickly the Agile team could respond to these ‘business critical’ items.

In most scenarios the business needs to grow to be successful. Andrew Chen writes about scaling user growth as an example. This doesn’t automatically mean the development team needs to double their velocity in the coming year. Building the wrong product twice as fast isn’t the answer. What company’s need to do for growth is experiment unceasingly and this means the product development team needs to ramp up to build, deploy, test, and redeploy quickly i.e Growth Hacking.

How well is the Agile team doing? The best measures are related to the business strategy and goals. There are several categories of measures that teams or business could use including: business, innovation, Agile, customer, or environment. The best way to select what metrics to use is to understand what’s best for your customer and your business.

Your key Agile team performance measures will come from the sample list of Business, Customer, and Innovation measures below. The best measures internal to the Agile team will come from Agile and Environment. If the business strategy or goals change, it’s very likely that your measures for Agile team performance will need to change too.

1. Business – return on investment, growth, and customer base & market

  • Net Promoter Score – measure a customer’s likelihood to refer your product.
  • Referrals – this is a raw count of customers who actually referred your product to someone else.
  • Revenue – the amount of revenue generated by your product after new idea or update is released
  • Acquisition – number of new customers to your product after of new idea or update is released
  • Solving Your Problem Index – Customer’s rating on how the MVP is solving their problem
  • Customer lifetime value – Is this changing due to the introduction of a new feature or product line?
  • Rate of Sales Pipeline Growth – Has the new feature or product line accelerated sales growth?
  • Adoption/Use of New Feature or update– Are the customers and users using the new feature or update?
  • Customer/User Feedback from Each MVP – How well received was the MVP?
  • Market Size and Market Share – Is the new feature or update making the projected impacts?
  • Retention – Has the change brought back ‘lost’ customers?

2. Customer – satisfaction with the product and timeliness of deliveries

  • Count of positive customer testimonials – For each update or new idea, are your customers saying good things.
  • Count of negative customer testimonials – For each update or new idea, are your customers saying unhappy things. You can leverage these to get ideas for upcoming releases.
  • How happy is the customer – Have your customers stopped looking for a solution to their problem to wait for your solution.
  • How unhappy would the customer be – If the release was delayed one month, how do your customers react and would they look elsewhere.
  • Percentage of customer base interviewed or involved in usability testing – This is the total count of customers and potential customers involved in your ‘customer discovery’ efforts. The percentage involved will be a statistical significant number to allow accurate predictions.
  • Number of customers who have the problem you plan to solve – The count of customers you know have a specific problem you’re trying to solve. This can come from product feedback, interviews with customers/users, or other survey techniques.
  • Number of customers who want your solution – Count of customers/users who want your solution to their problem. This can come from product feedback, interviews with customers/users, or other survey techniques.

3. Innovation – technology, adaptability, and markets

  • Count of core initiatives – Target up to 70%. Efforts to make incremental changes to existing products and incremental inroads into new markets. Low to very low risk. Enough return to keep the business going for a time but not enough to sustain the business indefinitely.
  • Count of Adjacent initiatives – Target up to 20%. Leveraging something the company does well into a new space. Shares some characteristics with both Core and Transformational initiatives. Medium risk.
  • Count of Transformational initiatives – Target up to 15%. Create new offers (or new businesses) to serve new markets and customer needs. High risk but big returns if successful.

4. Agile – practices, methods, and processes

  • Number of Tasks added/removed during iteration – How well team knows the work and what done means for the story – INVEST criteria being followed and stories are small
  • Number of stories forecast Vs actually completed during iteration – How well the team understands the work of the iteration – INVEST criteria being followed and stories are small
  • Average size of stories in iterations – The ability of the team to make the stories as small as possible and still provide some value to customers/users
  • Average score of “Value” per user story – How well the team understands the customer problem and understands how the customer wants it solved (or what success looks like from the customer/user POV)
  • Percent of user stories in iteration covered by automated System/Solution tests – The team’s journey to automate end-to-end tests at the System/Solution level.
  • How independent is each user story in the iteration – How well the team understands how to remove complexity
  • Test First Vs Test Last testing done in iteration – Measure the team’s journey to be outcome driven at the System /Solution level.
  • Number of hours in iteration waiting for something – Measure of cycle time for same sized stories or epics.
  • Partially done work – By counting stories that are in progress at the end of a iteration we highlight the potential waste of incomplete work. This count is minimized by having small stories and having the development team managing their iteration backlog.

5. Environment – team working conditions and happiness

  • How happy are team members – This measures the general fun factor of work for the team. A happy team will work smarter and deliver a better product.
  • Number of hours in iteration spent helping team members grow and be better – Measure of an aspect of a self-organizing team: caring and improving the team.
  • Are you adequately served by management – Measure of how the team feels management is there to support them.
  • Frequency of team making product decisions – If the team is making most product decisions, they’re more likely to be enthusiastic about the product.