I enjoy talking to General Managers, Product Managers, and other members of a business teams about the benefits of going agile. Their eyes light up when I talk about the basics. They get to see completed product at the end of each iteration, get the ability to change priorities and requirements, and there is minimal up front work developing requirements. They ‘get it’ – speed to market and the ability to adjust to market demands.But I warn business managers that with agile comes some new responsibilities. Below is an incomplete list of some things the Business needs to manage when working with an Agile software development team

1) Expect to spend a lot of time with the technologists! – The agile practice requires a strong commitment from business managers to help set priorities and communicate requirements. In our practice for development on Business Exchange, the technologists meet with the senior business managers no less than three hours per week for iterations that are three weeks in length. This is followed up by many small meetings to help capture requirements with individual stakeholders. It is time consuming and intense.

2) Set reasonable expectations with customers on the scope of product delivery. Agile teams should be good at hitting time lines and budgets, but because priorities and requirements are adjusted each iteration, it’s hard to know the exact functionality that will be available in a future release. That’s one reason creating a vision statement is key. It not only focuses the team on the key deliverable, it also is a tool to help market the product. But when a customer asks about whether a specific feature will be in a release, be prepared to capture the data point (aha, one reason to prioritize this feature) and respond accordingly.

3) Develop a methodology for prioritizing. Agile forces you to prioritize frequently and this can be a hard exercise for business managers if they don’t have prioritization streamed into a repeatable process. Most organizations have multiple stakeholders, so having a transparent methodology makes it easier to keep everyone informed and understanding why Story X is #1 going into Commitment. Still, prioritizing is really hard especially when you get used to frequent releases. Say the team’s iteration is a month and usually handles ten stories each iteration. The eleventh story, the one the team probably doesn’t commit to, will have to wait two iterations (two months) for its completion. Very quickly, Business Managers feel the difficulty in picking the right ten stories/priorities for the coming iteration.

Three more in the next post!