I wanted to jump up and down when I read it. It speaks to me about why I hate the whole idea of an electronic board.

He also links to Xavier Quesada Allue’s blog, which echoes this practical approach to scrum and teams. I absolutely love his “Elements of taskboard design” which has real practical tips on what you can do to make your task board more effective. And he made me aware of “Super Sticky Post It’s“.

Now I’m off to convince Loren, Mistress of Stationery, to order us some of those. Sometimes the best tools are already out there.

Scrum(tm) – a 3M product

I found Jeff Patton’s ‘Story Map‘ to be a useful discussion on an alternative to the 1-dimensional product backlog.

It was also the basis of one of the Open Spaces sessions at the recent Orlando gathering. This is definitely not a vanilla scrum technique, so not suggested for beginners. Jeff’s presentation explicitly states he believes it to be a ‘Ha’ technique (in the Shu-Ha-Ri schema).

One for the scrum masters among the readers: the Scrum Alliance has a run down of a discussion on the ‘Top 10 Organisational Impediments‘. Which will also give you a chance to check out the zooty new Scrum Alliance website. There is lots of content from the Orlando Gathering there as well.

The hot topic at the moment in the scrum community is all about the role of certification and testing. Mishkin Berteig‘s view of the beta test can be found here. I’d be curious to hear in the comments what people’s view of the test are.

Till next time

Imesh Soni has a good article up at Scrum Alliance, which could probably be called the ’9 Habit of highly Ineffective Scrums’ or something. It describes which tricks are used in traditional waterfall organisations and need to be changed for scrum teams.

From Ukrainian Agile discussion group comes this paper on how to use LEGO(tm) to simulate a scrum. Useful in showing people how the various principles and practices fit together.

For our Product Owners in the audience, Jack Milunsky has a good top 10 list of the things which a PO are supposed to be doing.

From Jeff Atwood (who is apparently a CSM) a really good article about team dynamics and the importance of eliminating the ‘bad apples’. As a scrum master it’s critical that your identify the impediments a team member may be imposing on the team.

For the techies, a good article on how to handle intermittence when using test driven development.

And from Ron Jeffries one on the necessity of refactoring. Ron’s salient point is that if you’re practising agile development your design must evolve. Under those circumstances refactoring is a ‘law of nature’.

Jurgen Appelo has published an excellent scrum presentation that you can find on his blog. Its a really good one for people not that familar with scrum and covers the history, practices and discussion on some of the usual questions.

Lastly, from the ever reliable InfoQ comes a good discussion about the pros and cons of physical information radiators. I love my Big Visible Charts; hiding things in a web application just don’t seem like a good idea, but go read the article to hear from more than one viewpoint.

Till next week.

I recently found an oldy-but-goody on running stand ups: It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings. This is a case of getting the basics right, and Jason Yip of ThoughtWorks has some really good tips. My favourite; if your team is engaging in the ‘Storytelling’ anti-pattern (or smell), make the person speaking do so while standing on one leg.

Jeff Sutherland talks a bit about how organisational change (like scrum adoption) happens. To add to this point have a look at an older article from Mike Vizdos. It contains the rather startling statistic from Ken Schwaber that about 75% of teams fail to successfully implement scrum.

The core of why that is, can probably be down to the reasons presented in this article from Alistair Cockburn. And if you’re not sure, he has a great top 10 list of how to know if you’re not doing agile.

On a less gloomy note: you can find a myriad of cool scrum games at Tasty Cupcakes.

For those with an interest in the debate about whether Scrum is Lean, Dave West’s slightly sensationalist article can be found here. Be sure to check out the debate in the comments.

And lastly, Tom Perry has an interesting idea; using the 360 degree feedback format as preparation for your sprint retrospective. This does move the discussion in the retrospective from a team-based improvement to more personal one, and should be used with caution.

Till next week.

Jurgen Appelo’s post on how scrum uses peer pressure in a positive way can be found here.
I enjoy his writing and he uses a cool technique for creating a scrum team, by getting them to cook dinner for him. I like it ‘cos I worked as a chef for a while and having everyone working together to produce a meal for several people at the same time is a good way to teach people how to self-organise. Plus you get free food out of it

There’s a good article by Clinton Keith here about the factors influencing your sprint length.

Mike Cohn clarified the ‘Release Backlog’ concept and why it really isn’t a good idea. He draws attention to the use of velocity as a predictor of the shipping date.

He has another good article up about story points. Many teams struggle with the move from time based estimates to story points. I think this may help clarify what story points are, given that they are a more abstract measure of effort.

Having to support the software we ship while building new functionality is probably one of the most challenging aspects of implementing scrum. Boris will tell you that the answer is not to write bugs. But if you do, how to handle the support requests while not changing the scope of the sprint or endangering the ability to deliver the commitment? Kelly Walters at ‘All About Agile’ has some good suggestions here.

If you can’t wait till next week for more links, you can also follow me on twitter. Till next week.

Carlo

I am particularly encouraged by the range of people and institutions that are engaging with the Scrum Alliance and embracing Scrum…from XP and Crystal to the PMI!

For more information visit http://www.scrumalliance.org/events/19–orlando-scrum-gathering

First up is Kent Beck’s ‘State of Agile’ presentation.
http://www.infoq.com/news/2009/01/Agile-Trends-Kent-Beck
He has some very interesting things to say about the alignment between agile’s values of transparency and how they help business, particularly in our current difficult economic climate.

Mike Cohn posted what amounts to a “Requirements Koan”
http://blog.mountaingoatsoftware.com/?p=77
This challenge was like a brain worm that I kept thinking about for days after. It is intended to get you to think about the fact that all new requirements can be thought of as merely improvements. Or something. Go read the post.

Also, Mike Cohn’s presentation on what scrum is has received a small update and a face lift. You can find it at:
http://www.mountaingoatsoftware.com/scrum-a-presentation

Martin Fowler has an interesting piece on the importance of using engineering practises that support agile development
http://martinfowler.com/bliki/FlaccidScrum.html
Of particular interest to me was his statement that team’s who do not adopt these practises are risking the reputation of scrum as a whole, but that he’s not worried about it.

Boris Gloger posted a review of the VersionOne software:
http://scrum4you.wordpress.com/2009/02/03/scrum-tools-version-one/

Lastly, if you’re looking for a comprehensive rundown on the tools available for supporting scrum in your organisation, Mike Cohn has started a website at:
http://www.userstories.com/
Coming later in the year will be samples and examples of stories and backlogs.

The adoption of Scrum as a project management process in IT projects has been extremely rapid. This is because of the fundamental principle that Scrum embraces is that software development if unpredictable. Scrum uses an iterative approach with short but focused iterations. Scrum formalizes the informal “do what is needed to be done” approach that is already followed in the software industry. People that use Scrum have seen huge productivity gains (up to 600% claimed by some). I will attempt to outline the reasons for Scrums success below.

  Methodology

Scrum is a lightweight, simple and highly effective methodology that delivers business value every two weeks (or there about). The team is highly focused on the goals of the iteration and the progress of the team (or lack thereof) is highly visible. Because the approach breaks down the work into small manageable pieces, teams feel that the goals of the project are achievable. It also allows the team systematically approach the work and start the project without necessarily understanding exactly how or what needs to be done in later iterations of the project.

Delivery 

Due to the fact that Scrum delivers business value every two weeks project sponsors feel that there is progress happening on the project all the time. They ultimately feel much more in control of the project and its budget. The use of the burndown chart and the daily “stand up” meeting gives everyone focus and makes any slippages or problems surface very early on in the lifecycle.

People 

Generally, because Scrum works so well and delivers business value very well, the mood on a Scrum team is very positive and motivated. Scrum encourages competition in a very subtle way between members on the team, however it also encourages a “one for all, all for one” type attitude on the project due to the fact that the productivity of the team is very visible. If one aspect of the project is failing it looks bad for everyone and this encourages everyone to get involved and help out. Naturally a lot of this type of behavior is seen in teams with more experienced and mature members.

 Philosophy

Scrum undoubtedly build trust between all the different members of a mature Scrum team. Everyone can see exactly what other members of the team are doing and what they are struggling with. It also builds trust with the sponsors of the project by quickly delivering business value to them and allowing them to shape and reform the project as it goes. Scrum also has the following “rules”:

• The people doing the work define and estimate the work

• The team sit together and interact constantly

• The people doing the work know what and how to deliver what is needed

Management 

Managers using Scrum generally enjoy the “No fuss”, delivery mindset of Scrum. Because a Scrum team very much “self managed” the work, there is very little management overhead required for a Scrum project. There are no complex Gannt charts to wade through and update and it is relatively easy to see where issues and slippage is happening.