Tips and Suggestions for Your First Iteration
Join the DZone community and get the full member experience.Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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?
Opinions expressed by DZone contributors are their own.