Matrix Resource Management and Agile
I have been having an ongoing discussion lately concerning matrix management styles and how they conflict with Agile Project Management.
If you look at the traditional “Iron Triangle”, resources are estimated, in that change is expected in the resource allocation depending upon task and assignment.
In Agile resources are fixed throughout the duration of the project and features are variable.
This is a clear delineation into the approach of Agile resource management. Traditional matrices were based off of manufacturing models that do not lend themselves to effectively managing knowledge-based work such as software development.
Manufacturing management relies on technicians to be trained at various activities in their line of work. These activities rarely, if ever, change. So, mastery of these activities increases dramatically with repetition. This is not a bad thing, since tremendous value is gained through the repetition for the business. From a management perspective it is very easy to assign different work streams to one person since the proficiency level of the work environment is not built upon change or adaptability but on repetition and skill mastery.
Knowledge-based resource management understands that knowledge workers are trained professional but the context domain on which their skills are applicable is in a constant dynamic state. Therefore, this forces the knowledge worker to pursue greater levels of training and reconstitute positions of ideology based on experience. This is the benefit of the organization that employs knowledge workers.
The fluidity of communication and thought surrounding a project (especially a software project) forces the knowledge worker to gain greater depth in the problem domain so that they may better serve the business in providing services.
This idea is compounded when you start to manage teams of knowledge workers. The term, “two minds are better the one”, shines in this environment. As knowledge teams ensure business value is rendered and investiture in the project increases, the thoughts and ideas of the whole out weight that of the individual.
As matrix management encroaches upon Agile management the philosophical view points on resource allocation are contrary to each other. Consider the following:
Organization: Gloop Org
• Developer UberBob – Is assigned to
- Project A @ 25% of his time
- Project B @ 65% of his time
- Project C @ 10% of his time
I know this NEVER happens but work with me. The Gloop organization is wanting to move toward a more Agile development approach but is not willing to give up it’s matrix model just yet.
• Project A is in the planning stages and several meetings have been setup to discuss how the new billing system is going to work.
• Project B is knee deep in the second release and velocity has been established for each iteration. The new warehouse system is underway.
• Project C is just finishing up but automated testing wasn’t followed so the team is mainly focusing on defect removal. Defect backlog is high.
Monday:
Bob comes to work and is perplexed to what standup he has to attend since he has input to each one of the projects he is on. He has already been dealing with this dilemma for the past couple of months as he spends the latter part of his day creating emails to send to the project managers of the standup he will not be attending.
The project managers do their best to convey Bob’s work and impediments but usually Bob has to follow up with team members throughout the day to determine what he missed and what issues he has to solve due to the breakdown in communication.
In Project B, Bob is working heavily on how the conveyor system is going to determine what gates to open to ship the merchandise. There is an issue, however, that the team has to figure out because the communication protocol isn’t fully supported for the gating system as originally thought. Several meetings are planned in the afternoon with the development team to discuss the correct course of action.
In Project A, they are still going through several domain modeling sessions to flush out how the billing system is going to work. The billing system model for Gloob is unique and is how the company maintains it’s competitive advantage. They are going to go over the complexities of this system in the afternoon.
In Project C the defects are just getting out of hand. There are several show stopping defects and the team is going to have to determine how they are going to solve these issues before going to production. They are going to get back to Bob on when the meeting is going to be held.
I am not going to go into what happens here but magically Bob is able to pull a miracle and make it to each meeting but he has to sacrifice time and only go partially to each meeting and rely on the meeting minutes to catch him up to speed.
Bob is an awesome developer, he is prideful about everything he does, and works late hours to overcome all the impediments his projects go through daily. The issues surmount when the communication breaks down.
What Bob didn’t know was after he left the Billing System meeting they went into a critical discussion on how the system calculates interest. His fellow teammates estimated that feature at taking days, but in reality with Bob’s experience, it will take months. In the warehouse system the Product owner came in and changed the backlog since the “gate issue” is going to take longer to flush out. So they added other value stories above the gate. But Bob doesn’t know this and is planning on staying late to figure out how to solve the gate issue. Bob was unable to really bring any value to the defect discussion since he came in at the tail end of the meeting. Bob’s teammates weren’t too happy with him for missing the defect meeting.
End of Monday…
I know this never happens in the real world but it is very possible (I say that tongue in cheek). All these projects are at risk because of the matrix model. Knowledge workers need to focus on one context at a time so that we harness the power of their collective thought.
By fixing the resources on a given project and dedicating them throughout, you gain momentum and predictability of effort. Matrix models disrupt communication continuity as well as iteration velocity. As you mix and match resource from project to project every week, you might as well throw whatever velocity you have been tracking out the window as the team dynamics have been disrupted. If you simply perform a one for one swap of personnel you cannot expect output not to be disrupted.
I want to make sure that everyone understands that I am not saying that matrix management doesn’t work. I have seen it work on extremely large RUP projects that lasted several years. My definition of “work” is slightly skewed because the project was less then stellar but the work effort was as fluid as RUP can be.
My argument solely revolves around matrix management and Agile. You can do it but the experience of true Agile will be lost. The people aspect of Agile, which to me is the most critical, will be damaged due to constantly managing frustration based around priority and delegation.
I have always said this and continue to say this, “Agile refocuses management to concentrate on people aspect of leadership. By focusing on increasing quality of life for the employee and increasing knowledge share, the benefits are tremendous!”