Monday, January 19, 2009

Dr. Scrum: Agile and Making It Work in the Real World (Part Two of Two)

In the real world of Agile development, you may be pulled a thousand different ways - and not just by development. Here's a few tricks I've learned to make working with an agile team a bit easier.

1. Plan your stories and epics in advance. Even though the development team is looking at the user stories on the very near horizon, plan a roadmap for what you will be working on over the next 4 quarters. By documenting a high-level iteration plan, it will inform the team on what's coming next, and will help you make adjustments when new user stories are requested. What I've often done is write out high-level user stories several iterations in advance in a spreadsheet (not the acceptance tests- yet). That way I can look at what's coming 5 iterations from now, in both managing my time, and making changes to iterations as they are needed.

2. Keep User Stories Lightweight. At Yesmail, user stories are very simply and include acceptance tests. That (for the most part) is it. By keeping them straightforward and clear in the acceptance test, you'll have less questions from engineering, and more time for managing the product.

3. Be Flexible in the Outcome. When you write user stories and acceptance tests, you probably have a fairly good idea of how the product will look in the UI. My advice? Allow there to be several solutions to one user story - and choose the best as a team. There's nothing worse in really hampering creativity than a product manager with a 'my way or the high way' point of view. That being said, do ensure you communicate the users needs and technical expertise well, so the users needs are well understood.

4. Assess ROI and Market Need. Set time aside to validate your roadmap and backlog with ROI and market need. In my experience, nearly all developers are 'okay' if I communicate that I need time to ensure the user stories are in line with market demands. Practically speaking, this means that I try to make myself available for a few hours to help with product development, but I do say "I will be working tomorrow morning from 8:30-11:00 on a revised market assessment(or other product management task)." Most developers are okay with with working with your schedule.

5. Ensure continual communication about development estimating. In planning the roadmap, I've worked with several development teams to ensure realistic timetables for a product roadmap were communicated. The roadmap answers two questions 1) What do we need to do (and why?), and 2) When do we need it? Ensure that development is on board, and plans for product iterations are realistic. For me, there were standing weekly meeting about iteration planning and estimating. This helps in both building trust both with development teams and executives.

6. Use Steering Committees to Validate the Backlog. What has helped tremendously in agile is monthly explicit communication to the executive team about what's coming in the next few iterations and what's in the products backlog. This may be contained in JIRA, or a confluence page - or a spreadsheet. What's most important is that the team knows the scheduled priorities of the product, and the order in which they are released.

7. Enjoy the ride (and the people you work with). Agile is about daily communication and collaboration. Soo... get to know the development team well. Soon you'll be making a great product with a development team that delivers great solutions and superior products. Agile and agile methodologies are likely to be here a while. So buckle up and enjoy the ride!


  1. This is a not-so lightweight comment regarding number two, Keep User Stories Lightweight

    Borrowing from "User Stories Applied" by Mike Cohn, who borrowed in turn from Bill Wake, author of "Extreme Programming Explored", a good story should have six attributes.

    Value to users or customers

    Notice they form the acronym INVEST.

    Independent means a story has as few dependencies as possible.

    Negotiable means that it is not a written contract, but instead is designed to generate discussion between the developer and the product owner.

    Value to either the people using the software or buying the software.

    "Estimatable" means that the developer can estimate how long it will take to turn the story into working code. There may be challenges to this. If the developer is not familiar with the domain, then some time needs to be allotted with the domain expert. If the story is too big, then it they make break it down into smaller pieces.

    Small means they shouldn't be too big. Although they shouldn't be too small either.

    Testable means you should put in some high level acceptance tests as passing its tests proves that a story has been successfully developed. They also provide some guidance to both the developer and QA regarding the expected behavior.

  2. The idea behind Agile Development seems to have been around for a long time... The notion of co-location all project resources... Rapid Action Development (RAD)... and the Rational Unified Process were all different flavors of what we are labeling as Agile.

    Do you think that we'll have another flavor development soon and will be merely be Agile with a new name?

  3. Could be. I've been working with modified version of XP, Agile, Scrum, but there are always new ways of working that will speed innovation.