Agile Program Management: Structure and Behavior

I believe you read my previous post.  In that post I shared a very simple lesson.   I am writing this post to discuss the next one.  It is ‘Architect your team structure and feed your feature teams!'.

 

Let me explain.  Think about a program consisting of multiple projects.  Every project has a structure according to the methodology followed.  Also at a program level there is a structure consisting of various roles and responsibilities in order to manage the program.  Every structure has its associated behavior whether it is at a project level or at a program level. Very true. Any ineffective structure at a program level can have cascading effect on almost all projects covered under the program. Obviously.

 

Hence, the lesson is ‘Architect your team structure and feed your feature teams!

 

One may think, ‘Why feed your feature teams? Why not focus on other areas as well?’ Well, a reasonable question. In my opinion, feeding the feature teams or providing them well-groomed requirements or users stories is the first and foremost need at ground level assuming that teams have required infrastructure, tools and platforms to perform their daily activities.  Providing well-groomed user stories is not the responsibility of program managers. However, being aware and taking necessary steps to ensure that well-groomed user stories are provided to teams is one of their responsibilities of program managers.  When program management teams are structured right and when they ensure that groomed user stories flow from time to time or from iteration to iteration, they get a very good view on what is happening on the ground.  They can do more. They can do more things better.

 

This is an ongoing activity.  Program management teams need to be agile. They need to go through periodic retrospective to relook at the structure and improve it.

 

How can we structure teams? We know how to structure project teams.  How do we structure program teams? We try to do this based on our prior experience or recommendations from an expert or consultant or coach – or both!  However, an important input to this exercise is to find an answer to the question, ‘What kind of behavior do we expect from this team? What do we want them to accomplish?  How do their accomplishments align with program goals?’

 

That is going to be a periodic exercise that may result in structural changes in project teams or program teams by means of role changes – either you introduce a new role, or make some changes to an existing role or create additional teams or something else to make things better.

 

When this happens, and when there is a constant focus on ensuring adequate flow of work, you have put your teams on the right track.

 

Any thoughts?