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

I have been reading a book entitled “Agile Project Management with Scrum” by Ken Schwaber. It is an interesting read. The examples and stories that he shares of companies who have struggled with Scrum and those that have succeeded are fantastic. The way Schwaber breaks up the book and explains all the roles then gives example makes it a great learning tool. It is also really funny and clever.

One complaint I have with the book is that it is very technical, it seems that the reader is assumed to have many years of software development experience. It is interesting that the projects that Schwaber discusses that have the most trouble with Scrum are those that are “stuck” in their old ways of working. It’s almost as if the old saying of “A little knowledge is a dangerous thing” is true for Scrum implementations. “Scrum means doing things in small cycles - so I will do everything the same except in shorter cycles.” Anybody ever heard of that type of reasoning?

I definitely recommend this book for those who have considerable experience in the technology field. For those who don’t this book might be challenging at times, espcially with the computer language words that are used.

I want to continually learn for my own personal and professional growth. So I  would like to know which books do you suggest? Are there any books that share examples and stories that are not focused on software development? If you disagree which my review of the book please comment.

For the past three months I have been working with Paul Heidema (our VP of Marketing) to use OpenAgile to run our business.  I thought it might be interesting for folks to see a screen capture of how we have arranged things in CardMeeting to do our planning and tracking. The yellow cards are labels for our Cycles, the white cards are Work Queue items, and the blue cards are Tasks related to the item.  The orange cards represent special information (eg. obstacles or ongoing work) and the green cards represent reflections and learning for each Cycle.

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? Read the rest of this entry »

One of my favorite books in the world is Systemantics, by John Gall. This irreverent look at systems and how they fail has a lot to teach a community that is attempting to re-work the systems of software development. Much of it justifies the “simple set of principles, applied” approach that most Agile methods use. It should also provide good insights into anyone trying to develop and architect complex software systems. The best kind of parody is one that’s hard to tell if it’s parody, because it’s so insightful.

The book is available from the author at the Systems Bible page.

A decent quick look at the kind of material found inside can be found here: Commentary on the principles of “Systemantics”, by Anthony Judge

And this article goes into more discussion about Gall’s laws of systemantics: Bart Stewart on Systemantics

UPDATED: Best quote yet: “Admittedly, it’s not easy to imagine what a self-organizing car engine would look like, but maybe it’s time someone tried.” -Bart Stewart

Bell Canada is traffic shaping to restrict the speed of data on P2P networks.  Mark Kuznicki has written a good reference piece on his blog.  The piece is titled Bell Canada Hands Net Neutrality Advocates a Gift.  It’s sad but funny too.  I don’t usually post non-agile items, but I thought this one deserved some attention.  Please, if this is important to you, take the time to blog about it even if just to link to Mark’s article.  We’re using the tags: bellthrottling, netneutrality, canada.

For the last 3 months I have been lucky to work with tools and in an environment that is agile. My job requires lots of small projects and tasks and my job title is clear but my work is every changing. I like new challenges and creative tasks.

Recently our small team has been using http://cardmeeting.com/ an online tool to add ideas, set up tasks, and keep track of what the whole is doing and what still needs to be done.

I am looking for more tools to make our agile practices more streamlined and efficient. Any suggestions or ideas?

This article called “To Bet Or Not To Bet: How The Brain Learns To Estimate Risk” is interesting, particularly because agile methods treat risk completely differently than traditional methods.

Berteig Consulting with the help of some partners is now offering a new service called The Agile Clinic. This is not a typical coaching or training session. The entire clinic has a duration of just one day. During this day there are short 30 or 60 minute appointments made by managers, executives, and staff with two experienced agile coaches. These coaches listen to problems presented to them, consult, discover, facilitate, diagnose, and offer solutions. These appointments are designed to be intense and high-impact sessions. Visit www.agileclinic.com to see how this service can add great value and provide fantastic results to your company with a small time cost.

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses - if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices List (OpenOffice format - 68KB)

Linda Rising and several others have a discussion about the Retrospective Prime Directive over on InfoQ.  It’s a fabulous read!

There was an interesting discussion on the LeanAgileScrum Yahoo Group early in December regarding the difference between flow (lean) and iterations (agile) that caught my eye. I only just now have had the time to write about it.

Read the rest of this entry »

Berteig Consulting is a Silver Sponsor for Agile 2008.  Hopefully our logo will show up on their home page sometime soon :-)  We also have several proposals for sessions in and we are planning some really fantastic stuff for the conference.  Make sure you attend if at all possible!

I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.

Read the rest of this entry »

There’s a great discussion on the Extreme Programming Yahoo! group where a whole bunch of folks list their blogs out. If you aren’t part of the group, you should probably join it (it focuses on technical practices, and there’s lots of other good agile stuff there too). The discussion starts with a message from James Carr where he asks who else here blogs?

It’s probably still cool to jump in with your own blog link if you have an agile-focused blog (I’m sure Scrum, Lean and other agile methods would be welcome even though it’s an extreme programming list!)

Building software is expensive. I’m not talking about creating software, I mean taking software as written (source code) and running it through compilers and linkers and post-processors and packagers and obfuscators and installer-generators. It might not seem so, but look under the covers and you will find a wealth of costs and potential savings…

Lifecycle of the Developer

The developer has a concept he needs to translate into software. He (or she) does not sit and meditate until it comes to him, then streams it effortlessly into the computer. Rather he tries something, and tries something else, and writes some conditions (tests) to limit the scope of his options, and cycles over and over and over again between four main activities: creating -> building -> executing tests -> discovering. The developer then wraps around, having discovered and learned (found the bug or identified a future direction) and begins to create again.

If you break this down, there are two states - active and waiting - that the developer is in at any point. He is active when he is learning and he is active when he is creating. He is waiting when he is building and executing tests. So the developer’s ability to do further learning/creative work comes from how long he has to wait for building/executing the software.

Read the rest of this entry »