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.
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.
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.