Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Tips and Suggestions for Your First Iteration

06.02.2010
| 8432 views |
  • submit to reddit
I've been helping a company establish a few Scrum-style Agile teams lately and there seem to be, as always, a few recurring themes. I wanted to share them while they were fresh on my mind.

Don't over analyze everything. It doesn't matter if you don't know exactly how long everything will take, or how to write perfect unit tests, or how you'll handle the required data dependencies to test X,Y, and Z. Just start moving. Pick a series of small tasks and get started. The best thing about having short iterations is having the chance to reset your expectations next week!

Don't stress over who will be the scrum master. In fact, I make it a point to rotate the role among the team. At first, each team member must be the scrum master for an iteration before anyone can be scrum master twice. How do we pick the first leader? Who's had the fastest speeding ticket? (We're assuming the personality will have a drive to get things done, not a reckless drive to flaunt authority.)

Learn the five-finger rule. Any suggestion someone makes, the entire team votes on it. One finger means I hate it and can't live with it. Five fingers means I love it. The fingers in-between reflect levels of acceptance. Three fingers means you're rather indifferent. We're looking for solutions that can garner "I love it" or "I can live with it" responses. None of the suggestions are permanent; instead we'll have one to three iteration experiments. Feel free to try new things, or let others try new things. It won't last forever and a good team eliminates practices that don't work.

Have short daily meetings. The scrum master leads them. Have a simple token (a pen? hackey sack?) that is passed around. If you have it, you can speak. Otherwise the rest of the team will mock you for speaking out of turn. (This can be a lot of fun!) Be sure each person answers the three questions. What did you do? What problems did you have? What are you planning to do today.

Get continuous integration in place for compiles (if nothing else). If you don't have an automated build, or a running CI server, take an "Iteration Zero" to get your infrastructure in place. I can't over emphasize the benefit this will have for the entire team.

Only work on features with rough estimates, ranging from one to three days. Do you have a six week task? Break it down into manageable pieces.

Have a team with both developers and testers. Pair when writing tests (both of you!) The developers will learn to write better tests, and the testers will too! It doesn't matter which side of the boat the hole is on, not bailing is just dumb.

Have a planning meeting. Your product owner, or manager, (or whoever fills the role for you) brings a enough work for an iteration or two. If you can't agree on what the feature means, or what it means for a feature to be done, reject the card. Have the product owner get more clarity and return the card in a future iteration.

Any work you do must get two sets of eyes on it. You can get this through pairing or through peer code reviews, but no one works alone. This is much about code quality as it is about knowledge sharing. (Btw, if you think your team mates aren't smart enough to "get" your work, the problem is you. It's always you. Don't be That Developer.)

Schedule a demo to show everyone what you've done at the end of iteration. This can be a fun chance to show off, and let other parts of the company (like docs or support) know what's coming down the pipeline.

Finally? Just relax. The team members who stress the most about "But what if this happens? Or that? Or the other??? NOT THE OTHER!!"... these team members get the least done. Just jump in, start working as a team, and adjust in a week. I think you'll find it's not only insanely productive, it's a lot of fun.

I'm sure there are a few more I'll think of later. How about you? What do you see in first time Agile teams?
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jared Richardson replied on Fri, 2010/06/04 - 1:10pm

I recieved a number of replies to this article via Twitter... I'm reposting them here.

 

From George Dinwiddie (link

 Rather than "5 finger rule" I suggest "Roman voting" Thumb up, down, or sideways. Simpler. More graphical.

 

And also (link

I also suggest tracking DONE work daily. Simple graph on the whiteboard.

 

James Carr (link) suggested using villians to personify the problems that drag you down. His team liked to use Apocolypse, from the X-Men, to represent the Really Bad Stuff!

 

And the single most quoted line from the article?

 

 If you think teammates aren't smart enough to "get" your work, the problem is you

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.