The Scrum Guide states that a sprint backlog "is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment."
We expect to find requirements, enhancements and even fixes in the sprint backlog, but is that it?
Remember that one of the three pillars of Scrum and a key principle of most agile approaches is transparency. Meaningful, significant work should be visible to all as agile doesn't encourage hidden factories. If we don't surface all major work being done by the team, it is understandable that a Product Owner or other stakeholders might assume that there isn't a lot of work being done in a sprint or that the team isn't being productive.
We can separate work which is worth being made visible into three broad categories:
By sizing, prioritizing and tracking work items across all three of these categories, a Product Owner and team will gain a complete understanding of what they expect to work on in a given sprint. This encourages healthy trade-off conversations during sprint planning and will help the team identify opportunities for improvement which might otherwise have been missed. For example, if some team members are spending significant effort in keeping build and test environments operational, the Product Owner or other stakeholders might be more inclined to understand why this is needed and what they can do to reduce that effort.
There is a fourth category which you may not want to include in the sprint backlog, and that's the activities performed by the team which are completely unrelated to the product or project. This could be year end employee performance assessments, town hall meetings, operational work or (hopefully not!) even supporting another project. Assuming team members have some insights into how much of their availability over the next sprint will be consumed by this unrelated work, they should communicate that to the rest of the team during sprint planning to ensure a reasonable sprint commitment is made.
So, with thanks to Capital One, what's in YOUR sprint backlog?
One of the benefits of living in the Greater Toronto Area is being less than an hour away from a large number of good wineries in the Niagara region. After visiting many wineries over 2018, I have come to the conclusion that wine tasting and agile have more in common than you might think.
It helps to have a guide
You could certainly partake in a flight of wine with friends without the benefit of a sommelier, but you won’t enjoy the experience as much and you might learn some bad habits such as not giving your wine a chance to breathe or drinking without sniffing the bouquet. Similarly a coach can help steer a team past anti-patterns so that they have a chance to appreciate what agility truly is.
Start small and grow from there
For novices, visiting more than one winery in a day could be a recipe for disaster. Without having developed the discipline to pace themselves they run the risk of getting tipsy too quickly and might get turned off by the experience. Starting with a large project is inadvisable for novice teams – they won’t possess the discipline to scale their behavior and practices and might blame agile rather than their immaturity.
There is no one right way
While there are good principles for enjoying wine, don’t let anyone try to convince you that you must follow pairing guidelines. While a robust red wine might be a good match for a meat dish, if you enjoy its flavour there is no reason you can’t have it with any other type of cuisine or even on its own. User stories are a good approach to starting a conversation about functional requirements, but don’t be bullied by agile wannabes who insist that all requirements must be captured as stories. Like with any practice, context and culture count.
Teams doing agile might make you want to drink but I prefer to have the perspective of the (wine) glass being half-full.
(Note: this article was originally decanted in June 2017 on kbondale.wordpress.com)
As we kickoff the final week of 2018, many of us will be making New Year's resolutions. While some of these resolutions might relate to achieving a specific goal or objective (e.g. I resolve to run a marathon this year), most relate to changing our behavior (e.g. I resolve to eat healthier this year).
But for many of us it becomes a case of déjà vu as we end up making the same resolutions we had confidently made in previous years.
Increasing organizational agility is a journey and not a one time goal.
Similar to New Year's resolutions, some delivery teams initiate plans to become agile only to revert to long ingrained habits when things get tough. It might not be on an annual basis, but companies which have struggled with agile transformations once will often try again and many will experience more than one failed attempt.
When it comes to personal resolutions and being able to stick to them the American Psychological Association's website provides some good advice which could be applied to agile transformations.
It might be tempting to pick the very largest product or project when starting an agile transformation to surface many key organization blockers and to glean some valuable lessons. However, the very visible impacts of potential failure as well as the higher volume of stakeholders whose behavior will need to change makes this extremely risky. Just as a casual runner shouldn't try to run a marathon in their very first month, starting with too ambitious a set of pilot initiatives is usually a recipe for disaster.
Change one behavior at a time
There are multiple behaviors which leaders and team members might need to modify and trying to change all of those at one time is like a golfer who tries to keep multiple swing thoughts in their head when addressing the ball. Usually they will end up with a worse swing than if they had just cleared their mind of all thoughts! A transformation team should identify which behavior change might result in the biggest impact and that should become the focus of coaching and peer support.
Talk about it
To succeed with any significant organizational change we need to over-communicate. The more we can talk with stakeholders about our target operating model, the challenges we will face to get there, and the small wins we are achieving, the more we will remain committed to the journey.
Don't beat yourself up
No agile transformation is going to go smoothly. Some initiatives might turn out worse than if a traditional approach had been used. Some staff will leave the organization. As the APA website states "Perfection is unattainable". But as long as we have support mechanisms in place and a desire to get better, we can bounce back from such setbacks which are usually minor when viewed from the perspective of an end-to-end transformation timeline.
Ask for support
Every organization has a unique culture, but it can be easier to stick to an increased agility resolution when you have support from those who have been there and done that. The value of external support comes from the breadth and depth of experience to know which patterns of behavior or practice are likely to lead to success and which won't.
Adapting the quote from Dr. Lynn Bufka "Remember, it is not the extent of the change that matters, but rather the act of recognizing that
I'm midway through Nassim Taleb's latest book, Skin in the Game: Hidden Asymmetries in Daily Life. As is usual with Taleb's writing, he provides thorough but humorous coverage of a concept which can be applied to many contexts. The premise of this book is that without skin in the game, asymmetries emerge which encourage unfairness, poor decision making and can contribute to a lack of understanding of realities.
One of the key principles discussed in the book is that there should be a negative incentive or cost to decision makers when things go wrong. Without this, we have an asymmetry since risks get transferred away from those who should have been held responsible. A common example of this is seen in companies where sales teams are compensated for initial sales but are not held accountable to some degree for customer satisfaction beyond the point of purchase. This can encourage salespeople to over-promise with inevitable expectation shortfalls. Another highly publicized example is that of the financial company executives who were never jailed for poor decision making which led to the 2008 financial crisis.
This principle can also be applied to some project teams.
There are industries such as large scale construction where the cost of poor quality in extreme cases (e.g. a bridge collapse) will result in punitive consequences to the engineers who were involved. However, in other domains such as software development for internal use where deadlines may be emphasized higher than product quality, there is no such downside. The teams who delivered the buggy release will have likely disbanded and the team members will have moved on to different departments or projects before the real cost of ownership is understood by the business owners.
On the other hand, when there is a product-centric model delivered by long-lived teams, there's greater skin in the game. Escaped defects are no longer the responsibility of an operational group or some future project team. Quality issues will come home to roost in the delivery team's backlog and the Product Owner has an incentive to focus on improved quality if he or she doesn't want to have ongoing uncomfortable stakeholder interactions.
Taleb also states that skin in the game supports the principle of survival of the fittest. Product Owners or teams which consistently miss the mark with their releases are unlikely to be around for long in product-centric contexts whereas in project-centric organizations, it may be easier for individual mediocrity to fester if there isn't ongoing vigilance.
"Skin in the game prevents systems from rotting" - Nassim Taleb
How effective are your agile ceremonies?
We hope that by conducting effective ceremonies we will achieve the agile trinity of improved value delivery, better quality and more fun.
But these objectives might be reached via multiple paths so we might not be able to prove causality between our ceremonies and those objectives.
We could ask our team members to tell us whether they see the value in the ceremonies and their perceptions are certainly important but is that enough? Can we identify measures which we could directly attribute to specific ceremonies so that we know if they are generating sufficient value?
Each agile framework provides its own ceremonies but given that Scrum is still the most commonly referenced one, let's focus on that framework's events.
The Scrum Guide calls sprints the heart of Scrum as these time boxes set the cadence for all other events. But to know if the Scrum heart is healthy we could track achievement of goals and value delivered sprint-over-sprint.
Sprint planning should answer the "what" and "how" of delivery for an upcoming sprint. Measuring its duration, quantifying the variation between what was expected to be delivered and what was actually delivered, and confirming whether the team is working at a sustainable pace might help assess the ceremony's effectiveness.
The daily scrum helps the team align themselves towards the accomplishment of sprint goals and to collaborate better. It should also reduce bad surprises and the need for traditional status meetings. To see if it is adding value, we could check how many work items are completed and measure how many unanticipated impediments are encountered each day.
The sprint review provides an opportunity to inspect what was accomplished and adapt the backlog accordingly. We can measure how many new requirements and course corrections emerged from the discussions. We could also conduct regular surveys with key participating stakeholders to gauge their satisfaction with the product and with the team.
Finally we come to the sprint retrospective. To gauge whether this ceremony is more than just a frequent "lessons learned" session, we could track the ratio of improvement ideas generated compared with how many were actually executed and provided expected benefits.
Agile ceremonies should add value. If not, we are just adopting the form of agility with none of its substance.