In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?
In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?
Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.
While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:
With great knowledge comes greater responsibility.
When we are managing projects using a predictive delivery approach, dependency identification and tracking is done as part of the BPUF (Big Planning Up Front) exercise using the activities from a work breakdown structure and the collective wisdom of our team members and key stakeholders. If a major scope or solution approach change is identified afterwards, the impacts of addressing new dependencies is usually considered in the analysis of the change request.
But on those projects which follow an adaptive lifecycle, this gets a bit trickier. Given the emergent nature of requirements and design, we are only able to see dependencies to the extent of our team's "headlights" which might just be showing us the next two weeks of work. A team might have "Have all dependencies been identified and captured?" as a guideline within a Definition of Ready (DoR) but that doesn't always mean that it is possible to satisfy that dependency just-in-time.
We always strive to build a whole team which possesses all of the skills and authority needed to deliver the full scope of the product or project.
But sometimes, we need a subject matter expert for a small subset of the product features and if we don't identify that need early enough, we won't be able to deliver those features in a timely manner. In addition, building a whole team in larger organizations is often challenging as there are established delivery or control partner teams who must contribute to specific product features but won't necessarily be available at a moment's notice.
One way to reduce the risks associated with dependencies being identified too late is the combination of upfront story mapping with ongoing look ahead planning.
Story mapping provides an opportunity to bring together key delivery and control partners to review the high-level stories which the Product Owner and team are identifying. Giving these external partners a chance to indicate which stories they are interested in will help the team know who they need to line up as the time approaches to complete one of those stories. Based on how high those stories show up in the story map, they will understand how soon they might need to be engaged. Team members can also start to identify and capture the inter-dependencies between individual stories to help the Product Owner with backlog prioritization.
As stories with dependencies start to move up the backlog, as part of a look ahead planning activity, the team can proactively contact the external partners to request their participation a sprint or two into the future.
Planning is an ongoing activity with adaptive approaches so without this, an external partner your team needs is likely to respond with the old cliche: "A lack of planning on your part does not constitute an emergency on my part."
While teaching a class earlier this week, a learner asked how will team members start to feel psychologically safe, especially if they are working in a company whose culture isn't fully supportive of this critical ingredient to a high performing team.
Updating existing corporate values, and senior and middle management leaders holding themselves and each other accountable to modeling behaviors consistent with these refreshed values helps as does coaching at all levels of the organization. For individual team members, the Scrum values can provide good reminders of our own responsibilities for creating a psychologically safe working environment regardless of which delivery framework or method we are using.
Commitment: While we normally think of this value in terms of committing to achieving team goals, this value can also be considered as a shared commitment to creating a safe environment.
Courage: The Scrum Guide encourages team members to show the courage to do the right thing and work on tough problems. This is equally applicable to interpersonal relations. It takes significant courage to speak up when you witness behavior which is corrosive to psychological safety especially when the person misbehaving is more senior than you are.
Focus: While team members should be focused on completing work, living this value also means that we are focused and actively listening when we are part of a discussion or ceremony. By doing that, we are better able to pick up on the tone and body language of others to understand if they are feeling uncomfortable about what has just been said or look like they want to say something but just need that little bit of encouragement to speak up.
Openness: Just as we expect our teams to be transparent about the blockers they are facing, the same level of openness should be exhibited during retrospectives or other opportunities for inspection and adaptation with regards to how we interacted with one another.
Respect: Demonstrating this value towards our team members means not only treating them with respect but challenging others who would show them disrespect.
Edmund Burke - "The only thing necessary for the triumph of evil is for good men to do nothing.”
My article last week discussed the need for team members to act with responsible transparency. Each team member requires discipline and wisdom to judge when an issue preventing them from completing their work items can be resolved quickly without the need for broader communication or escalation.
If a blocker surfaces and no one other than the person who encountered the impediment is aware of it, the delivery of that work item could be critically impacted resulting in a cascading set of delays. The same holds true for the team as a whole. I've occasionally worked with teams whose members are uniformly confident in their ability to resolve any blocker which arises. Such teams can go out of their way to show that they are in control and everything is going well on their delivery work, right up till the moment when it is clear to all that this is not the case.
So assuming that team members are doing a good job of surfacing impediments, how should these be communicated and tracked?
The project manager will likely be accountable for maintaining a project issue log but depending on where that artifact is housed it might not be visible enough to create the right sense of urgency from the stakeholders who can help the team resolve issues. Also, such a log is likely to track higher level issues and not just those affecting individual work items.
If a detailed schedule is being used to plan and track work activities, blockers could be directly linked to the affected activities, and indicator icons or flags can be set to highlight the tasks which are currently blocked. But that still requires stakeholders to regularly review the project schedule.
A better approach is to expose blockers through existing information radiators.
If a work board is used to help the team manage their work flow, blockers can be identified in one of the following three ways:
Blockers can also be tracked separately using a pain snake (sometimes called a "snake on the wall"). Every time a new blocker is identified, a new stickie is added to the snake. The length of the snake will help encourage the team not to allow too many blockers to remain unresolved.
So how bold are your team's blockers?
The essence of project work is uncertainty, and much as we say that we thrive on variety and change, our teams face multiple challenges on a daily basis. A certain amount of venting on the part of team members is bound to happen over a project’s lifetime, but when blowing off steam becomes the norm instead of the exception, and the majority of the complaining is purely negative, it can start to suck the energy out of the entire team.
While most project managers might feel this is the lowest priority of the issues they will have to manage each day, negativity is contagious, and one team member’s chronic complaining will eventually infect others with this behavior and will irritate the remaining ones – in both cases, productivity gets impacted.
Even more corrosive is when the project manager exhibits such behavior. While most project managers are likely to feel that they don’t possess sufficient formal authority over their projects or team members, they do wield enough influence that their negativity is likely to rub off and impact the productivity of the overall team.
Don’t get me wrong – I’m not advocating that everyone on the project has to join hands and sing Kumbaya in spite of how well or poorly things are going. There ARE going to be issues, some of which cannot be resolved optimally, but what we can control is how we choose to handle these situations.
The book The No Complaining Rule is written around a parable to provide practical approaches on how to tackle the issue of workplace negativity, and while most of the techniques provided by the author are intended to be applied individually or at an organization-wide level, there’s no reason why they can’t be adapted for use at a team level as well.
One way is to institute a No Complaining day each week – team members (including you, Mr. or Mrs. Project Manager!) who complain without providing solutions or without qualifying complaints with positive thought or action are charged a nominal penalty. The paid amounts will be saved up and used to fund team celebrations or a charitable donation. Once the team is able to successfully handle one day a week without complaining, increase it to be one week each month, and so on.
If the team is already in the grip of negativity, it can be hard for someone who is as close to it as the project manager to identify, but if metrics such as work item completion velocity are being calculated and tracked on a regular basis, it should be possible to identify productivity declines. The project manager should also practice active listening with stakeholders or the customer to see if they are becoming keenly aware of the project being a never ending “whine & cheese” party. Finally, it may be worth inviting peer project managers to sit in on the occasional status meeting – not being directly involved they may be able to pick up on such issues.
To plagiarize (and misquote) a famous Jedi Master: Negativity is the path to the project dark side. Negativity leads to stress. Stress leads to reduced productivity. Reduced productivity leads to project failure.
(Note: Positive when I wrote this article in june 2013 on kbondale.wordpress.org I was. Yes, hrrmmm.)