Notes from a Tool User

One year of Scrum - Lessons Learned

This is a series of posts that will focus on seven key lessons I've learned over the past year of implementing and coaching scrum.

I became interested in Agile development in 2000 after failing at every other approach I’d ever tried: waterfall, RUP, drawing UML diagrams (I spent a lot of time perfecting the diagrams and less producing a working product).

In Jan 06 a team I was a member of started doing daily standups during a crisis. When the problem was solved we decided the standups had been effective at sharing information so we decided to keep them. After a reorg in Oct 06 we decided to start iterations and add regular Planning, Review and Retrospective meetings. So began our journey with Scrum.

Lessons Learned

• Working at a distance is hard
• Good Agenda's make for great meetings
• A great Product Owner is key
• Embrace Failure
• Build Trust first
• Light Touch Leadership is required
• Healthy builds matter

I will post the details of these lessons at the rate of one or two a week until I'm done.

Programming note - the focus of these posts will not be cheer leading. Scrum has worked for us - if it didn't we wouldn't keep doing it. Instead the focus will be on the things that were hard

If you enjoyed this post, subscribe now to get free updates.

Articles on Failure

Don't worry I'm not about to turn this into a link blog. I stumbled across these articles while looking for more Scrum Smells.

How to Fail with Agile (the link isn't date specific and will probably rot by Septmember) - by Clinton Keith and Mike Cohn. They cover four classes of issues (20 in all) that might cause problems:

1. Management - Don't trust the team or agile. Micromanage both your team members and the process...
2. Team - Continually fail to deliver what you committed to deliver during iteration planning...
3. Product Owner - Don't pay attention to the progress of each iteration and objectively evaluate the value of that progress...
4. Process - Drop and customize important agile practices before fully understanding them...

11 Ways Agile Adoptions Fail by Jean Tabaka covers items like: Ineffective use of the retrospective, Product Owner is Consistently Unavailable or There are Too Many Owners Who Disagree and Teams Lacking Authority and Decision-Making Ability.

10 ways to screw up with Scrum and XP by Henrik Kniberg (author of Scrum and XP from the trenches): Team is pressured, Technical Debt ...

Next post will contain some more original content.

If you enjoyed this post, subscribe now to get free updates.

Miscellany

I promise that won't turn Notes into a link blog but there are a few interesting topics that I've stumbled across recently.

Mishkin Berteig (friend and mentor) has a pair of interesting posts:

• The Best Agile Practices to Implement Now (Highest Return on Investment) - he should called it biggest bang for your buck. His recommendations:  "A Proper Team Room", "Short Iterations" and "Test Driven Development". Read the post for the reasoning.
• Measuring Process Improvements - Cycle Time? - a long article that examines how to measure the effect of process changes. Along the way Mishkin also highlights some of the pitfalls that dog Agile implementations.

Deborah Hartmann and Michael K. Spayd have organized Agile Coach Training I would be attending but its in conflict with family obligations.

Finally via Alistair Cockburn I found Wordle.net. What a cool way to waste time. Wordle is a toy for generating “word clouds” from text that you provide. Some examples:

Agile/Scrum Smells

In 2003 Mike Cohn started this project with a paper entitled: Toward a Catalog of Scrum Smells (pdf - in the spirit of Code Smells) and last year Rowan Bunning did a presentation Sharing More than > Deodorant for Scrum Smells (pdf). Rowan encouraged to create a wiki with all of these of smells. So I've spent some time in the past few days fleshing out this Catalog.  These are a series of simple patterns that describe a problem and then offer some potential solutions.

Minimally Agile

Recently I had a conversation with a long time friend that made me realize that in my writing and conversation I often come across as a fanatic. Oppppsssss. Time for me to hit the big red reset button. I'm opinionated and passionate but I also believe that you can do good work even if your not push agile limits. There are two things that I'm dogmatic about:

1. Quality - I can't stand shit, especially shit code.
2. Accuracy - I hate mis-information and will pounce on it even when I should know better.

In any case I thought it might help put my core beliefs on the table. If you are working in small achievable chunks and are continuously improving you are Agile. On the other hand you be doing all of the Scrum Practices (Short Iterations, Planning Meeting, Daily Standup, etc.) but are not making any ongoing changes, then you're not Agile.

 

If you enjoyed this post, subscribe now to get free updates.

Help needed Choosing a Ruby Framework

I'm helping a friend who is going to be creating a new web app a hand navigating the technology maze. So far I've steered him in the direction of Ruby because it seems that a small team can build a good web app quickly in it. So far so good. I've read a most of the Pick Axe book and it’s great as far as it goes.

But now I'm stuck how do I evaluate the various frameworks? Rails? Merb? I like the agnostic approach of Merb and am concerned that Rails has already chosen the UI library (the ORM tool, etc.) for me. But I know so little at this stage I may be missing the boat. Where do I go to learn more? The ideal would be I write small web app in each framework to get sense of what works. But this is unpaid work and I have a family so that option is right out.

I’ve found a news item at InfoQ: The Forgotten Ruby Web Frameworks - it at least mentions other frameworks. But even that news item makes no real attempt at comparison. Are there any good comparisons of the frameworks out there? Where would you start?

To be the decision doesn't need to be made right away and there will be room for some experimentation once his developer gets going, I'm just trying to set him on a good path.

Mythbusting - Collective Code Ownership

In researching "Are there weaknesses with Collective Code Ownership?" for a news item on InfoQ I was struck by the number of myths that get repeated around Collective Code Ownership. I thought it time to burst a few balloons.

Software Development as profession? Not Yet, Probably Never

In discussing Scott Bain's book: Emergent Design: The Evolutionary Nature of Professional Software Development Martin Heller asks Is "professional software developer" an oxymoron?

In the book (which I've not read yet), Scott makes the case for the use design patterns, test driven development, coding style and readability. This sounds like the book we all wish our colleagues would read (not ourselves of course - we're already perfect).

Test Driven Development vs "Plain Old Unit Testing"

Scruffy Looking Cat Herder (aka Jacob Proffitt) recently wrote Test Driven Development considered harmful. Jacob is writing about why he believes that TDD zealots have caused people to skip unit testing altogether. I allege that Jacob is missing the boat here. 

The gist of Jacob’s hypothesis has five points which I summarize: 

1. Unit testing provides benefits when used regularly. 
2. Ensuring that developers write unit tests is the prime benefit of test driven development. 
3. Most unit test advocates are also TDD proponents. 
4. Looking for information on Unit Testing? You’re most likely to find a piece encouraging you to test first. 
5. Many developers skip Unit Testing altogether because TDD seemed too hard or too much of a change.

Solve your Task Estimation problem in Scrum

I'm often asked about improving the estimates of task hours generated during planning meetings. Years of waterfall development have taught us - if we improve the estimates we will do a much better job of tracking the sprint progress.

When this comes up I like to ask two questions:

• why estimate task size at all?
• what value do we gain improving our project tracking?

Tools, Tools, Tools

As software developers we have this innate belief that another tool will solve all our problems. To that end many agile practitioners search for a tool to track their projects for them.

However in using a tool we miss the benefits of cards posted on a whiteboard/corkboard in a public place.