Although subtle, having a public retrospective can do terrible damage to a Scrum team. In this video I explain what I mean by “public”, why it is so bad, and what you should do instead. This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices. I will follow-up this video in several weeks with a written article complimentary to this video. Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!
The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?). One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word. I have posted a response. I strongly believe that the word “commitment” is the right word. Here’s the first paragraph of my response:
Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.
A long time ago I had a really good friend….
Check out all the discussion on the five values of Scrum and please comment or vote (or both!)
Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it. From the article:
If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.
Please, for the sake of your team(s)….
When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!
Stakeholders are people too. They don’t want to let the team down either.
Mike has great experience working with Scrum teams and I hope you read through his other articles as well.
The Sprint Review meeting supports the Scrum value of Openness and the principle of inspect and adapt. This rule of Scrum also aligns with the Agile Manifesto principles “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” and “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members and effective communication of feedback from stakeholders reviewing the product increment. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership. The successful delivery of the valuable software requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and inspect and adapt will lack effectiveness.
The Product Backlog is a list of potential work to be done for future Sprints. This list is most vibrant when as many people as possible contribute to it. Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value. Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome. Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision). If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost. Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.
The ScrumMaster organizes and facilitates the Scrum meetings, including the Sprint Review. The ScrumMaster ensures that all the stakeholders of the Scrum Team and its product are invited to the Sprint Review. The list of stakeholders invited should include, most importantly, end users of the product and / or actual external customers who would buy the product. The Scrum Team presents the product increment during the demo portion of the Sprint Review. This presentation allows the stakeholders to give immediate feedback on the product increment including new functionality, quality, and desired future direction. If the stakeholders are not universally invited, then it is possible that important feedback will be lacking and the Product Owner will create a sub-optimal Product Backlog. One significant benefit of having a broad group of stakeholders attend is that it is highly motivating to the Scrum Team to receive direct feedback every Sprint. This feedback is only possible if all the stakeholders are invited every Sprint.
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
This is my first post on the Agile Advice blog. In fact, it’s my first blog post ever. Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile. After all, my background is marketing, community relations, and sustainability! Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.
The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.
As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.
Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.
I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.
David D. Parker
VP Marketing and Sustainability
Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning – disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment – opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders – engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control – mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change – processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?