Many leaders have high expectations when starting an agile transformation. Just imitating what, e.g. the Scrum Guide describes, bears the risk of falling for cargo cult. The best way to meet the expectations management has, is to know where to invest your efforts and why. In the third part of this mini series we will review how to establish the culture required for a successful and sustainable agile transformation by adopting Scrum.
An often used blueprint for an agile transformation is to hire an Agile Consultant, or better yet Coach, do training with a selected group of people and then establish a pilot project in which the team executes the practices described in the Scrum Guide[1]. Then wash, rinse, repeat for additional teams. However, this approach bears the risk of introducing cargo cult[2] to the organization. To prevent mindless repetion of rituals, you need to be aware of the original intentions for the Scrum Events and Artifacts. By nurturing the culture that springs from living tha Agile Principles, you can then unleash its power to drive the further rollout of Scrum in the organization. Let’s dive right in and walk through a sprint start to finish, to map Scrum Events and Artifacts to principles and build that virtuos circle of mutual improvement.
- The Product Backlog
- Sprint Planning & Sprint Backlog
- Daily Scrum
- Sprint Review
- Scrum Retrospective
- Scrum Master
The Product Backlog
“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”[1]
The what is needed to improve in the product is also referred to as Product Backlog Items or PBIs. Also note that it is not a prioritized list, but an ordered list. That makes a huge difference. In traditional project management priority classes are assigned to requirements, in order to differentiate between high priority requirements, and less important requirements. (I heard rumors those exist.) There are many methods out there for prioritizing requirements: MoSCoW Prioritization[3], Brian Tracy’s ABCDE method[4], or the Eisenhower Matrix[5] as a variation of a priority matrix, just to name a few. They all describe different ways of defining these classes, or buckets for requirements. Unfortunately, these buckets are bottomless. As a result everything tends to be highest priority, because nobody likes to wait.
When you order your PBIs instead of categorizing them, you essentially achieve the same thing: prioritization. Only now, the size of the bucket is reduced to exactly one. In return you can have an unlimited number of buckets. (You shouldn’t, but you can.) That’s about all the Scrum Guide has to say about the Product Backlog.
Product Backlog in Scrum
A good practice in regards to PBIs is to only add as much detail as is needed at that time. So when a PBI is added, it may only be heading. Over time, while refining the PBI, more details will be added, PBIs might be split or hierarchies might be introduced. Ultimately a PBI has to provide sufficient detail so that the Developers can implement it in the product. This does not necessarily mean all details will be documented in the PBI. Another good practice is to use a lightweight format when documenting PBIs, such as User Stories.[6] A User Story is a reminder for the Product Owner and promise to the Developers to provide the required information when it is needed. User Stories don’t intend to capture and document everything, so that the PO no longer has to talk to the Developers. They rather are the invitation to a Face 2 Face Communication with the PO as a proxy for, or even better the domain experts themselves. In these meetings the Scrum Team learns from the domain experts about specifics of the domain. By representing these learnings as PBIs in the Backlog, the team Embraces Change. This is also one of biggest enablers in an agile transition. A backlog that is not frozen, but is instead continuously adapted to the needs of the product, is a key factor in practicing agile.
Developers
“Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”[1]
As a group they possess all skills and knowledge required to create and deliver increments of the product to the stakeholders.
The Product Owner
“The Product Owner is accountable for maximizing the value of the product resulting form the work of the Scrum Team.”[1]
The Product Owner is in charge of the state of the Product Backlog and the PBIs it contains. It’s their job to formulate and communicate the Product Goal. The Product Owner is also accountable for adding, refining, (re)ordering, and removing PBIs in the Product Backlog and making sure the Product Backlog is accessible. These tasks are generally referred to as backlog management. The role of the Product Owner is assumed by single person. The Product Owner may represent the interests of multiple stakeholders in the Product Backlog. Anybody who wants to change the backlog, must convince the Product Owner to do so. For a Product Owner to be successful, the organization must respect the decisions of the Product Owner. The Product Owner may delegate the work of doing these tasks, but cannot delegate the accountability for the product.
Many organzations underestimate the importance of this role and how demanding it is to fulfill. Choosing the right person for the job is crucial for success or failure of the product. When the PO is just a proxy without any decision making power or is not making any decisions out of fear of making the wrong decision, the Developers will be blocked a significant amount of time, awaiting the decision of the actual Product Owner. When the Product Owner is steering the product in the wrong direction by making bad decisions, the Developers can try to intervene and course correct by asking questions. But ultimately it’s the Product Owners responsibility to decide what is good or bad for the product. A successful Product Owner will act in Close Cooperation with all stakeholders.
Sprint Planning & Sprint Backlog
“Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.”[1]
During Sprint Planning, the Product Owner formulates the Sprint Goal stating what should be improved in the product when the sprint is completed. The Sprint Goal helps the Developers to focus their efforts and guides them should tradeoff decisions become necessary during the sprint. The Developers select the PBIs required to achieve the Sprint Goal, formulate a Sprint Plan and verify, using their estimates, if the amount of work can be completed in the alotted time. If they agree, The Developers commit to the Sprint Goal. Should the Developers think that they won’t be able to meet the Product Owner’s expectations, they need to negotiate a new Sprint Goal.
Sprint Planning & Sprint Backlog
Sprint Planning Meetings are Face 2 Face meetings, ideally bringing everybody in the same room. By formulating the Sprint Goal, the Product Owner sets the pace for the Developers. The Product Owner should keep in mind that a Constant Pace not only prevents burn out among the Developers, but also results in a more reliable base for estimates and projections. A challenging but achievable Sprint Goal will build Trust when the Developers deliver, while keeping the Developers Motivated. Due to the constrained time, the Developers will be forced to Keep it simple when formulating their Sprint Plan. Since Scrum defines a Sprint as a “[…] fixed length event of one month or less […]” at the end of which the Sprint Goal is reached, the Developers will Deliver frequent updates of the product for inspection.
Definition of Done
“The Definition of Done is a formal description of the state of an increment when it meets the quality measures required for the product.”[1].
As such, it represents another Trust building tool in the Scrum arsenal. All the items on the Definition of Done must be completed, respectively fulfilled, for a PBI to be considered done. Therefore, the Definition of Done helps to bring to life the Quality Mindset in the Developers. The Developers and the Product Owner might agree that some tasks that would be required to meet the quality measures for the product are excluded from the Definition of Done. This could be the case for e.g. integration tests which require the availability of a 3rd party system, that can’t be made available to the team to the required extent. Such tasks are referred to as unplanned work and the Product Owner and Developers must track for that to be completed before the product is released to the customers. The Definition of Done is different from Acceptance Criteria, in a way that the Definition of Done might state that the Acceptance Criteria have to be met, but would not describe them in detail. Since the Definition of Done describes the formal readiness, it can be applied to every PBI, while the Acceptance Criteria describe readiness criteriea specific to a single PBI.
Daily Scrum
“The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”[1]
It is a timeboxed meeting, limited to 15 minutes max, that is scheduled to happen at the same time on every working day of the sprint. The goal is to coordinate daily action plans so that the Developers can reach the Sprint Goal.
Daily Scrum
The Daily Scrum is the forum for the Developers to self-organize. It is not a status report to the Product Owner, or to be used by a line or project manager to micro manage the Developers. Any kind of external micro management would be a sign of dis-trust in the ability of the Developers to reach the Sprint Goal on their own. It would allow them to fallback into a disconnected not my fault, I only did what I was told-attitude, watching everything crash and burn. (Who brought the popcorn?) Giving the Developers the freedom to decide who will be working on which task, triggers their intrinsic Motivation to reach the Sprint Goal.
Sprint Review
“The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.”[1]
The Scrum Team presents the their results in a live demo to stakeholders and discusses the progress toward the Product Goal. Stakeholders review the accomplishments and provide insights about changes in the business domain. Together they collaborate on which updates to the Product Backlog are needed, in order to map the best possible path forward for the product. The Sprint Review is a timeboxed event of at maximum 4 hours for a one month sprint, less if the sprint is shorter.
Sprint Review
The Sprint Review is about delivering an update of the Working Product for the stakeholders and/or customers to inspect. Based on their feedback the Scrum Team adapts the Product Backlog. When the feedback is positive, the Scrum Team will be motivated to continue. When stakeholder constructively criticize and explain what needs to change and why, the Scrum Team will Embrace the Changes and still be motivated. It is however imperative for the motivational effect, that the Sprint Review is held in a respectful, psychologically safe environment. When people are scolded for trying new approaches, they will stop all active contribution and fall back into only doing what I’m told mode.
Increment
“An Increment is a concrete stepping stone towards the Product Goal.”[1]
Each item in the backlog represents at least one increment of the product. The Developers work on a backlog item to bring new functionality to the product. From a formal perspective, the work on a backlog item is only completed when it meets the Definition of Done. Increments can be delivered to stakeholders during the sprint review, or even before.
Sprint Retrospective
“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”[1]
The Scrum Team looks back on the Sprint they are about to close with respect to Individuals & Interactions, Processes & Tools and their Definition of Done and discusses what went well and where they see potential for improvement. They identify ways to move foreward and formulate action plans for how to quickly remove identified deficiancies. The Sprint Retrospective is also a timeboxed event of at maximum 3 hours for a month-long sprint, less if the sprint is shorter. The Sprint Retrospective closes the Sprint, the Scrum Team immediately starts the next Sprint with Sprint Planning.
Sprint Retrospective
The Sprint Retrospective fosters the Quality Mindset. The Scrum Team Inspects their way of working and Adapts where they find room for improvement to become more effective as a team.
Scrum Master
“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.”[1]
This is the role that coaches team members in self-management and cross-functional working, helps teams to focus on creating high value increments that fulfill the Definition of Done, assists in impediment removal when the impediments are beyond the teams circle of influence and ensures that all Scrum Events take place in a healthy atmosphere.
But that’s not all!
In addition to working with the Scrum Team as a whole, the Scrum Master also helps the Product Owner in finding techniques for effective Product Goal definition and Backlog Management, establishing empirical product planning and facilitating stakeholder collaboration.
Should you have thought that the Scrum Master’s plate was full by now, your wrong again. On top of all of the above, the Scrum Master serves the organization by leading, training and coaching Scrum adoption on an organizational level, planning and advising Scrum implementations within the organization, helping employees and stakeholders understand and enact an empirical approach for complex work, and removing barriers between stakeholders and Scrum Teams.
Real life Super Heroes? You bet they are.
What is it that Agile Coaches do? For one, they write blog posts like this one. Mostly, because Scrum Masters already have their hands full. Other than that, the biggest difference between an Agile Coach and a Scrum Master probably ist the form of employment. While Scrum Masters are often part of the organization they act in, Agile Coaches often are externals. They come in for a relatively short period of time (e.g. a few of months) and introduce some revolutionary change leveraging their external perspective. Together with the Scrum Masters they maybe map out a couple of strategies to lead the organization from the chaos resulting from the change to a new performance level before they leave. Working out the gritty details of implementing these strategies often falls to the Scrum Masters and Scrum Teams.
And now you know. Agile has permeated our business world to a point, where for many it has become the default behavior. As with other defaults, we tend to stop questioning why they are there. In order to reap benefits and find ways to keep improving, we need to stay alert and make concsious decisions. Don’t get lulled into doing Agile the way “it is done around here”. Prevent cargo cult by employing it’s arch enemy asking Why do we … . Whenever you get the feeling that progress is stalling, get in touch with an Agile Coach to get that external perspective that leads to the next leap in performance. Change the way you work to shape your organizational culture, so that it becomes the driving force of your strategic goals. One transition at a time.
Quellen
Christoph Murczek - works at iteratec as a passionate Product Owner and Scrum Master by conviction. He is the founder and main organizer of the Vienna Scrum Meetup, a forum for discussions about agile ways of working with more than 2.500 members from India to California, resp. Sweden to South Africa.