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!