A colleague of mine, Robin Dymond, posted this great video about Scrum and healthcare.gov on Youtube. It is a fantastic summary of Scrum and is well worth the 20 minutes to watch.
Agile methods and the culture behind them focus on teamwork, safe environments, motivation, technical excellence and lots of other things that are easy when business is good. But when business is bad, and you simply can’t afford to keep everyone around, what do you do?
… UPDATE …
Interesting: this tiny post has generated a lot of traffic… but no responses. Please feel free to offer suggestions or ideas or questions in the comments.
The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.
I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.
The Scrum Guide recognizes the following inputs to Sprint Planning:
A newly-formed team often needs to address the following before the first Sprint:
If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).
Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.
Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).
This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.
In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.
Organizations like to have clear role definitions, clear processes outlined and clear documentation templates. It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect. ScrumMasters should be anti-bureaucracy. Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.
To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).
– Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing. These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
– Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams. Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed. Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks. This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).
NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents
The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach. There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.
So you’re trying to do Scrum well because you heard it gave you great results. You know that the ScrumMaster role is critical. How do you find the right people to fill that role? Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters. From Worst to Best:
The ScrumMaster creates high performance teams using the Scrum process and values. The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance. The ScrumMaster is responsible for removing obstacles to a team’s performance of their work. The ScrumMaster is an organizational change agent.
Other things you might want to consider when looking for a ScrumMaster:
Bottom line: try and avoid having PMI-trained project managers become ScrumMasters. Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.
Great article about goals and how they might not actually be as important as we have all believed for so long. Does this also apply to Agile teams? The article is focused on individual goals and processes rather than team or organizational goals. I’d love to hear if anyone has experience with this!
The ScrumMaster is responsible for ensuring the correct use of the Scrum process. Because the ScrumMaster is usually the most well read on Scrum, always trying to improve the team’s understanding of Scrum, facilitating the Scrum meetings, and developing new ways to develop relationships and structures that allow Scrum to thrive, he is the most able to guide the team in its use of Scrum. This authority holds within the Scrum Team where the ScrumMaster is a member and overrides any external authority as applied to that team. However, this does not mean that the ScrumMaster becomes a guru that withholds learning and understanding and guards it as if it is a treasured jewel. Instead, it is also the responsibility of the ScrumMaster to enable understanding, learning, and action so that the team advances together. Having this authority allows the ScrumMaster to stop any argument about the Scrum process, and ensure that the team is focused on action. If the ScrumMaster does not have final authority on the correct way to use the Scrum process, it is very likely that the Scrum Team will flounder, argue, and limit the progress of the team by not continually improving how they use and interact with the elements of Scrum.
To learn more about the correct way to use the Scrum process, visit the Scrum Team Assessment.
Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
A few weeks ago, David Parker and I had a conversation about some of the differences between Scrum and OpenAgile. We hit upon one really interesting thing: Scrum strongly emphasizes that it is a purely empirical approach to doing work… and OpenAgile does not make that claim. In fact, OpenAgile, while it includes empiricism, is definitely not an empirical process framework.
Ken Schwaber has long been adamant about empiricism with his phrase “Inspect and Adapt” which is the core of Scrum. All the artifacts, meetings and roles of Scrum are meant to be supportive of the inspect and adapt approach in a product development environment. A Scrum self-organizing team inspects and adapts on the product it is building. It inspects and adapts on the obstacles that arise as it does its work. It inspects and adapts on all the organizational processes, technical tools, team dynamics,… everything! This is Good.
But Scrum, in its pure empiricism, also lacks something.
OpenAgile has components of Scrum’s empiricism. Certainly, OpenAgile owes a great deal to Scrum. The concept of “Systematic Learning”, one of the foundations of OpenAgile, is similar to Scrum’s empirical framework. The process structure of OpenAgile is also similar to that of Scrum with short cycles of work delivering value on a regular basis. The main difference comes from a simple concept: Guidance.
In OpenAgile, guidance is a critical component of systematic learning. Guidance allows someone outside the team to intervene. This might be a manager, a stakeholder, a family member… anyone who sees things from an “outside” perspective. It might also be someone within the team pulling in guidance: asking for advice, doing a web search, reading a book, or even meditating in the hope of inspiration.
In Scrum, there are some very strong boundaries around outsiders providing guidance. No changes mid-sprint. All requests for work go through the Team’s Product Owner. The ScrumMaster “protects” the team from outside interruptions. “Chickens” cannot participate in the Daily Scrum. The team self-organizes with individuals volunteering for specific tasks. Team members discard all organizational titles when working within a Scrum team. All of these boundaries support a pure empirical approach to working. They also provide a form of safety for the team. This safety is deemed necessary with the implication that stuff from outside the team is dangerous.
In OpenAgile, guidance comes to the team through the conduit of love. Yes… love.
The team develops a love for its work. This love then opens the team members to guidance. Think of the opposite: if I hate my work, I’m not likely to be interested in taking any advice about how to do it better. If I love my work, I will always be seeking ways to improve it.
Of course, love is not binary. It’s not on or off. In that continuum, the more an OpenAgile team loves its work, the more receptive it will be to guidance. The more receptive to guidance, the more sources of guidance will be “safe”. And the less reliance on pure empiricism will be necessary.
Let’s be frank: pure empiricism, in its most extreme form, means that Scrum teams would re-invent things that may have already been invented many times before. In the Scrum community, the most obvious example of this is the Agile engineering practices that come from Extreme Programming. Scrum teams seem remarkably resistant to adopting these practices at the outset… despite the fact that eventually most Scrum teams working in software succeed or fail based on their eventual adoption of these practices. Scrum teams are often left without the guidance that XP practices can help them. Instead Scrum teams seem expected to re-discover XP practices on their own.
For what it’s worth, I don’t think that Scrum is fatally flawed. In fact, I think that in some environments, where teams truly are unsafe, where people tend to hate their work, where dysfunctional bureaucracy is deeply embedded in the organizations culture… in these environments Scrum is actually the right place to start. Scrum is great for product development in high-crisis situations: save your product with Scrum!
OpenAgile, by accepting guidance into its framework, allows teams to progress rapidly when they can leverage other people’s learning. Scrum does not dis-allow this, but it sets up an environment where the team culture tends towards the “Not Invented Here” syndrome. OpenAgile puts teams on the other path: the path of allowing for greater and greater learning from others.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
|Cycle Planning||Sprint Planning and Sprint Review|
|Team Member||Team Member or “Pigs”|
|Growth Facilitator||Product Owner|
|Work Queue||Product Backlog|
|Work Queue Item||Product Backlog Item|
|Cycle Plan||Sprint Backlog|
|Progress Meeting||Daily Scrum|
|Learning Circle w/ steps||“Inspect and Adapt”|
|Delivered Value||Potentially Shippable Software|
|Five Types of Work:
New, Repetitive, Obstacles, Calendar,
|- no equivalents -
User Stories, N/A, Impediments, N/A, N/A
|Consultative Decision Making||- no equivalents -|
|Sector / Community||- no equivalents -|
References on OpenAgile:
References on Scrum:
“Agile Software Development with Scrum” – Schwaber and Beedle
“Agile Project Management with Scrum” – Schwaber
“Scrum and the Enterprise” – Schwaber
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
All credit for this is due to Mary Poppendieck as this is entirely cribbed from her Agile2007 talk on agile leadership.
A man walks into a quarry and sees three people with pickaxes. He walks up to the first one and asks, “What are you doing?” The first quarry worker irritably replies, “I’m cutting stone, what does it look like? I cut stone today, I cut stone yesterday, and I will cut stone tomorrow!” The man asks the same of the second person who replies, “I’m making a living for my family.” The man turns to the third person and asks him, “so what are you doing here?” The third worker looks up for a moment, looks back at the man with a proud expression and says, “I’m building a Cathedral!”
The moral of the parable is likely clear, but it bears applying to organizational dynamics. Basically, consider that everyone gets annoyed with aspects of their jobs. The question is one of response. Basically, if a person is annoyed with his job, does he:
Cathedral builders are absolutely critical to a healthy organization. They push the organization towards a vision, often propagating the high-level vision throughout all levels of the organization. Unfortunately, these are also people who annoy the stonecutters and paycheque earners, because they won’t participate in the complaints, and they agitate for changes which make it hard to ignore things and just “do the job.” But your success will rely on them… find them, shelter them, and grow them. And whatever you do, don’t “promote” them into positions where they aren’t effective. Empower them, and if you need to add salary and title that’s fine, but let them find their own area of maximal contribution. Guaranteed you, Mr. business owner, aren’t smart enough to see what that is.
Organizations that fail to see this remain mediocre or failing organizations. Organizations that find ways of harnessing their workforce and coaxing people into the next level of engagement, succeed.
The fact that agile methods increase return on investment, accelerate learning, increase stakeholder satisfaction, and enable better control of work are all an interesting result of this final benefit: responding to change.
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.