Sometimes all you need is Waterfall Agility
Target Audience: Product Managers, Project Managers, Individuals with higher than normal Openness to Experience.
This is a post on how to build products, but as all groundbreaking historical moments, it must begin with a story. This story will show that some of the most Agile climbers end up chasing a series of waterfalls, albeit with style.
They teach you in Agile that customer feedback loops is critical to the success of the project. Which is correct. What they normally don’t tell you is that projects require boundaries and waterfall is an amazing way to communicate the beginning and end of a project even if the product never does get done in reality. I’ll attempt to highlight how that might work in reality.
It was a hot summer day when we walked into the exaggeratedly air conditioned teaching training facility in Muscat, Sultanate of Oman. If the foggy glasses didn’t expose the customer’s over preparation, I’d have to say the 40 person initiation meeting was a cue this project was going to be an adventure.
They also teach you that the project is half done if the requirements are gathered correctly (although Dave Snowden will probably have a mouthful to say about requirements gathering but I’ll just rest my elbow on the Business Analysis Book of Knowledge as he shakes his disapproving head for the time being). Where were we? Oh yes, the training centre in Muscat wasn’t a large one, they catered to a total of 5,000 trainees a year.
For a single 6 story building, handling 5,000 trainees is an operational and logistical challenge since 50% flock to the capital from around the country, and the training operations in particular had quite a long list of activities that needed to be looked after by a team of roughly 52 full time, fully capable employees.
After about 54 customer interviews, the Actors, Personas, and 250+ Business Requirements were gathered with all the t’s dotted, and i’s crossed that you could imagine a Business Analyst and a Scrum master could muster. We created a Project Charter, initial priorities were set, stakeholders decided, and schedules created.
Two months later, we were back with the first set of mockups. Our process was relatively Simple although not Easy (more on the distinction between the two later) and this is how it went:
- The Agile Product Development Process
- One Time: Interview Staff → Generate Business Requirements → Create Job Stories & Narratives (Functional Requirements)
- The Loop: Interview Customer → Modify Job Stories & Narratives → Design Interactive Wireframes (UX)
- Single Shot Attempt: Design UI → Deliver Product
2. Feedback continuously moves each of the Sprints forward or holds us back until we get an approval that the Wireframes meet the Project Business Requirements (BR)
3. Sign-offs are from the relevant owners of each BR, sequence is determined by priority from the final (yeah right) Project Charter
4. Code isn’t written until UI looks amazing
The remainder of this article will discuss how we explain what happens during those Wireframe Agile meetings to help other navigate the angry expectations of frustrated public servants patiently awaiting a solution to help them get their day to day operations out of Whatsapp and into an environment they can actually track.
The Agile Customer Feedback Meeting
It’s worth noting here that we would meet every 1–2 weeks with the customer after having generated Wireframes for about half of the BRs in the order of priority we received, with added caveat that in software development some things need to be designed before you can actually move on to the following part. Think of this as choosing the highway route before setting the exits in stone.
In reality we prioritize designing User Journeys proportional to how many BRs (and their respective priorities) are affected by them. I’d love to break it down for you because it’d illustrate a good example or heuristic & data driven decision making, but I’ll leave that for a different post.
The problem with gathering feedback from around 100 people who work in a single organization is a couple of things:
- They rarely understand the context of the meeting (nor the meaning of Wireframes)
- They weren’t the people who gave you the first set of Business Requirements
- They rarely receive & read the Agile Customer Feedback Agenda you shared in advance
- It’s hard to guess whether they like to see a guy in a suit or jeans & t-shirt (so I usually dress to impress)
Based on the above 4 challenges (looks matter — a lot!), we decided to explain to each of these groups the Agile process, and the design and UX ethos which would go as follows:
- The Project Management Framework (what is Agile)
- Who we are, who they are, what we’re doing here today, and what we hope to get out of this workshop
- How we design our products (iPhone vs Android)
- Nomenclature
Business Requirements (BRs): what they are & why they should care
User Journeys: what they are & why they should really care
Wireframes: why everything looks so ugly
(customer) Business Owner Priorities vs (our) User Journey Priorities aka In which sequence we choose to build - Updated Wireframes based on the previous Sprint feedback
- Feedback on Wireframes (where we ask the customer to look beyond the squiggly lines & green backgrounds)
- Next Sprint: BRs, Updated Wireframes, & Stakeholders involved
As you can tell by now, we go progress through every sprint with a lumberjack’s attitude, taking down one BR at a time, from beginning to end. The trick to us, is telling an internal narrative about each of the User Roles based on the 54 interviews, and continuous feedback we receive from the customer during the Sprint review meetings.
Each project with a Kickoff, Milestones, Schedules, and Signoffs. Cringe-worthy as it may be to some, the real world doesn’t work in binary Agile vs Waterfall mode. But instead in a context based, empathy driven, pragmatic way.
If you’re interested in UX and Product Design, look out for the next post: The One Question Every Product Manager should be able to answer: Are you building an Android or an iPhone?
