Product Owner Prioritization, Lean, and Experimentation
In environments I have seen, the Product Ownership (PO) role and the Software Developer role (Dev) are separated by some sort of artificial boundary. Sometimes that is an separate department, a ticketing system, time availability. Though we have the same overall goal of getting working valuable software into production, at times we have different incentives and often we have different schedules, responsibilities, and secondary measures of progress. Alignment and re-alignment are so important that teams will often create standup meetings to make sure everyone is on the same page. I believe it is important for us to not just stop at alignment but instead create a cadence of experimentation and regular improvements to the interactions that occur cross functionally.
Cross functional retrospectives
One great way I have found to create a continuous improvement cycle with two groups that have this artificial boundary in the way is to create a recurring lean coffee focused on how the team works together. It is very open ended and could equally be about the "Bright Spots" as well as areas for improvement. The main. This works well not only with PO and Dev interactions but anywhere where there is a cross functional interaction.
Equality of representation
One caveat to this is the fact that Product Owners are often largely outnumbered by Developers. This makes retrospectives and lean coffees uncomfortable. This is why I hear regularly hear from typical Scrum teams that other functions like POs regularly miss the team retrospectives. Their time is usually not used well and the resource efficiency mindset can incentivize them to regularly miss these retros. The best way I have found to make this interaction more natural is to constrain the number of people representing each side to be equal. If you have 4 projects with 4 different product owners, get them in a lean coffee with 4 developers on the team, not all of the developers. This makes for a nice 8 person lean coffee that will result in ideas for experiments that the team can run to improve the process.
Psychological Safety & Radical Candor
Foundationally the ability to deliver critical feedback without fear is extremely important to the effectiveness of a team. Developing a relationship with someone that results in this kind of candor takes time and is much more likely to form for people who interact often. In the case of the product owner and the development team we want to see unfiltered, constructive, kind, considerate, and respectful feedback.
SBI Feedback
One way to develop this skill is to intentionally practice "Situation Behavior Impact" feedback. This format of feedback is much easier to deliver and harder to get wrong. It is also a widely recognizable feedback format which means people know you are trying to be respectful when delivering it because you are practicing deliberate feedback and not winging it off the cuff which can sound hostile in new or low safety environments.
MVP Small Vertical Slices
Targeting a minimum viable product should be the first discussion topic. We want to agree on the best way to conquer the 80/20 rule. Meaning we do not want to write any excess software. An MVP built our of small production deployable vertical slices prepares prepares us to maximize value of code produced rather than risking waste from partial features.
Cost of Delay prioritization
The second discussion we should include the next releasable vertical slice. Product owners have a vision for the product that includes many valuable insights about what he customer needs. Sometimes they also have trouble prioritizing those features based on a lean value stream. If everyone speaks in terms of cost of delay as long as we keep the items
Lean UX Prioritization
If Cost of Delay does not result in a releasable slice, or the PO has a good business case to not release right away, moving to prioritization based on highest risk and highest unknown. Too often developers will work on the easiest code first to show progress quickly which builds up risk especially with known unknowns. The opposite should be the target. If Cost of Delay for all features is the same, use highest risk and highest unknown to prioritize over the input of the product owner. If you cannot release to a customer without all the features being complete, then all Cost of Delays are equal.
Common Language of Lean
These conversations can be further improved by implementing a common language for large concepts. Specifically "Lean" has terminology that can make it easy to give feedback about optimizations that can be made in the process. With Lean we know how to eliminate waste and implement "Kaizen" processes of continuous improvement. When talking to the product owner, now developers can say "We are creating waste in the system by having a poorly optimized value stream on our delivery pipeline." Alternatively the product owner can tell the developers that we are creating over processing waste by gold plating a feature that is good enough.
The following concepts are described in detail in the book Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck. I wont go into too much detail but I wanted to describe some practical applications of the following.
Eliminate Waste
Targeting and eliminating process wastes is a great way to frame retrospectives as you do your normal development processes. For example; retrospective prompts can include
- Partially done work: "Is there any partially done code or features we are currently working on?"
- Extra Processes: "Let's build and optimize a value stream map (VSM) of the team's process."
- Extra Features: "Let's look at analytics together and identify unused features. What can we learn about these features and should they ever have been developed?"
- Task Switching: "Do we thrash? Are we experiencing additional costs around context switching?"
- Waiting: "Are there any relationships or interactions we can work on to help eliminate waiting in the development process?" This can target executives or even other teams that are dependencies to the development.
- Motion: "How much time do our most important questions take to get answered? Can we optimize this?" - This one was a big impact. Once we transitioned to remote we noticed a dramatic increase in the speed in which questions were answered.
- Defects: "What would it take for us to approach zero bugs without sacrificing development speed?" This is not only achievable but extremely effective once achieved.
- Management Activates: "How can we achieve minimum viable bureaucracy?" Which activities are value adding and which ones are non value adding? Value Stream Maps are also very effective here.
Amplify Learning
Learning is extremely important in a software organization. The absence of learning opportunities in an environment has a catastrophic effect on teams. Consider an development team with a significant diversity in work experience among the team members. A developer early in their career is likely to have a lot of free time at home and their personal life is not impacting their free time as much as someone later in their career. If there is no opportunity to learn on a team, then the developer earlier in their career can spend time outside of work learning to get ahead. This type of person might be considered a 'go getter' and viewed in something of a positive light. What about that person later in their career? They likely have more responsibilities outside of work. This means when confronted with a requirement to learn they are incentivized to discourage it. The result is the least experienced people on the team are the most capable to move the code to newer technologies. If the seasoned developers have the power the codebase can stagnate, if the developers earlier in their career have the power then the senior developers have increased stress levels and are encourage to fight the direction of the team. Dedicated learning time is paramount to the success of a development team.
Decide as late as possible
When will you know the most about the decision you have to make? Up-front architecture can be the enemy of appropriate long term changes. Developing the ability to make decisions later in the process is important to the quality of the decisions.
Deliver as fast as possible
Delivery helps amplify learning, it also allows for your company to capitalize on the cost of delay of your proposed features. Delivering quality software quickly allows for a tight feedback loop and better product development.
Empower the team
I recommend reading "Turn this Ship Around" when considering empowerment of the team from a leadership prospective. The book covers the topic well and is inspirational in its description. One thing that I think allows teams to hold themselves back from self empowerment is the assumption that something cannot be changed when it can. If a team is not doing retrospectives with solid action items and follow-up on those action items, they should absolutely start doing so. The bigger issue is that I regularly encounter teams that take a process or rule as set in stone and do not even think to retrospect on it even if their retrospectives are well facilitated and follow-up is regular.
Build integrity in
How do you create software that fits your user like a glove? How can you and your team not only make great software but make the right software? Feedback loops and the flow of information is critical to developing software with high integrity.
See the whole
Evaluate your processes, metrics, systems and every component of your entire environment as a whole product. Considering the effects of complex adaptive systems and utilizing systems thinking to experiment on not only the software as a product but the complete multi faceted production process from inception to use.
0 comments:
Post a Comment