Thanks to some quick feedback from Tobias Mayer, we have made a trimmed-down demo version of the Scrum Study Guide available for free download.
Scrum Study Guide, “The Best Tool for New ScrumMasters”, is now available at Scrum Study Guide. This guide is designed to be an editable tool for helping ScrumMasters do their jobs effectively. With the Scrum Study Guide you are able to keep track of the rules of Scrum, to keep structured notes on your own job as the ScrumMaster, to maintain a list of online reference material, to assess the progress of your team, and to organize the obstacles you are working on. It also contains a wealth of reference information for learning along the way.
This is the project I’ve been working on for the last several months that has reduced my output here on Agile Advice. It represents a huge investment of my time as well as several other people who have assisted me in this including Paul Heidema and Garry Berteig. Purchasing the Scrum Study Guide, aside from its usefulness as a tool itself, will also give you substantial discounts on other services offered by Berteig Consulting Inc. Finally, if you like it, you can help to share it by letting us know who should get a discount on their purchase of the Scrum Study Guide. Enjoy!
Wonderful article by Martin Fowler that discusses the relationship between individual productivity, cost, team size, time to market and value delivered. Some very interesting conclusions. This is critical reading if you are a manager!
Nice little article over at ITWorldCanada on “Detailed Development Specs Up Front a ‘Worst Practice’ Says IBM“. Pretty standard agile/scrum message. It’s nice to see it being delivered at ProjectWorld. I wish I could have been there :-) Anyone reading this at the talk, I would love to hear your comments.
I have been practicing Agile for the last few months for my job. With Mishkin we have been following many of the Agile rules as a small team. It has been very successful, and the learning is tremendous.
So, like Mishkin, I wondered if I could use the same practices at home. A few days ago I asked my wife, Laila, if we could try using cards, a work queue, and cycles. She thought it would be great idea to put all our tasks on post-its and not have to remember them.
Yesterday we made the work queue, did some estimation, and decided what we would commit to for our first cycle. We consulting and decided that one week cycles would make the most sense for our schedules.
Right away I noticed a relaxation that came over Laila. I guess that it is very tough to maintain a work queue in your head day-in and day-out. I will continue to post my thoughts on our progress.
Has anybody else used agile practices outside of your work? How did it work? What did you learn? Maybe my wife and I can learn from you and avoid those challenges.
Called “Mr. Squiggle” after an Australian TV show, this exercise looks great! Thanks to Patrick Kua for this great idea.
Our earlier post saying that it was available was a mistake.
Sorry for the mistake.
Geoffrey Wiseman has written a post on InfoQ about Complaint-Free Iterations. I like the idea. Check it out and participate in the discussion there.
The recent growth in the popularity of agile methods such as Scrum is gratifying. However, I am constantly encountering people looking for the Silver Bullet of software development. In the paper written by Brooks, No Silver Bullet[pdf], he describes “accidental” and “essential” complexity. Agile in no way changes his arguments. What agile methods do is to help remove the accidental complexity associated with people and their interactions. This can lead to substantial increases in productivity, but it does not change the hardness of the underlying problem that is being solved by building a particular software system. In fact, doing a good job with agile methods, in particular Scrum, is extremely hard work due to the deep cultural shifts that must occur in order to get the full benefits.
The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this?
Identify Repeating Tasks
Early on, the team will make tasks that include every activity that is done to make software out of the features listed in the Product Backlog. This will include all sorts of things including “Build login web service”, “Write unit tests”, “Review code”, etc. Most of these tasks will be thought of in terms of who will be doing them so that throughout the Sprint every person on the team is busy with tasks and there is very little passing of a single task from one person to another. In other words, one task = one person.
It will quickly become clear that there are a number of similar or identical tasks that show up for most items in the Product Backlog. If you have to develop a user-visible feature or function in the software, you always need to check code into your version control system, you always need to do some sort of testing on the code, etc. So you might have tasks in the Sprint Backlog called “Internationalize login panel”, “Internationalize registration panel”, “Internationalize login error panel”, and so on. Every Product Backlog Item has an “Internationalize ….” task. These tasks can be abstracted and the “Internationalize” idea becomes part of the Definition of Done (DoD). It applies for every Product Backlog Item.
You might also have common pairs of tasks where one of the pair is unique to what is being built, and another is attached to it, but common across many pieces of the system. For example, you might have a task “AnonymousUser class” and an associated “Unit test AnonymousUser class”. Then you might have another task “LoginErrorHandler class” and an associated task “Unit test LoginErrorHandler class”. Again, the idea of unit testing then can be identified as part of the DoD. These apply to every Sprint Backlog Task.
Once these required activities or constraints are added to the DoD, you can then stop identifying them as separate tasks. Instead, they get represented in some other way in your work environment: a checklist on a whiteboard, columns in a spreadsheet, or checkboxes pre-printed on the cards you use to write Tasks or Product Backlog Items.
Prepare for Release
The software might need many things done to it or around it to prepare for a release. Often, these things will be put on the Product Backlog as non-functional business requirements. For example, it may be important to write online help for the system and this is not currently being done by the team. The Product Owner identifies that users will need this help and puts it on the Product Backlog. Yo(1) discovers that These things can eventually be moved into the DoD. For example, yo puts “Online Help” in the Product Backlog and prioritizes it somewhere near to the point in the Product Backlog when the system will be ready for a release. The team eventually gets to this item and does it during a Sprint. At this point, the system is “caught up”, but in order to prepare for the next release, the Product Owner will have to put the same “Online Help” item on the Product Backlog again. Instead of doing this, it can be added to the DoD.
It is critical that the team agree to add these things to the DoD, and not be forced by someone. If the team does not feel that it is within their capacity to include something in the DoD, the ScrumMaster should find ways to assist with this: training, etc. Once something is added to the DoD, it must be completed every Sprint in order to have a successful Sprint.
Release/Deploy to Users
There is nothing like actually getting software into the hands of users to find out what “done” really means! Similarly to preparing for a release by adding things to the Product Backlog, the team may have a “release sprint” or a “stabilization sprint”. Everything that is done in one of these special Sprints could and probably should be added to the DoD sooner rather than later! Again, the team must agree to doing this expansion of the DoD and be supported by the organization so that they have the capacity to meet the DoD every Sprint.
