Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

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.

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? (more…)