I’m especially pleased to see Forrester analyst Tom Grant applying Agile principles, visibility and collaboration into his own research. Tom’s conducting research on thought leadership in which the entire process will be visible online and the online community can have input into the research methodology.

I’d like to encourage our readers to participate in Tom’s research on thought-leadership at http://community.forrester.com/docs/DOC-3383. He’s already got a great dialog happening on what thought leadership is and how you measure it. Community input will be used to adjust the methodology and outcome of Tom’s research.

This is the third and final post in this Scaling Agile series. I’ve written about the triangle of traps, the challenges of developing complex systems, and smart requirements and intelligent backlogs. In a recent conversation with John Haniotis, VP of Products at Accept, we discussed how to ensure successful adoption of agile methodologies in a large company. John’s experience with enterprise wide adoption of agile (at Intuit) points to two areas to pay attention to:  mitigating risk of organizational change and managing the transition.
(more…)

We find that there is a lot of question as to how Agile teams can help stakeholders and customers in dispersed locations collaborate. We’ll cover information that should increase your knowledge at our Scaling Agile: Smart requirements and intelligent backlogs webinar on May 12th 2010.

Find out who needs to be included in the sprint process to make sure the right product is built and the right priority decisions are made.

Topics to be covered include:

• What are the right “most important” priorities? How do they fit with company goals?
• Are the requirements detailed enough for engineering to build?
• How can engineering validate early on if what they are building meets customer needs?
• How do you manage backlogs for complex systems?
• How do you adjust to changing conditions, understanding the impact of your decisions?

Be sure to register today and add the date to your calendar.

Join us on this important topic!

Just a quick reminder that we have the first of our Scaling Agile Webinars tomorrow April 29th at 10:00 a.m. PT/1:00 p.m. ET!
We’ll be chatting about how developing complex systems stretches the Agile methodology with these challenges:

• Multiple teams are required, they are distributed, and team members are often not collocated
• There are dependencies across teams requiring tight coordination in order to deliver working versions of the system at the end of each sprint
• The scope of platform/architecture work is too big to be part of a functional team effort
• The backlog for entire system is too big to be managed at the sprint level
• How can Agile be adapted to handle these challenges?

Please join us! Register now!

In my past two posts in the Scaling Agile series, I’ve written about the triangle of traps and the challenges of developing complex systems when scaling Agile development. Today I would like to focus on the impact and challenges at the team level when developers and product owners are forced to operate in dispersed and distributed environments – a situation that could impose serious dependencies and may have an impact on other teams.

Three points of impact

The working context of large projects directly impacts team members in three big ways:

• They are dealing with a huge backlog and multiple teams, making it difficult to answer questions like: What is really important? Are there dependencies? Which pieces are locked by contractual commitments?
• The customer is typically not part of the team and in the high pressure to deliver it is easy to loose sight of who wants what we are building, why it is important, and how does the customer expects it to work.
• With multiple, distributed teams and individuals there is much more information to track and things easily fall through the cracks.

How to Break Down Backlog: Strategies

I’ve written about the need to break down large backlogs into tiers, but the big question is how? As backlogs get larger it becomes critical to have a way of defining the weight of multiple prioritization criteria to produce refined, intelligent backlogs. As criteria and weighting change, these intelligent backlogs can be automatically updated. In the Accept360product these prioritization criteria are called “strategies”.



Smart Requirements

Because teams in large projects are not self contained and customers cannot be part of every team, simple user stories are not enough for each team to manage their decisions.  In the rush to complete a sprint, shortcuts are often taken – risking that the end result misses the mark or negatively impacts the work of other teams.   To avoid this user stories need to carry a much richer set of information in addition to the description of the story. They need to be “smart requirements” and include:

• References to the customers who requested the capability, why they requested it and how they expect it to work
• Use cases and definition of affected personas
• Links to the strategies or prioritization criteria that they fulfill, so it’s always clear their strategic impact
• Dependencies from and to other user stories and the teams who own them.

Empowered Team Members Make Informed Decisions

Not being able to deliver an important feature in a release is always painful for me and from what I have seen it’s the same for anybody involved in a project. Some internal stakeholders and customers are bound to be upset. But this approach has helped me make informed decision with an understanding of the impact. It has also allowed me to proactively communicate the impact to the people affected. I find that people tend to be much more flexible and understanding when care is shown about informing them of a change instead of leaving them to discover it on their own and be surprised.

I’d love to hear what your experience has been in this area.