Continuing the Agile series, I'd like to turn over to demos and retrospectives.
Let's start with the latter, as it's the most politically charged of all Agile ceremonies. If you have not been to many of those, you might be wondering why. After all, isn't it just a short meeting to look back as a team on the sprint and see what we did well, suggest what we can improve, and then move on?
To explain myself, I need to become a bit philosophical. Scrum, and other "collectivist" team methodologies, have a sharp contrast to the many individualistic attributes of the IT career. Namely, it's not teams who get annual reviews, promotions, salary raises and bonuses - people do.
Even the most altruistic IT professional cannot abstract him/herself from that: they can work within a team as well as anyone else, but at the end of the day they know it's for their personal contribution and their skillset that they are being paid for.
So, whenever we come to a meeting and ask the question "Did we do well?", each engineer inevitably, inaudibly, also asks the question: "Have I done well?". If the answers to these questions are different, especially if the first one is a "No" and the second one is a "Yes", then the meeting may backfire.
Of course, in an idealistic world, it's only the team that matters. In football, it does not matter in theory when a midfielder has played well, yet the team has lost 0-3. (In practice, it does matter to a degree since there are scouts and reviewers out there who would still single him out.)
Then, maybe you might say that there is no way these two questions can be answered differently.
In real world, however, sprints partially fail more often due to technical gaps and oversights than processes. Developer X is working on project Y, and greatly underestimated the task complexity. Engineer A has let defect B into production causing disruption to deployment. Mistakes happen - this is all part of the job.
Moreover, sometimes A, B, X and Y all happen at the same time, but somewhere in the corner of the room sits person Z who has done nothing wrong and who maybe worked 8 AM - 7PM throughout the sprint completing both their and others' tasks and amortising some of the impact. This person needs a reward - not a rant.
In short, retrospective is great for process adjustments, but many sprints go south because of purely technical or personal issues, and in my opinion an Agile ceremony is not the best place to solve those.
With all of that, I tend to make retrospectives optional, and use them when there is a process, rather than personal, improvement to be made. This happens of course, but not in each and every sprint. In fact, if we modified the processes in each of the 120-odd sprints in my career, then our process would have been lack thereof.
Now, let's move on to the subject of demos. For me, the one and main purpose of demos is that they need to be interesting. Not comprehensive, not formal, not long or short - just interesting.
The real acceptance and validation happens during the sprint when tasks get completed, and someone who understand those tasks well (QA Engineer, Product Manager, Product Owner etc.) validates them in depth. Demos are more about sharing, getting visibility and celebrating success.
This is all good and fine when there is UI involved, but when a team develops micro-services, extends APIs, deploys load balancers, or optimises a Web service, making a subject interesting becomes more challenging.
Of course, for the right person, seeing a new port being taken by a service and a sample request on APIv2 triggering a HelloWorld response is exciting. Unfortunately, not all of us were born this way, so keeping interest is not easy.
Another dilemma inevitably pops up towards the end of the sprint's last week. Since demos tend to include the entire department, it's not something we should cut corners on; if we did, they won't be interestingTM.
This, in turn, means that we spend effort specifically on the demo: set up environment, prepare slide deck, get notes in order etc. By Murphy's law, this comes a time where customers and Technical Support breathe down our collective neck, while the test/demo environment is doing its best impression of a yo-yo as far as stability goes.
Hence, my ideal approach is:
- Identify in advance what we want to demo. Think whether the target audience (i.e. other engineers) will care about this.
- Allocate time (again, in advance) to get the environment ready.
- Use demos as a visibility / celebration opportunity, not acceptance criteria.
- Explain the business need behind each feature.
- Call out future plans.
- Ask difficult questions when someone else demos - let them feel loved. If demo goes by without a single question, then it almost certainly was just a tickbox.
Let's take my long-running Multimedia player tasks from previous posts, assume we just completed them, and apply these principles:
Integrate Chinese UI localisation provided by an external agency - Yes, do a demo. Highly visible, and gives a ton of creative chances to show off.
Enhance skin support for more customisation - Only if we have a sample skin implementation visualising the new features (we should, but it might be a separate follow on task that's not ready yet).
Address 3 visual defects - Do not demo. Too minor, and not very interesting.
Support two more codecs - Yes, do a demo: especially if we can dig out a nice movie clip with one of these codecs. Visible, and can appeal to engineers: we can even prepare a slide deck with features and specifics of these codecs, and explain how we will gain market share because of their support.
Prepare high-level effort estimate for porting to the MacOS platform - Do not demo. Wait until we actually have the MacOS platform supported.
As usual, I've strayed a bit from the classic sprint review recipe. Again, as usual, this is not because recipes are wrong, but because adapting them to various situations and teams is what managers do.
In the next post in these series I talk a bit about reconciling long-term planning and the dynamic nature of sprints.
No comments :
Post a Comment