One of my former interns, an excellent engineer, is working at a company that is transitioning to agile. He asked for some readings and resources I’d recommend. This got a bit longer than a few links, so I decided to turn it into an article instead of a direct message.

Without further ado, my recommended resources (and steps to take with them) for a team or company transitioning to Agile.

• Read the Scrum Guide. Map it out on the whiteboard. Poke at it until you get how the values influence the practices, how the practices reflect the values, and how the artifacts help the team and the company. Then read it again.
• Now read Joel Spolsky’s series on Painless Functional Specifications (Part 1, Part 2, Part 3, Part 4). Now, up-front specs are not a standard Agile recommendation. Product Owners, take note. I’ll come back to functional specs and why they’re important in a bit. For now, enjoy the tension between Agile and BDUF.
• Watch Agile For All‘s Scrum Foundations series (15 videos, probably less than an hour all together). Compare this to the understanding you got from the Scrum Guide. Discuss with your transition-to-Scrum team to compare notes on how you’ve refined your understanding of Scrum.
• Now read the Manifesto for Agile Software Development. Note the sentence at the bottom: “…there is value to the items on the right” but more value in the items on the left. Again, tension. Follow up with the principles behind the Agile Manifesto. Spend a few minutes staring into space figuring out how all the material from the first bullet points fits into the abstract framework of the Manifesto and its principles.
• And to get back to something more concrete, finish up with Mountain Goat Software’s Scrum Roles (click through to the descriptions of the Product Owner, Scrum Master, and Scrum Team).
• (Bonus: Extreme Programming (XP) is another way of doing Agile. Reading up on it (more detail) may give you ideas down the road about ways to help improve your Scrum team.)

That’s good theory and a few resources for reference. I mentioned we’d come back to functional specs, and it’s about that time. First, a caution.

Caution: Organizations adopt Scrum for a variety of reasons. Sometimes they realize they want to develop software better. Sometimes they want to appease a room full of grumpy engineers. Sometimes they want to be trendy. Sometimes they want to squeeze more work out of their engineers and heard that Agile lets them do that. Sometimes they have heard that Agile is the silver bullet (wikipedia). Sometimes it’s change for the sake of change. Therefore, individuals charged with leading a Scrum transition should gauge the commitment of the organization (starting with their direct manager, the project management organization if applicable, and management layers all the way up to the top). If there is a lack of commitment to the transition, or an unwillingness to explain what Scrum/Agile means to a higher layer, the transition will be more difficult.

Back to functional specs. Did you notice that in the Scrum resources, there was very little description of how the Product Owner came up with product backlog items or tasks or user stories? You probably didn’t. I didn’t. It was only during my CSPO training, when my trainer pointed it out, that I realized it. I don’t necessarily recommend functional specs in all situations, but I have found them useful. They are probably more accessible to novice Product Owners than most other approaches.

So, because it’s getting late and I want to keep this practical, here’s how I’ve approached the Product Owner role for a particular team and project in the past. (And yes, it happens to be for the project my former intern worked on. But it’s not that different for most of my projects.)

1. Way before the project starts (months if possible), write a functional spec. Put a lot of effort into the scenarios. Understand how and why the product will be used. If the scenarios are done well, the rest of the spec (and the rest of the project) gets a lot easier. (Bonus: make the scenarios funny. Joel is right on this. Then your specs get read and enjoyed!)
2. Have someone you trust review the spec. Revise the spec.
3. Put the spec away for at least a week.
4. Re-read the spec. Revise the rough edges. Yeah, they’re there. And you see them now.
5. Make a list of the most valuable things the product does, in order. You’ll want the team to attack the product by creating as much value as quickly as possible. (Note, not from this particular project, but in general: when they tell you they’ll need a few months to design the database, mock up the user interface, and build some technical infrastructure, say “no.” Look for working software that delivers value. Look for it with the team, working together.)
6. Break that list of valuable things down into steps. The less experienced your team is, the smaller those steps will need to be. The less experienced you are, the harder it will be to break them down. You’re aiming for tasks that take your typical developer a couple of days, tops. Smaller is better.
7. Write those steps down in your task-tracking tool (sticky notes on a wall, Jira, Trello… There are a lot of options. If you don’t know, start with something cheap and easy. I’d suggest sticky notes. Get the super-sticky ones and good markers.). Make it clear what has to happen for the task to be considered “done”. You can do that on the card or when discussing with the team.
8. Repeat until you get about two or three sprints’ worth of tasks done.
9. Prioritize the tasks. There may be something “later” that would bring more value (to the customer, increase development speed, protecting your boss from internal pressure, etc.) if it were done sooner.
10. As the team chews through tasks, continue to revise the spec, understand the value of the product, create tasks, and prioritize tasks. Keep several sprints’ worth of tasks on the backlog. Realize that your understanding of the product may change as it’s built and as users experience it. (If you have users, talk to them regularly!)

I’m glad to answer questions for anyone that has them. Good luck!

Bonus resources:

• Basics of user stories and examples, which seems to be the most common type of product backlog item these days.
• When you realize that the user stories on the backlog are too big, you’ll want to split your user stories. I recommend the links from that page as well, especially for Product Owners.