Last
post we talked about two facets of communication in the agile
enterprise... constraints and feedback. Constaints flow from the
higher levels in the organization... to give guidance... to constrain
the actions and decisions of the lower levels in the organization. At
the lower levels the agile teams are empowered to make decisions within
the context of the higher order constraints.
Constrants
are established at the right level of abstraction so that decisions are
made as close to where the work is actually getting done. The
constraints of the enterprise serve to establish context... product
ownership if you will... for the independent agile teams. Feedback
from the teams is essential to influence the actions and
decision-making at the higher levels of the enterprise.
The higher order constraints are constantly evaluated against the realities of delivering working software.
At
this point it seems we have a reasonable starting place to structure
our agile organization. What we are basically building is an
organizational framwork so all our agile teams are working toward the
common goals of the business. We are working on a conceptual model for
organizing our agile enterprise so that we can rationally decompose an
enterprise product backlog.
Now let's lay
down an analagous framework... a conceptual model for prioritizing that
backlog and throttling work through the agile enterprise. To do
this... once again we are going to have to discuss a few foundational
principles that will enable enterprise agility...
- Make small bets by approving smaller projects
- Prioritize for finishing projects rather than starting projects
- Work on your highest priority projects first
- Don't start projects you are unable to finish
- Provide support for those teams that are slowing down your ability to deliver
- Establish an enterprise level velocity
Over the next few posts we'll explore these ideas and see if we can identify any others.
I need help! The next level of managers are creating multiple backlogs that are time bond to insure stories are completed in the time.
How do I help them understand this does not allow the teams to pick the highest priority stories?
Posted by: Natalie | Thursday, May 21, 2009 at 04:26 PM
Unfortunately, there are no easy answers to a question like that. You might have them read a book like Agile Project Management with Scrum by Ken Schwaber.
Short of that... just start measuring velocity and communicate actual progress to the management. Put the business in a position to make tradeoffs once you have real data.
Posted by: Mike Cottmeyer | Thursday, May 21, 2009 at 06:50 PM