A deeper understanding on…
As we’ve been running through this series we’ve been developing a deeper understanding of Scrum. Jeff and Ken have been somewhat mischievous in mentioning that Scrum is ‘simple to understand’ in the introduction of the Scrum Guide. They emphasise the importance of having a common language shared by all. We’ve been chewing through definitions like framework, empiricism, transparency and next served are artifacts. The Scrum Guide is perhaps infamous for its linguistic magic.
Definition of ‘Artifact’
I learned that we don’t all share the same understanding of this term. Sometimes we can’t even agree on whether it’s ‘artefact’ or ‘artifact’. When I ask people what they think an artifact is, they generally tell me its an ancient/old excavated object.
The term originates from the latin “arte” (thing crafted) “factum” (by skill). Something could be also referred to as ‘artificial’.
In Software Development, artifacts are by-products created during software development. These are generally specifications, models/diagrams, test scripts, designs, prototypes and metrics. Some will refer to artifacts as surviving ‘legacy’ documents. They generally describe a historical desired to-be state of something that by then has already evolved. Therefore they are no longer all that reliable as these documents are rarely kept in a transparent state. They can be the source of a lot of waste and confusion when they continue to be used as a source for ongoing development. But as they no longer reflect the as-is state of the actual product, it results in all sorts of wasteful malalignments, misconfigurations and miscommunications.
By-products and Make-work
It’s all this bureaucratic madness that gave rise to the numerous alternative approaches to software development. The ever growing popularity of both the Scrum Framework and the Agile Manifesto are a testimony to this.
Many (software) development agencies work project based with a contractually agreed fixed number of hours to be spend on it. So one might argue that the more is spent on creating by-products, the less is being spent on crafting the actual product. With Waterfall, often half (if not more) of the project’s timebox has expired before the actual product starts emerging.
“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies.” — History: The Agile Manifesto
Many organisations have all sorts of ‘dilbertesque’ rituals. In the office we comfortably participate in all sorts of rituals and contribute happily to the development of by-products. We’ve come to value them. It makes us appear productive after all. We are providing valuable contributions; or so we all like to think. Many have come to value their individual ‘conveyor belt’ position along the Waterfall production line.
Likewise many have come to value their ‘white collar’ positions (being clerical, administrative and managerial) over those doing craft or service work, which traditionally ‘enjoy’ a lower salary and intellectual esteem.
Over decades we learned to value conceptual thinking/designing over creative and crafty production work. In many countries the educational system aligns to this. Sigh.
Naturally we don’t consider ourselves to be massive time wasters. ‘Oh we’re so busy’ and we like to show it. Our agendas are overbooked, our inboxes swamped, our backlogs… endless. Being (or appearing) busy appears to be priority number one in the workspace.
Now with Scrum, like Kaizen we continuously change for the better. We create visibility over the way we work so together we can inspect the way we operate to try and improve overall efficiency. Counter to our intuition, this effort mainly revolves around the principle of simplicity: “the art of maximizing the amount of work not done”.
Now all this is not to say that producing artifacts isn’t valuable, in fact it generally is.
“We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.” — History: The Agile Manifesto
Agilists might reject Scrum’s artifacts for being what they are. However, those who are actually serious about reducing wasteful artifacts, could (ironically) embrace Scrum’s artifacts. They should serve to eliminate waste and act as containers that creates transparency.
“Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.” — The Scrum Guide
The Scrum Framework contains three artifacts:
- Product Backlog — An ordered, single source list of everything that is known to be needed in the product.
- Sprint Backlog — The Sprint Backlog contains the Forecast, plus a plan for delivering the product Increment and realizing the Sprint Goal.
- Increment — The sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
Now, Scrum is a framework, we established that. All its components support each other. There aren’t all that many, it’s a lightweight framework after-all. The roles, events and artifacts will only truly be effective when they reinforce each other. Try to take anything out, and the whole system (which is your organisation) is likely to become unstable.
One of the reasons why a Scrum Master is a pivotal role, and, in my opinion one that should spend a fair amount of time collaborating and working with the team, is due to the following responsibility:
“A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.” — The Scrum Guide
Scrum dedicates another role to ensure that the Product Backlog is well tended to. The Product Owner is responsible for:
“Ensuring that the Product Backlog is visible, transparent, and clear to all” — The Scrum Guide
We also learned who is responsible for the state of the Sprint Backlog:
“The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.” — The Scrum Guide
Definitions of Done
Definitions of Done help to create transparency over the artifacts. They are needed to keep them in shipshape condition. The Definitions of Done and practises used to get Product Backlog Items in a ready state I will cover in more detail further down this series.
Transparency, Openness, Visibility, Accessibility.
Now, these terms might scare the begeebers out of anyone concerned with data security/data protection and such. Though visibility and accessibility might contribute to transparency, it is not to say that artifacts have to be visible and accessible to everyone in order for them to be transparent. These nuances matter. Teams will learn and adapt what levels of visibility, openness, and accessibility work best to run production smoothly yet securely.
Now with Scrum, it is paramount that everyone shares the same understanding of the artifacts in play. They are there to create transparency over (potential) value, complexity, and the use of the actual product. When their state is abysmal, stability, and reliability plunges. The ability to make decisions effectively deteriorates. Value goes down the drain.
Scrum Artifacts are living documents. All Scrum events are purposed to ensure the artifacts are well tended to. In addition to these, the Scrum Guide explains that Scrum Teams generally spend 10% of a Sprint refining the Product Backlog. These events (and Backlog Refinement) I will cover continuing this series.
Scrum Teams are mastering the art of being factual. Monitoring progress in Scrum is primarily done through direct inspection of the actual Increment. Sprint Reviews serve to monitor progress towards Sprint Goals. During these reviews, progress becomes transparent to Stakeholders.
The Development team monitors progress only to project the likelihood of achieving the Sprint Goal so they can adapt accordingly throughout the Sprint. They likewise do this by making actual progress on the increment transparent to each other on a daily basis.
Although Scrum Teams may engage in other projective practices, like Burn-Up/Down charts, the use of these should not replace the need to inspect the actual progress of actual work. Let’s be honest, they generally end up doing that, resulting in decisions being made based solely on a mirage.
Many might frown upon Scrum’s lightweight Framework at first.
Quite frankly, the Agile approaches scare corporate bureaucrats — at least those that are happy pushing process for process’ sake versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” — because they run out of places to hide. — History: The Agile Manifesto
I‘ll go ahead and categorise my younger professional self to be one of those corporate bureaucrats who ran out of places to hide. Personally, coming from a background in software and business architecture, I used to (and secretly still do, shhhhh) love chewing through and spitting up all sorts of artifacts. Calmly running through and munching all the chewy stuff is relaxing. This might be the case for you too, having come this far into the series.
Scrum is something to experience. I now value Scrum’s artifacts so much; I could hardly imagine myself doing without.
“Transparency doesn’t occur overnight, but is a path.” — The Scrum Guide
Thanks for staying tuned.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.