Wednesday, February 15, 2006
Enterprise Architecture, Agile Software Development and the PMO
Several architects within our enterprise have been meeting on a weekly basis over lunch brainstorming our next set of recommendations to move our thinking forward. While we have had great successes in agile software development, we haven't done much in terms of agile project management. There are several things that the lunch crew has landed on that are worthy of further discussion...
Agile approaches encourage iterative planning. Most folks when adopting an iterative approach tend to think in terms of short iterations from the perspective of timeboxes but miss a more important subtle thought that says iterations become focused on features and not tasks.
Project planning on the features that customers believe are important keeps the project team and the customers synchronized (because the customers understand the product even though they may not understand the technical activities). It also
focuses the team on delivering the product vs keeping track of task-oriented details that many enterprises love to waste time on...
Another aspect isn't frequently discussed is that in many shops, business analysts and the folks from QA desire to participate in all technical discussions. Some developers feel that they will slow down the development process if they allow these folks to participate. Reality states that balance is achieved if the QA folks participate on technical discussions and decisions made by developers as they have the responsibility for automating acceptance testing.
Don't forget the forming/storming/norming/performing principle.Although your team struggles more then most, they have to get through the storming phase, and they can only do that on their own. What you could do is find exercises to facilitate the discussions between your two stormers. Sometimes it is better to stand back and let the events take their course...
The main problem though is that in many shops, the notion of letting events take their course becomes siderailed by agendas of program/project management offices and therefore it becomes vital that they too become aware of what agile approaches offer them.Agile development looks like just iterative development to a command-and-control-style management culture. In this style, it is the PMO management who must collect the metrics from below and decides whether any project has reached the point of diminishing returns.
The main problem that enterprise architects ned to start championing is the whole reward system. Of course, if they start with rewards for themselves, it will appear selfish. The key to masterin selfishness is the ability to get what one desires without others detecting this goal. One way would be to champion additional rewards for project managers which will immediately get them on your side.
If project managers were rewarded for understanding their own project well enough to make this decision themselves (or more realistically suggest it to the PMO), then some agility would indeed be percolating up to the management level. In most organizations, a project manager who decided his/her own project had outlived its usefulness would be making a really stupid career move.
Enterprise architecture must deal with people issues in order to be successful. Likewise, it should also have a Bill of Responsibilities along with an Elevator Pitch that is understandable by PMO type folk. Likewise, it is vital that enterprise architecture doesn't take actions that create more Urban Legends.
In the meantime, I figured I would sweeten the deal on a previous post entitled: Where's the WSDL by also adding a $100 contribution to a mutually agreed upon charity to the first person who solves this puzzle...
| | View blog reactionsAgile approaches encourage iterative planning. Most folks when adopting an iterative approach tend to think in terms of short iterations from the perspective of timeboxes but miss a more important subtle thought that says iterations become focused on features and not tasks.
Project planning on the features that customers believe are important keeps the project team and the customers synchronized (because the customers understand the product even though they may not understand the technical activities). It also
focuses the team on delivering the product vs keeping track of task-oriented details that many enterprises love to waste time on...
Another aspect isn't frequently discussed is that in many shops, business analysts and the folks from QA desire to participate in all technical discussions. Some developers feel that they will slow down the development process if they allow these folks to participate. Reality states that balance is achieved if the QA folks participate on technical discussions and decisions made by developers as they have the responsibility for automating acceptance testing.
Don't forget the forming/storming/norming/performing principle.Although your team struggles more then most, they have to get through the storming phase, and they can only do that on their own. What you could do is find exercises to facilitate the discussions between your two stormers. Sometimes it is better to stand back and let the events take their course...
The main problem though is that in many shops, the notion of letting events take their course becomes siderailed by agendas of program/project management offices and therefore it becomes vital that they too become aware of what agile approaches offer them.Agile development looks like just iterative development to a command-and-control-style management culture. In this style, it is the PMO management who must collect the metrics from below and decides whether any project has reached the point of diminishing returns.
The main problem that enterprise architects ned to start championing is the whole reward system. Of course, if they start with rewards for themselves, it will appear selfish. The key to masterin selfishness is the ability to get what one desires without others detecting this goal. One way would be to champion additional rewards for project managers which will immediately get them on your side.
If project managers were rewarded for understanding their own project well enough to make this decision themselves (or more realistically suggest it to the PMO), then some agility would indeed be percolating up to the management level. In most organizations, a project manager who decided his/her own project had outlived its usefulness would be making a really stupid career move.
Enterprise architecture must deal with people issues in order to be successful. Likewise, it should also have a Bill of Responsibilities along with an Elevator Pitch that is understandable by PMO type folk. Likewise, it is vital that enterprise architecture doesn't take actions that create more Urban Legends.
In the meantime, I figured I would sweeten the deal on a previous post entitled: Where's the WSDL by also adding a $100 contribution to a mutually agreed upon charity to the first person who solves this puzzle...
