Add to Google
Resource Flexibility in The Agile Enterprise
Posted on December 2, 2010 by Dean Leffingwell in Enterprise Rollout, Feature Vs Component Teams, Release Planning, Team PracticesI received this interesting email from a colleague (who allowed me to share it) a few days back.
“I currently lead a project on how to increase our resource fluidity so that we can effectively assign sufficient manpower to where it matters the most, e.g. working on the highest priority items on the backlog. We acknowledge the need for deeply specialized teams in certain areas and that drastic competence shifts are unrealistic, so the change project aims at finding out how many scrum teams do we need to make more fluid? What competences should these teams have, if they are to be deployed on a wider range of tasks? We also need to address change resistance such as designers or managers being protective of their work domain.
I wonder if you have any advice on how to increase resource fluidity and thereafter managing it.”
Best regards,
– Dr. Mikkel Mørup, Nokia Mobile Phones, Experience Portfolio Management
The email also reminded me of a visual on the same topic that I saw recently as well, which went something as follows:
Matching project backlog to team competencies
Even if we have driven the excess WIP out of the system, even if we can match capacity to backlog, even if we have shorter queues, even if we can build working software in a short time box, we still have to rapidly adjust resources to match the current backlog; that’s a big part of what makes us agile after all. But of course, it never really matches. So we constantly struggle to make the best of the situation, and yet who wants to be the epic owner (or project manager) for Epics (epics 7&8 above) or a team member for Team 4 or 5? A number of awkward conversations and suboptimal economic solutions are likely to develop.
To address this problem generally, we need two things:
1) Feature teams, which have the ability to work across the domains of interest (See feature teams/component teams category)
2) Individuals with “T Skills”, i.e. people who are deep in one area and broad in many. (See Reinertsen: Principles of Product Development Flow, W12).
As agile as we hope to be however, this is a journey often measured in years, not weeks or months, and it is sometimes met with resistance from the enterprise, as Mikkel notes above. Resistance can come from:
- individuals who are highly specialized experts, and who may even see their knowledge of a domain and specialty as a form of job security
- managers who control resources associated with a domain and who can be reluctant to share their resources (and implied base of power)
- Individuals or managers who may have lost their technical thirst for “life long learning” and are comfortable in their existing skills and knowledge
- Logistics and infrastructure (CI and build environments, branching structures, etc) that make it difficult to share code bases across teams
I’m posting this as I would like to hear some other opinions on the topic. As a kickstart, however, my initial response to Mikkel went something as follows:
1) Make the objective clear. It is product development economics that drive us to this particular change vector, and in the end economics wins (or loses) the game for every enterprise. Make the business case based on economics of agility and flow.
2) Make the value system clear. We value feature teams and T skills the most highly (yes, we value component teams too; but even there T skills are an asset). Embed the value system in the performance review/appraisal system to eliminate ambiguity about our expectations for individual career growth and advancement.
3) Adopt XP like practices and values (simplicity, pair programming, collective ownership, single code line, etc.). Hire people with experience in these areas.
4) Attack the infrastructure unremittingly. The technical blocks must be eliminated or the rest of the change program will far less effective.
For you other enterprise agilists out there, do you have thoughts and experiences that you can share?
Fantastic post – this reminds me of some very similar changes we faced a while back as part of our large scale agile transformation. In our case, we were coming from a very heavy waterfall driven culture to an agile based model. The reason I highlight this is that the question asked by Mikkel was the same issue we faced. However, in our case, it was actually a root issue of the organization not wanting to go through the proper transformation to ultimately be successful. I am not sure if this is the same situation so I’ll cover what was happening and then I’ll move on to some thoughts on Dean’s suggestions…
In our case, the organization was accustomed to middle management making commitments on behalf of the teams. Resource planning and actual release commitments were NOT done by the teams themselves and instead, were accomplished in regular meetings that treated the prioritization of features based on interchangeable FTEs. Group A has 10 resources and therefore I can do 10 resources of work for this release. The resource assignment and trading that occurred was based on a category skills vs. a given team structure. While this worked great on paper, it ultimately led to a very bad situation… Management would hand over committed features to teams who were then expected to deliver the work. The teams would look up and wonder what happened because either a) they didn’t have access to the right people or b) they didn’t feel the original commitments were accurate to begin with! Stated differently, resource planning and feature commitment was done by management on behalf of the team. This is a bad situation and not one that exists in a healthy agile environment (regardless of size).
What had to change in our world (and I can’t honestly say it’s fully happened) is that the estimation and prioritization process had to shift away from management and to the teams themselves. The good thing is that they are perfectly willing and capable of doing so. In fact, they are more likely to do it right AND they will retain ownership of the commitment which is a critical step when it comes down to doing the actual work. Furthermore, it’s almost a natural outcome when teams are executing in a mature enough fashion to manage their backlog effectively…
In my next comment, I’ll tackle the situation with a different view and I’ll assume above isn’t the issue we are talking about…
Now for part 2… I want to provide some general thoughts…
Ownership – this is really the # one issue I believe you have to solve for. In a model where you leverage interchangeable resources, you have to think about who will ultimately own the work that is getting created and in the future enhanced. For this reason, I feel it’s best to align features to teams while keeping the teams as static as possible vs. adjusting resources to meet the feature needs
The added benefit of this approach is that the team will continue to get more and more efficient AND you also have the ability to measure their performance over time. If you continue to adjust resources and affect the teams in the process, you start to lose the ability to hold the team as a whole accountable. For example, when something breaks, who fixes it? The next available resource or the person that originally designed and owned it?
If you must adjust resources, do it with a longer timeline in mind – we found that teams that were shifted around generally took an entire release to get efficient again so we ultimately tried to keep teams structured in a similar manner for at least two releases (about 4 months). Furthermore, if the backlog of features for a given area exceeded the capacity of a team to deliver the functionality in time, we added a new team to the mix to deliver the same type of features. This team was generally managed by the same product owner as the first team and was often seeded with one or two individuals from the first team. This allowed you to maintain the optimal team size, increase your backlog capacity and maintain ownership – which is really what I want to stress is the most important.
If a team ran out of things to do, we favored giving them more responsibility vs. taking resources from the team and reallocating them elsewhere…
Long story short – agile isn’t really about software development. It’s about highly efficient, collaborative and effective teams who delivery in a highly visible fashion partly because they act and execute like a well functioning family. You mess with the family and you unfortunately impact the productivity of the family. Ownership is a critical, critical component.
Last but not least – if your existing infrastructure prevents you from sharing code or prevents you from being agile itself, you will fail. Infrastructure is vitally important to the success of a true agile environment. That’s why Scrum gets such a bad rap now a days – it’s a great process but many folks look at it as only a process vs. a portion of the overall solution. In fact, the team I manage today is only allowed to execute in one week iterations (realize this isn’t truly lean but we have a hybrid model). The reason they are only allowed to execute in one week iterations is because they are forced to address infrastructure issues faster. If they can’t develop, test, document and deploy effectively, they fail. Our goal is to measure success based on what we deploy vs. create. We still aren’t great at it but we are getting better every day. What’s important is that we are committed to our infrastructure…
[Part 1. Real Story] Dean and I clearly remember a team of 14 people (two scrum teams, a bunch of real C++ top guns) that delivered brand new product in brand new (for them) technology – java – in just 6 weeks. This is exactly how much time they needed to get “Friends and Family Beta” out of their way. And since then delivered a number of releases never failing a single delivery date and always implementing priorities to satisfy product management. This is just one of the examples that may reveal a couple of interesting things in respect to the subject of this post…
[Part2. Reasons of Flexibility] Based on what we were encouraging in teams and what on the contrary we didn’t support much, here are major observations:
1) Extensively use spikes. A team that wants to be flexible should develop strong culture of working and thinking in spikes. Why? Because a) spikes (be it technology of functional spike) always helps individuals to clearly state and achieve objectives by any efficient means, and these might not necessarily be within their current technology stack or skill set; b) spikes encourage creative thinking that leverages many things including transition to new technologies or “areas of requirements”. Now, there is always more than enough need for spikes on any project, so it is easy to start “today”.
2) XP practices, more detail. I agree totally with item #3 in this post, but few words on that. Sometimes it is hard to adopt pair programming for it may be too big a culture shift for the team. What is quite easy and efficient and I suggest many teams to do it is: spontaneous pair work paired with rotation. In reality this means: people work for approximately 20%-35% their time in pairs and work on one area of functionality for 2 weeks max. On one hand this introduces a way to share all new knowledge and approaches very fast (pair programming) and master new pieces fast (rotation). This subject alone though requires a full-fledged post to be properly outlined…
3) Real results vs tools. Encourage achieving results, not achieving “tools”. In that team a person who would invent a new efficient way of indexing our data that would let us index more documents, or proposed important change in design that would boost system performance, would get recognition and good bonus. This (actual results) we valued much more than, for example, someone getting his or her java language certification or something alike. While any certification is good thing alone, teams should develop an understanding that results is the key and they get certified (or not) only if they think they need to acquire a better “tool box” to achieve better results (!), but not just in order to be a certified java or dot net programmer.
4) Learn fast with Refactoring. I put this practice separately just because of its huge significance. Devs that refactor very often can grasp new areas much easier. They immediately start playing with code (as part of their learning process), they “see logic and design behind lines of code” much clearer. On the other hand if enterprise encourages refactoring and all divisions have it as part of their culture then when someone “inherits” code from another person, it will most likely be good refactored code that is readable and understandable which also shortens learning time.