Waterfall, Agile, Wagile?

This is not another article about the differences between Waterfall and Agile software development. That topic has been beaten to death. As Product Owners and Agile Business Analysts in Application Services, we continue to learn that it is not about what software development prescription a customer has always used but how we find efficient ways to work within the constraints of their sandbox.  

Define the sandbox 

When we start a new project, it is essential to begin with understanding the struggles our customers are going through and consider those as we work to figure out how our organizations will collaborate.  

We begin our engagements by identifying the boundaries of the project's sandbox. This can include a typical project roles and responsibilities alignment, but we are not afraid to dig in deeper. We often push beyond what some might be comfortable with to challenge and then confirm the boundaries for the sandbox. We look for lengthy or complex approval mechanics that are necessary constraints on the sandbox and we work to establish a clear path for the continuous delivery of value, working software. As we are collaborating, we create and update artifacts that we can all rely on as the source of truth for the sandbox, including everything in the sandbox and all of the boundaries and constraints for the sandbox. This investment increases our collective clarity on our constraints and establishes a clear space for the team's autonomy in their execution.

Be empathetic

A key mantra for us is, "meet the customer where they are at." This is key for us because we recognize that each organization is uniquely different. We can not assume that what has worked for us in the past will work for a customer. People in organizations have expert knowledge of what has worked and has not worked. So we meet customers where they are, both in terms of their agility and technology stack. A key benefit that we bring to the table is our deep expertise and breadth of experiences across the industry. We use our experience as we partner with customers to advise and guide them throughout projects. We create a safety net that makes it safer to experiment and to stick a toe in the seemingly murky waters of trying something new.  

The art/benefit of introducing ideas 

Change never happens in a day, but it does come with enough persistence. Though we might not make the change today, we can introduce ideas, and through our collaboration and partnership help customers make that change a reality in the near future. Understanding that change is difficult on a good day, we seek to understand and demonstrate the benefits of making the change and provide the safety net to reduce the perceived risks of the change. Actions speak louder than words and experimentation is how we prove the benefits or how we fail fast, pivot, adjust and try again.  

Educate from the beginning

So how do you best align? At the start of a project, treat the conversation as you would getting to know your partners, co-workers and stakeholders. Understand what the project means to them, why it is important, and what is flexible. Agree to it, write it down and share it with everyone to drive clarity and reduce the chance for confusion down the road. 

The goal is to show the customer that you have good social awareness of their world. When it comes to change, be sure to explain the rationale for it from the beginning. Even if a reason seems fundamental to you, it is still important to ensure clarity and alignment with everyone involved. This will set the stage for the right questions to come up and the right conversations to be triggered.  It even helps to have your customer walk you through a day in their life so you can see their reality. Doing this helps you get that better view of their world. There are services/tools that can help support this research like an ethnographic field study of contextual inquiry.  These are conducted by our UX Researchers providing a deeper understanding of your customer's pain points and opportunities.

Always define important words 

Clarifying the meaning of important words is vital to successful product delivery. Aligning everyone with an agreed-upon definition, from the beginning of a project, helps to ensure clear and concise communication. Never assume that a word means the same thing to everyone.  

Minimum Viable Product (MVP) is a classic example of this. While Eric Reis defines MVP as "that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort," that is not always everyone's understanding. In fact, you may be surprised by how many different definitions there could be. We have worked with many customers that believe MVP will include everything they ask for. Or that it means perfection in the few features they have. It may be better to abandon the term MVP altogether and plan in terms of milestones in some instances. That is okay if everyone is aligned with what your milestones entail.  

Address the squeaky wheel 

With new ideas and change, there will be challenges that halt progress at times. We've all heard comments like "we've always done it this way," or "I don't have time for this right now — I have five other projects going on."  If you run into this unfortunate situation, it is best to just get ahead of it before the problem becomes too big. 

Set up a one-on-one meeting with anyone who possesses this kind of sentiment. Create a safe place for them to be open and honest about the core issue(s) they are dealing with. As we know, we're all human with emotions, life problems and work. Find out what is the motivation or obstacle keeping them from adjusting. Identifying these key pieces of information can help you negotiate a mutually beneficial path and build trust that is pivotal to making a successful project.  

Be adaptable 

We can all appreciate the challenges that come with the Waterfall development methodology, but we should recognize that it exists for a reason. That alone is something we should respect and try to appreciate. How can we take the key pieces of our toolset and mold them into solid pieces of the customer's environment?  We know not everything will fit perfectly, but that's where open communication will help move things along. 

Conclusion  

In conclusion, have a conversation. Ask questions, listen to understand. Be adaptable and never assume. Document agreements that are made so there is clarity when our memory decides to play tricks on us. Waterfall vs. Agile is only a line in the sandbox that you and the customer are playing in. At the end of the day, you still need to find a way to work together to build a sandcastle.