We might assume that transparency should be a given when delivering value through our projects so why is it that the actions of teams or the stakeholders supporting delivery don't always demonstrate that basic hygiene factor? Transparency is so critical that the Scrum Guide lists it as one of its three pillars and it is similarly echoed in the reference materials for many other agile delivery methods as well as in PMI's Code of Ethics.
Transparency is a rising tide which lifts the attitudes of all stakeholders:
I wrote a few years back about the downsides of unfiltered transparency as this could generate unnecessary panic or encourage micro-management from our stakeholders, but responsible transparency is key to creating trust.
Responsible transparency is about providing the truth, warts and all, but ensuring that sufficient context gets provided so that our stakeholders' reactions to the truth are appropriate. Project teams have many tools and techniques available to them which can provide transparency about progress and impediments, but using these in isolation may not provide that context. For example, reviewing individual work items in a sprint backlog without also being aware of the sprint goal(s) identified by the Product Owner doesn't help a stakeholder see the forest for the trees. Similarly, trying to interpret a burn down or burn up chart without understanding the team's delivery approach or the contents of a sprint or release backlog might create the wrong perceptions.
So as you strive for transparency in your information radiators and other communication methods, ensure that you are providing the necessary color commentary to make the information meaningful.
The single most important ingredient in the recipe for success is transparency because transparency builds trust - Denise Morrison, (Former) CEO, Campbell Soup Company
I'm midway through reading Choose Your WoW! from Scott W. Ambler and Mark Lines of the Disciplined Agile Consortium. While their 2012 reference book for Disciplined Agile Delivery provided guidance for teams interested in tailoring their delivery approaches, the new book delves much deeper into the key goals, decision points and options for those decision points. It also provides external references to inspire practitioners to venture down the rabbit holes for the practices they wish to explore further. The main content of the book comes in just under four hundred pages but given the volume of information provided, it shows that the authors have been practicing what they preach when it comes to minimally sufficient documentation!
Their book focuses on teams using adaptive lifecycles for delivering technology solutions but it would be still be helpful to address the needs of teams who are utilizing traditional approaches for delivering projects in other industries or domains.
What would the outcome have been if the volunteers who created the sixth edition of the PMBOK Guide had taken a similar approach? Yes, the current edition contains new sections with tailoring considerations but those are just scratching the surface of that critical topic.
Perhaps they would have realized that the current guide should have really been released as two separate documents. There is still a need for a PMBOK framework reference covering process groups, processes, inputs, outputs, tools and techniques, but much greater value would have been realized by practitioners in having detailed guidance for exploring the key goalposts and decision points taking into account the context of a given project and the culture of the organization they are working in.
This could be done using a decision tree approach similar to that used for Disciplined Agile but imagine how much fun it would have been if it was written like a Choose Your Own Adventure® book? Such a guide could help teams understand the options available to them while simultaneously exploring potential downstream implications of their decisions. Add in some cartoons illustrating key concepts and the Guide would no longer be considered a surefire cure for insomnia!
I'm midway through Priya Parker's book The Art of Gathering and her insights into how to make an event a meaningful gathering rather than "just another boring meeting" are apropos to ceremonies. A common complaint many team members raise in the early days of an agile journey is that it feels like they are in too many meetings. This shows that they aren't perceiving the value of the ceremonies and, if these concerns aren't addressed quickly, the team members are likely to disengage.
One way to evaluate your ceremonies is to do a W5 assessment on them.
Without a shared understanding of the purpose for the ceremonies, misalignment of expectations and behaviors may emerge. It is critical that a newly formed team understands why each ceremony is needed, but as the team evolves, the purpose of each should be reviewed to ensure it remains relevant. One way to gauge this is to ask each team member to summarize what they believe the purpose of the ceremony to be in three words or less.
Once there is clarity on why, we need to confirm that the outcomes of ceremonies are being realized and are in line with the purpose for conducting the ceremonies. Poll team members on their perception of the effectiveness and efficiency of producing those outcomes.
A common challenge with agile ceremonies and most recurring events is that, over time, you might pick up a number of participants who "just want to observe" or "need to be kept in the loop". If everyone is needed, no one is needed. A self-disciplined, self-managing team will weed out those stakeholders who aren't required but will be equally diligent on ensuring the right participants are at each ceremony. For example, conducting a sprint review without adequate representation from those who will be consuming the outputs of the team is a waste of time. Who is also about the role each participant plays. While new teams might lean on the Scrum Master to facilitate most ceremonies, over time, this can become a shared responsibility, giving each team member a chance to develop their facilitation abilities.
It is a good practice to hold ceremonies at the same day and time but the timing that seemed ideal in earlier sprints may not suit all participants in later ones. It is also worth evaluating the duration of the ceremonies as they should be long enough to meet the purpose and achieve the expected outcomes and no longer. If certain team members are missing certain ceremonies, it is worth confirming whether the timing is still suitable for all participants.
Whether it is physical meeting rooms or virtual video conferences or collaboration environments, it is important to ensure that the location supports the purpose and approach and doesn't detract from it. In physical settings, this could be as simple as the arrangement of chairs around a table and the availability of white board space for spontaneous collaborative activity. Consider alternative environments for physical ceremonies. Could it be possible to conduct some in a more dynamic manner - perhaps as a walking meeting? In virtual sessions, this means ensuring that the tools provided (e.g. polls, whiteboards) are functional and everyone knows how to use them in advance of the ceremony.
How frequently ceremony reviews should take place will vary and one trigger for a health check might be to have team members vote every few weeks or every couple of sprints on how valuable they feel each ceremony is.
To paraphrase Chris Fussell "If your team is trying to be more agile, stop and think, 'Are my ceremonies actually productive, or are we merely having ceremonies for ceremonies' sake?'"
There is no single recipe for how to best manage a project.
Culture (organization & team) and enterprise environmental factors all influence how a project gets managed but personal style and approach also plays a critical role. Within the constraints of the previous factors a project might be managed successfully but the degree of efficiency can vary widely between project managers.
It might not be advisable to invest a lot of effort in analyzing how we are adapting and executing each of the PMBOK processes, but we can lean (pun fully intended) on process excellence to help us identify common sources of project management waste.
Is your approach to managing projects as efficient as it could be, or are you stuck in a WORMPIIT?
(Note: this lean & mean article was originally published in October 2015 on kbondale.wordpress.com)
I was asked to facilitate a lessons learned session for a program team using a retrospective format. After the team had brainstormed, prioritized and discussed most of the challenges they had faced, it became clear to them that there were only a couple of root causes for most of the main pain points they had identified. Neither of those root causes was a true learning but rather they were just simple reminders of good practices to follow for large, complex programs. I then asked them the somewhat rhetorical question: "Remembering now what should have been done then, how will you ensure that this doesn't happen on a future program?"
A project team I've been working with has struggled with judging how many work items they can successfully complete within a sprint. In the retrospective for their last sprint, they identified a number of simple, effective ideas for resolving this chronic concern. Again, I challenged them with the same question: "You've come up with a great list of ideas, but how will you ensure that you actually act on those the next time you are sprint planning?"
Both of these experiences reminded me of how difficult it is to break habits.
In his book The Power of Habit, Charles Duhigg has written about the three part neurological loop governing habits which was discovered by MIT researchers: a cue, a routine and a reward.
In the project team's case, the routine has been to accept more work items than they can complete in a sprint even when historical evidence shows this tactic hasn't worked out well. The cue is that moment in the sprint planning ceremony when the team makes their sprint forecast. It's hard to say what the reward has been but perhaps it's the temporary high which comes when we take on a significant challenge as a team.
To break habits, we need to find a way to substitute a different routine for the old one and soliciting the help of a close, trusted colleague might be one way to do this.
The team could designate a single individual to come to the sprint planning ceremony with a stuffed pig or some other visual gag which represents gluttony. Then, when the team is about to forecast how much they will accept in the sprint, that team member could hold up the pig and say "Oink! Oink!" to remind all of them to be a little more conservative. While the team might not bask in the short term glow of having accepted a bloated sprint forecast, they will enjoy the much more rewarding experience during their sprint review when the product owner and other stakeholders congratulate them for improving their predictability.
Breaking habits is hard to do but by identifying cues and implementing good routines to swap in for the old ones, we can prevail.