On one of my projects where we built a large software application on an agile scrum framework, we were a team of six product owners, and 20 developers. It was a highly competent group and I could not have asked for a better team to lead on an agile scrum based delivery. The problem though was each one of us looked at the project from one lens:
- The designers wanted to make sure this was the “coolest” application in the company, their reputation (read portfolio) was associated with it!
- Three of the product owners were excellent business analysts who would chase down every bit of information they could get with regards to a user story and write detailed acceptance criteria so that the test cases were close to perfect
- One of the product owners was responsible for ensuring that we had all the functionality for processing business rules and were integrating with other interfacing systems effectively – for him, all that mattered was whether we were processing all the rules correctly and we had every data element validated while doing a transaction in our system
- As the product manager, I was responsible for release planning and tracking progress to plan to report to stakeholders, so, I had to ensure that the development team had a good pipeline of work, whether we had the acceptance criteria detailed for the upcoming sprints so that the product owner team did not become the bottleneck for the developers
- The development team often negotiated for sprints dedicated to technical debt and/or refactoring
- My boss, the most agile minded person I have ever worked with had to ensure we were all collaborating with each other and the project was surviving the intense political drama that was very much part of any project in the company (I never envied his job!)
We did a lot of things right. Each one of us was trained with excellent tools to do our job. For me, use-cases were a great way to keep the big picture in mind and user story mapping was a powerful tool for release planning. The other product owners drew from other set of skills and strengths to do their jobs well. We structured ourselves in a way that gave each of us decision making in our own areas of work while also having reporting relationships to ensure alignment and visibility into the project. We had divided the development team into four teams and assigned one product owner for each team. We ran effort of managing the backlog of what to build parallel to the development track and ensured we were ahead by a few sprints all the time. I was crazy enough to ensure that happened!
We had some pretty frustrating problems though:
- Every time one of us added a story to the backlog that potentially impacted dates or scope of delivery, we were never quite sure if this was something we missed because we did not take the effort to understand the customer at the outset or whether we discovered something from the last iteration that gave us a better understanding of what to build
- If had to re-prioritize the backlog based on feedback from a sprint review, my boss was left to think about who he needed to meet for lunch to damage control for what we decided not to build to make our dates
- Every time an interfacing application or program was getting impacted, we were in a quandary – none of our prioritization techniques helped anymore, we were chasing a moving target that not only moved, but often changed directions
- Although we tried to stay ahead of the development team, every time we encountered a significant change in functionality, our user interface design had to be revisited for its usability – our developers hated it!
- Whenever the development team had to re-factor or clear technical debt, the issue of deciding what to build took an entirely new meaning with far reaching consequences that the product owners could not even fathom (I am sure that has never happened to any of you!)
Sounds familiar?! I remember one of the agile coaches calling the product owner a superman, a superman was what we needed to keep this going – the only reason we survived was the incredible commitment of every one of us to the project and to our work. No forum on agile product management, no training on business process management, no discussion on how to make UX work with agile was helping. We did have a project manager helping us manage the many moving parts, but, when it came to “deciding what to build”, the product owner team was on its own!
Right now, there is still a lot of focus on helping organizations transition from waterfall to agile. I am optimistic that soon, the dust will settle on agile adoption and it will become the norm for software development. But, when that happens, the very principles of agile will become the challenges to deal with – how do you not lock down scope at the very beginning of the project and still retain your sanity for the rest of the project. How do you not design everything upfront and still not lose velocity in development. What is “just enough design”, what does “just enough analysis” feel like? What makes waterfall easy is that it does not leave any of these questions to subjective answers – you are done with requirements when everybody “signs-off”, you are done with design with it can be traced back to the “signed-off requirements” – simple solution – yes, we know it does not guarantee good products, but, it did not ask for me to hire a team of supermen in my product owner team. It’s not often, but, sometimes, I do put my sanity over my product!
A holistic approach to deciding what to build means we move beyond principles and best practices to scalable and repeatable solutions. To look at the problem from the lens of just UX or engineering or product management or project management is IMHO making it appear that the problem is going away when it might be getting worse.