Mark Levison has written up a great list of Scrum Smells on his blog Notes from a Tool User. Check them out! There is a lot of great information there. He also asks your help: if you know of common problems with Scrum, see if you can add them to the list!
This looks good: Agile Coach Training - Aug. 1-3, 2008. I’m not directly affiliated although Deborah Hartmann and I work together frequently.
Everywhere I go, there are three practices that make the biggest difference in overall productivity for teams and organizations. All three practices are part of agile methods such as Scrum and Extreme Programming, but you don’t need to be doing these methods to take advantage of these practices. All of them are relatively inexpensive, and the return on investment for these practices is HUGE!!! Without further ado…
This is astonishing: you can expect a 60% boost in team productivity from this single practice! The cost of re-stacking your cubes or office spaces is trivial compared to the benefits. If you are going to do this, do it right! Do the research, hire an agile coach or consultant, but make sure it is done well. One organization I worked with was very excited about their new team room setup. They had a nice open-concept layout with lots of windows etc. But they had also made some big mistakes including that all the developers on a single team would have a low wall separating them from each other. Because of poor layout that would block communication paths, their new setup would actually be worse than their old setup! Some research has shown that you can expect as much as a doubling of productivity (reference). This is one practice you don’t want to let your competitors pick up before you do! Here are some tips on agile team room setup.
Once you have set up your team room, it is critical for your team to have something to do! The fastest way to get your team doing something is to start using short cycles of work (iterations, sprints) to deliver valuable results such as working software. Many software development projects use iterations that are two weeks long or even a month long. I strongly recommend iterations that are only one week long. Again, the benefits are incredible: your team will move through the stages of team development (forming, storming, norming and performing - reference) much more quickly than with longer iterations or no iterations… thus leading to high productivity much sooner. The value here is in the time gained. This chart demonstrates how this works:
The short iterations provide a certain type of pressure that forces team and project crisis to happen quickly. However, because iterations deliver working, valuable results, the pressure is not demoralizing, instead it motivates teams to get through the crisis and reach the norming and performing stages of development quickly. Again, to make this work, there are some critical success factors including methods of allowing team commitment, self-organizing and obstacle removal.
There is a myth that speed and quality are mutually exclusive. This comes from the idea that you need to slow down to make stuff high quality or that you need to sacrifice quality in order to go fast. It is true that initially you might get gains through these approaches. The really amazing thing happens when you try, deliberately and systematically, to do both high speed and high quality work. In software development this is best done through test driven development. In informal polling I’ve done with teams I’ve worked with, test driven development produces a noticeable long-term productivity gain as well as a simultaneous increase in developer and end user satisfaction due to a substantial reduction in defects discovered after the code leaves the developers. I have seen teams doing this that reduce defect rates to 5% (or less!) of what they once were prior to test driven development… while at the same time delivering projects faster than expected. Since substantial expense is squandered on defect management (tools, support teams, user training, lost productivity, etc.) and since staff turnover is also high in IT and high-tech, the results of test driven development on the bottom line are substantial.
If a team and an organization adopt these practices, get through the initial cost of learning them, then I would like to suggest that your teams can easily double their productivity if not more. For a team of 5 people working on a 100 day project this amounts to shortening the project to 50 days (save $200,000) or get twice as much work done. Clearly, an organization that adopted these practices and perfected them would save huge amounts of money and would be able to crush any competitors not doing this.
Previously I wrote a more general treatment of the benefits of agile and an article that lists other resources discussing the benefits of agile.
Any discussion of benefits should at least say a few words about how exactly to measure those benefits! However, I’m out of time. How do you measure the benefits of agile?
Hey folks, if you found this useful, could you please “Digg” and “Reddit” this article? Thanks!
Not getting the benefits of agile? Consider the Agile Clinic!
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.
Called “Mr. Squiggle” after an Australian TV show, this exercise looks great! Thanks to Patrick Kua for this great idea.
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.
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.
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!)
Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method. These Patterns of Agile Adoptions are described as three sets of contrasting options:
I just read through this article about Requirements Management in an Agile World. It’s a pretty brief article (just the one page), so there isn’t too much there. Have a read, and then come back here and tell us all: what is wrong with this article?
This sounds cool: The Three Word Starter Retrospective Safety Exercise.
Here is a great article on InfoQ about team size and productivity. The basic idea is that a small team, supported by excellent tools and techniques will always do better than a large team. One aspect of this that isn’t mentioned in the article, but which figures prominently in “The Mythical Man-Month” is the idea of communication overhead. It is impossible to house a large team in a team room and therefore communication cycle times, effectiveness and frequency also become a substantial factor.
This is a nice little encapsulation of the Scrum process and the daily Scrum meeting: http://www.effectivemeetings.com/teams/teamwork/scrum.asp. It is described in completely non-technical language and the example used is that of a marketing team. Basically, what is described is the Agile Skeleton plus the daily status meeting without any of the other project management aspects of Scrum.
This is a great presentation on the importance of trust: http://www.agile2007.org/agile2007/downloads/presentations/Larsen_613_613.pdf. I love this sort of thing since it is, to me, so important to building effective teams. I often prefer to talk about truthfulness since that is the attribute or capacity that people need to develop, but the result of truthfulness is trust, so in many ways they are one and the same.
Sanjiv Augustine, agile coach and consultant at LitheSpeed, has a great blog: LitheBlog. Focus on agile project management topics. Good writing and good reading!
One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to “sell”, set up and execute on agile contracts. Here are the links:
FaceBook is an extremely popular social networking site. It is also becoming an effective community collaboration site. The agile community is gradually starting to see the value of this environment. Here are four groups related to agile practices:
Agile and Lean Development Community (589 members)
Agile Project Management (218 members)
Extreme Programming (16 members)
Scrum (7 members)
Well, it’s officially launched: The Agile Professor - Creating an Agile Learning Environment for Classrooms and Schools. This blog, authored primarily by my father, Garry Berteig, is an exploration of the use of agile methods to organize learning environments such as schools, classrooms, seminars, workshops, etc. The material in this blog will include Garry’s experiences over the past two and a half years of experimenting with agile methods in an educational context as well as a record of his continuing exploration of this topic. I might chime in from time to time too 
I’m fascinated by the idea of applying agile methods outside of software… be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years… agile classroom management. Here’s how I do it in my Agile Project Management / ScrumMaster Certification courses:
Having just finished a substantial series of articles on the Benefits of Agile, I thought it might be good to let you all know about some other ideas about these benefits. I don’t agree with everyone who has written on this topic, but of course, you can judge for yourself!
Bill Wake has a great collection of photos of team rooms for agile teams.
In the ScrumMaster training, I include a diagram that has a simple idea: to map the areas of complexity in a problem based on two dimensions: Agreement and Certainty. This diagram is an adaptation of the diagram by Ralph Stacey found in this article called Aides for Complexity by Brenda Zimmerman. This diagram or model can be used to help us understand where and how agile methods can be applied.
Christopher Avery, who has written a book about teams called “Teamwork is an Individual Skill”, has a good reference page on his web site about teams. From his FAQ, here is his definition of “team”:
A team is a group of people whose personal outcomes are obviously linked to a collective outcome — such as a successful project — and who work together to maximize collective and individual outcomes. “Team” also refers to the quality of group relationships that allows ordinary individuals to achieve extraordinary results together — such as a project that surpasses its goals.
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.