Saturday, July 30, 2011

Agility and staff organization in large organizations

In the last six to seven year I worked a lot with large organizations - in only a few cases real agile, but we were always discussing how to change towards more agility...

These discussions inspired me to reflect on the staff organization and staffing rules for projects. If you have some hundred knowledge workers in your organization you just have to setup some kind of structure. Question is: What kind of structure is best suited for the organization?!

Contradictory goals and constraints come into play.
  • you have to staff projects and programs with the appropriate skills
  • you have to offer your employees a clear development and career path
  • every staff member needs a boss in the line mangement for several reasons
  • organizations today need a certain amount of flexibility in the size of the workforce so they can adopt to a changing market (or win and loss figures)
  • the project portfolio includes anything starting from real up2date innovation projects to boring maintenance of legacy systems
  • the only thing that is constant is change in your organization
I recognized two core pattern for staff organization. From my point of view these pattern are as following:
  1. The "Pool pattern": Creation of discipline oriented pools of engineers lead be a line manager (the pool head). Typical pools are: business analysis, project management, requirements engineering, architecture, development and testing. Each time a projects comes into life the pool head is requested to send the needed amout of FTE's, lets say 1 PM, 0.5 RE, 1 Architect, 4 Devs, 2 Tester and so on.
  2. The "Application pattern": Each software application has a more or less constant team that has the knowledge to develop and maintain the application. The team sticks to the application as long as the application lives.
From my point of view both pattern have a few advantages but many disadvantages.
The Pool Pattern allows to define a clear carrier and development path for staff members - often well aligned with human resource management and development. An architect runs through these skill levels and trainings over the years and will become an senior architect over the time (if she is able to cope). As well you know in your organization how many of X and what level you have and check that against what you need for expertise in your organization.
But drawnbacks are enormous:
  • You educate specialists that identify with being a specialist. A developer does not know how to test (and worse: does not want to).
  • If a project needs 0.5 RE it get's 0.5 RE in person, i.e. an RE ends up as team member in 2 or 3 projects at the same time. Efficiency of such a poor person tends against Zero, even if she is keen and good. Might not be the case for Dev's and Tester, but for core roles like RE's and BA's I have seen this often.
  • Project teams are just put in place and destructed again as the projects are defined and close down. The knowledge a team builds up to succeed with the specific context of the project is gone. No sustainable path for project work. Efficiency is intentionally wracked.
  • Agility is out of reach. For agile teams you need the multi-disciplin engineer, not the specialist in X. A multi-disciplin engineer typically is very good in A, but good in B and C and - in case nobody else is available right now - will go for D at least sufficient.
The "Application Pattern" is good for efficiency in respect of this application. The team around the application is pretty constant and sharing knowledge. They know how to deal with the dark sides in the application and know how to develop and maintain. Sounds pretty good for setup of agile teams. But in real life I have seen as many disadvantages:
  • Example: The team responsible to create reports with the report application X that is stoneage. These developers are lost for the market. Personal development never took place. Some never realized that and the organization neither. No additional statements needed.
  • The team around the team lead (she is typically the line manager as well) has a strict parochial thinking. A local kingdom with a very strong local king. In case of troubles always the others are guilty. The local king protects but as well closes out his team. Lucky team to have a king with high ethics (I personlly met many of these high ethic peers for there team :-) but others as well :-( ).
  • To push a valuable business request through that touches - let's say - four or five local kingdoms is a multi-battlefront war between business and IT. One reason for the often mentioned and existing gap between business ind IT.
  • Anybody talking about personal development?! Organizations structured like this often buy-in the needed skill-set on the market. From time to time there are re-organizations going hand in hand with payoffs.
  • Interesting aspect: in organizations like this the instrument "project" often lost his meaning. Nobody really can say what a project is, when it started and when it ends. The team is working in a kind of permanent process on its application...
These structural patterns often hinder a change towards agility. The "Pool Pattern" with partial engagement in projects, therefore wrong cut projects and specialists. Inefficiency in the work force, specialists that are not used to work as teams and permanent building up of knowledge and throwing that knowledge just away again.

The "Application Pattern" with local kingdoms. A thinking that prevents business requests to be seen and handled as a whole, thus slowing down time to market. The compensation is installing a huge workforce of business analysts decomposing business values into tiny change requests passed into kingdoms to prevent subject matter discussions with local kings.

Two ways to implement waste. Is there a successful way?

My idea would be a combination of these pattern with a serious change of what a team is responsible for, what an application really is and what a project should has as context, goal and size.

I guess I reflect about that the next time.

No comments:

Post a Comment