Here's a short overview (2 minutes) video of the VoltDB Development Process, our use of Scrum and our strong Definition of Done (DOD).
I had fun working with VoltDB marketing to make this video, an thanks to my team for pitching in!
Showing posts with label done. Show all posts
Showing posts with label done. Show all posts
Monday, July 14, 2014
Wednesday, April 27, 2011
Multi-tasking Mayhem
One of Scrum’s rules pertains to the purpose of each Sprint, which is to deliver increments of potentially shippable functionality that adheres to a working definition of “done.”
Scrum Guide: http://www.scrum.org/scrumguideenglish/
A few weeks ago I was part of a small team creating an Agile training course for our Product Group. The one-week time-boxed effort was broken into 5 one-day Sprints - we were going to eat our own dogfood and create the course using the Scrum framework. For our second Sprint, day 2, I volunteered to implement a couple fairly involved stories from our backlog, each requiring me to create a dozen or so slides with associated training notes. A accomplished multitasker, I dove into the effort, working on both stories concurrently. Late afternoon I suddenly found myself in the final hour of the Sprint with both stories more than half complete, but neither story Done! A bit of panic set in as I contemplated my mistake: if I had worked on the deliverables sequentially, I’d have easily completed at least one Story, come Sprint review time. As it stood then, I might not have anything done. I felt momentarily paralyzed by my situation and realized that I’d have to put in extra effort to get the work done in time. I also realized I had a great topic for my next blog, so all was not lost!
The ability to multitask is often viewed in the workplace as a positive skill: the ability to juggle and deliver multiple competing priorities in an increasingly complex and dynamic business environment. However, numerous studies have shown that multitasking only gives the illusion of enhanced productivity, when in actual fact, working on more than one task at the same time often results in less actual productivity! According to Psychology Today “the mind slows down when it switches back and forth between tasks”. Each time you switch to a new task you must gain context on the new task while losing some context on the task you left behind. A Stanford study suggests that when you are switching between multiple tasks, you “couldn't help thinking about the task [you] weren't doing”, leading to a further drop in productivity.
My take-away from this is two-fold:
- Teams (and individuals) should work on one story/task at a time and deliver on stories sequentially. The prioritized Product Backlog and Sprint Backlog should is the artifact that focuses the Team.
- Management should respect the Team commitment (of course!), keep team members 100% dedicated to the Sprint and do whatever necessary to eliminate competing priorities. When competing work is discovered, the work should be added to the Product Backlog and prioritized by the Product Owner.
Focusing one one story and completing that work before moving on to the next, Scrum teams (as well as individuals) will deliver more work. Sometimes you have to go “slow” to go fast.
Wednesday, January 12, 2011
What does “Done” mean?
It starts with a team conversation...
One of my favorite team conversations that generated by the Scrum framework is one that occurs at the beginning of a Scrum project. It’s the team discussion and subsequent agreement of what the word “Done” means.
A Scrum Team is supposed to produce potentially shippable code at the end of every Sprint. This means that any stories (requirements) that the team commits to must be full implemented, documented, tested, etc within the time-boxed Sprint. The stories must be DONE. Done can and often is defined differently by each team. Minimally, Done means that the story committed to is coded and fully tested. A story really can’t be potentially shippable if it isn’t coded and tested.
Done is demonstrated during the Sprint Review, where working code is demonstrated the business owners and everyone else in attendance. A story isn’t complete unless it satisfies the definition of “done”. In fact, Scrum will not credit the team with story points unless a story is, in fact, “done” (and accepted by the Product Owner).
Each Pilot team that I observed went through similar discussions about “done”. Because Scrum was new to the teams, the initial definition of “Done” was a bit loose: there was general agreement that a story was “Done” if it was coded and tested. Over the course of the first Sprint Planning and the start of the Sprint 1, it often became apparent how loose that definition of Done actually was.
The Product Owner and Team conversation for story acceptance criteria was one of the main catalysts for Done refinement. As each member of the cross-functional team discussed the stories they were committing to, it was quickly realized that the initial definition of done left many questions unanswered. Product areas such as documentation (what kind? what level?), training (again, what kind?), automated tests (how much should be automated? what platforms should be tested? what web browser? what about performance testing?) and bugs (should all be fixed? just blockers? more than just blockers?) all had questions that needed answers.
Over the period of a month or so, the teams each refined the meaning of Done. The process of discussing, debating, and ultimately answering these questions helped the group grow into a high performance team. This was very important to the success of the effort, as with Scrum the commitment to delivering a story is a team commitment, rather than an individual one.
A Great Habit
I think most would agree that it’s great to get in the habit of fully completing work, versus completing 80% of the work and leaving the remaining 20% for some time “later”, during the release end-game, or perhaps never (thereby wasting effort). With Scrum, producing done work is essential to the process. In the pilots, I’ve noticed a tendency for teams to commit to too many story points during a Sprint, ultimately leaving one or two stories partially finished, though the team put in often heroic effort to meet the original commitment. The unfinished stories were fortunately completed in the next sprint, but the fact that they were not complete often defeated the “potential” from the potentially shippable product. One way to deal with this is for the team to sequentially complete stories within the sprint, never starting a new story until the current story is Done. This isn’t always practical, or efficient, but the team should be aware of the story bleed and velocity drag that partially implemented stories create. Alternately, it is perhaps better to commit to fewer story points per sprint and fill in any capacity with product maintenance or backlog grooming or architectural spikes. These are team decisions that can be considered during Sprint Planning or during the Sprint Retrospective.
Agility
For me, the concept of Done is the key foundational principal that makes Scrum agile. At the end of a Sprint all stories are fully completed, thus potentially shippable. This fact, coupled with a short development iteration, offers the business frequent predictable time windows in which to re-prioritize work or introducing completely new requirements. Scrum allows an organization frequent opportunities to, in contemporary terms, pivot. Easily and readily shifting priorities with minimal impact to productivity is one of the primary mechanisms through which an engineering organization gains agility.
One of my favorite team conversations that generated by the Scrum framework is one that occurs at the beginning of a Scrum project. It’s the team discussion and subsequent agreement of what the word “Done” means.
A Scrum Team is supposed to produce potentially shippable code at the end of every Sprint. This means that any stories (requirements) that the team commits to must be full implemented, documented, tested, etc within the time-boxed Sprint. The stories must be DONE. Done can and often is defined differently by each team. Minimally, Done means that the story committed to is coded and fully tested. A story really can’t be potentially shippable if it isn’t coded and tested.
Done is demonstrated during the Sprint Review, where working code is demonstrated the business owners and everyone else in attendance. A story isn’t complete unless it satisfies the definition of “done”. In fact, Scrum will not credit the team with story points unless a story is, in fact, “done” (and accepted by the Product Owner).
Each Pilot team that I observed went through similar discussions about “done”. Because Scrum was new to the teams, the initial definition of “Done” was a bit loose: there was general agreement that a story was “Done” if it was coded and tested. Over the course of the first Sprint Planning and the start of the Sprint 1, it often became apparent how loose that definition of Done actually was.
The Product Owner and Team conversation for story acceptance criteria was one of the main catalysts for Done refinement. As each member of the cross-functional team discussed the stories they were committing to, it was quickly realized that the initial definition of done left many questions unanswered. Product areas such as documentation (what kind? what level?), training (again, what kind?), automated tests (how much should be automated? what platforms should be tested? what web browser? what about performance testing?) and bugs (should all be fixed? just blockers? more than just blockers?) all had questions that needed answers.
Over the period of a month or so, the teams each refined the meaning of Done. The process of discussing, debating, and ultimately answering these questions helped the group grow into a high performance team. This was very important to the success of the effort, as with Scrum the commitment to delivering a story is a team commitment, rather than an individual one.
A Great Habit
I think most would agree that it’s great to get in the habit of fully completing work, versus completing 80% of the work and leaving the remaining 20% for some time “later”, during the release end-game, or perhaps never (thereby wasting effort). With Scrum, producing done work is essential to the process. In the pilots, I’ve noticed a tendency for teams to commit to too many story points during a Sprint, ultimately leaving one or two stories partially finished, though the team put in often heroic effort to meet the original commitment. The unfinished stories were fortunately completed in the next sprint, but the fact that they were not complete often defeated the “potential” from the potentially shippable product. One way to deal with this is for the team to sequentially complete stories within the sprint, never starting a new story until the current story is Done. This isn’t always practical, or efficient, but the team should be aware of the story bleed and velocity drag that partially implemented stories create. Alternately, it is perhaps better to commit to fewer story points per sprint and fill in any capacity with product maintenance or backlog grooming or architectural spikes. These are team decisions that can be considered during Sprint Planning or during the Sprint Retrospective.
Agility
For me, the concept of Done is the key foundational principal that makes Scrum agile. At the end of a Sprint all stories are fully completed, thus potentially shippable. This fact, coupled with a short development iteration, offers the business frequent predictable time windows in which to re-prioritize work or introducing completely new requirements. Scrum allows an organization frequent opportunities to, in contemporary terms, pivot. Easily and readily shifting priorities with minimal impact to productivity is one of the primary mechanisms through which an engineering organization gains agility.
Subscribe to:
Posts (Atom)