FOUR: Developing a “WaterScrumFall” Process

The Challenge: As I shared earlier, management needs a roadmap, a schedule, a vision document, a plan. “But that’s not Agile!” says the Agile team. This is one of the main reasons that many companies either overtly or covertly create a hybrid of Waterfall and Agile. They use Waterfall to clarify the front end to develop a plan, and then allow the development team to take over and use their Agile approach. Once the product is near market release, the team will attempt go back to the plan developed under Waterfall thinking. This often includes applying the launch readiness criteria developed in the front end planning and gets a quick response from management, “Hey… this isn’t what we agreed to!” to which the development team responds, “Hey, it’s Agile.”

While this hybrid process can work, it creates great strain on the organization due to the management team following one process and the development team with different process philosophies, terms and metrics. In Waterfall, once a “plan” is baked and approved, there is an expectation that the plan will be followed and delivered upon, even if the development team is using Agile to execute. Now I’m going to say it, “But that’s not truly Agile,” since Agile requires the plan to be flexible and consistently reprioritized and revised. We see this approach so often that we’ve heard many describe it as, “WaterScrumFall.” It’s really business as usual with a traditional process of defining a complete product up front and then the development team using an internal Agile process to conduct the work break-down process to deliver code. But often the real testing, and real development, doesn’t even start until testing of the expected deliverable starts. This is way too late to leverage the power of “agility” in software development. Let the blame games begin!

The Solution: True Agile requires that management, marketing, operations, and other functions are aligned with the principles of Agile development. Agile evangelists must acknowledge the needs of business leaders and other departments, and these other groups must acknowledge the methods and benefits of Agile. In more concrete terms, product roadmap milestones and market releases developed in the Waterfall model must be aligned completely with Agile sprints and software releases. If the development team is practicing Agile, they must create deliverables that track to the plan and provide early warning of what is really getting completed, and how it reflects on the roadmap. To guide the development team’s iterative approach, the marketing and sales teams must be clear on what customers deem most important and how market dynamics are impacting solution requirements to guide Agile efforts with every Agile “sprint.” Communication of progress and product deliverables must also be spoken in both Agile and business teams. For example, use cases and tasks must be translated to the promised features, and business models must be broken down into user stories. The bottom line – any Agile approach used by the development team must support all business needs and address all stakeholder concerns.

Read part 1, 2, 3 or download “The Five Challenges to Agile Planning” whitepaper.

THREE: Not Building in Real Customer Feedback Loops

The Challenge: A major tenet of Agile from the Agile Manifesto is, “Our highest priority is to satisfy the customer.” However, let’s be clear. The Product Owner is NOT the customer. The people in marketing are NOT the customer. The CEO is NOT the customer. The only person that is the customer is… well… the Customer. This may sound like a “duh” moment, but this is by far the biggest challenge to Agile development teams working on market-focused products. When Agile first got traction with IT and internal development efforts, bringing customers directly into the Agile process was relatively straightforward. Just take a completed iteration down the hall and sit down with the “customer” to get their feedback. However, as Agile spreads to more open-market solutions gaining real customer feedback in a timely manner is more difficult, and is particularly challenging for a new project that doesn’t have any paying customers yet, and even more challenging for consumer-based products, where the “customer” often feels like a mass market of people.

There are several reasons we see why teams find it challenging to bring in real customers during the Agile development process:

1. The perception these activities will slow the team down.
2. The input is fuzzy, so often ignored.
3. Uncertainty of who the customer really is.
4. They just don’t know how or try to rely on traditional surveys or focus groups.

Because of these challenges, it’s easy for developers, or even Product Owners to take shortcuts and use personal opinions statements such as, “I’d want this feature,” “It should work like this,” or “The customer will need this,” to drive product decisions, rather than build in real customer feedback.

The Solution: To be truly Agile, it is critical to bring customers into your efforts at the right points and with the right methods. While gaining real customer insight throughout Agile planning and development may seem challenging, it doesn’t need to be. We use three simple and equally important steps to gain Rapid Customer Insight that support Agile development efforts. These steps are:

1. Access: You must find and identify a set of target customers that you can rely on to provide accurate, timely insight. These are often early adopter customers that will not only share their insight, but want to be part of your success. Successful Agile requires developing a well-maintained customer panel or advisory board.

2. Listen: Once you have direct and rapid access to customers, you must build skills to actively listen to them. This isn’t running a focus group, launching a survey, or asking them what they want. Although these methods can also be used, having high-quality interaction with your customers, either in person or through appropriate collaboration tools is critical, probing them for real needs, problems, desires, and objective feedback. Listening is also being able share early designs to learn how your customer is thinking, how they would prioritize elements of your solution, and the tradeoffs they are making in their head.

3. Communicate: This learned insight into your development efforts through clear and prioritized use cases, the relative value of each feature, and building test cases that reflect how your customers would want to experience your product.

Read part 1, 2 or download “The Five Challenges to Agile Planning” whitepaper.

TWO: Clarifying the Role of “Product Owner”

The Challenge: Another critical challenge that can cause short and long term angst is in selecting, defining, and empowering the role of “Product Owner” in your new Agile process. Let’s accept that this is one tough role. They are responsible for being “the voice of the customer,” the evangelist and decision-maker, and the perfect blend of business acumen and technical savvy.

Should you select a product manager who has previously been the product champion and tradeshow extraordinaire – but doesn’t know Agile software development? Or perhaps you should select a project manager or program manager that understands software development and perhaps has heard you should do some focus groups. Or perhaps you should nominate a solid, innovative architect that can design a 20 billion-user system? Whatever the choice, the Product Owner is a critical role to drive priorities, approve software releases, and be a liaison between development and the rest of the company… and often the market. Selecting the wrong person or incorrectly defining the product owner role leaves your Agile team limping along, or worst, at the whims of a control freak bent on driving personal opinions into the product.

The Solution: The role of Product Owner is indeed challenging. You should think about it more as a set of activities, interactions and desired outcomes rather than a job title and structure your team and responsibilities accordingly. As a “Product Owner”, one of their main roles is spending a significant amount of time directly with the development team. They must participate in every iteration review (often multiple meetings per week), write and review use cases, help write and approve test cases, and be available to review and approve software releases. This is a very hands-on role that requires serious time and commitment. If someone is this engaged with the development team, who is doing all that important market and customer work? It has be someone, or expect to fail. Someone, such as a Product Manager or Product Marketing Manager must take this more business-focused role and be the ying to the Product Owner’s yang. Getting these two roles in a room to work out how they will work together and how decisions will be made at the very tactical level is a key step to success. One tip – have the Product Manager participate in planning meetings, agree on priorities and implementation, then allow a more technical Product Owner to drive day-to-day decisions, write use cases, and approve test cases. Have them sync back up for software releases, and then fix any conflicts with the next Sprint. If one person is responsible for all of these activities, only a superhero will be successful except on small projects or in much-defined markets.

Read part 1 or download “The Five Challenges to Agile Planning” whitepaper.