Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Vikas Hazrati on Jun 23, 2009
Agile projects are known to address the problems of rapid change. These may be changes in market forces, system requirements or implementation technology. One of the change, that does not gel well with Agile projects, is the frequent change of people working on the project. In organizations adopting Agile, this is a common challenge when they want to allocate people among projects. Roland Ceullar discussed a few ways of doing effective resource management.
According to Roland,
Every now and then, we will get the interesting question of how to do "resource management" in an enterprise that is adopting Agile. "How can I allocate people 100% to a single team for so long when we have so many projects going on?"
Roland mentioned that there are 2 fundamental problems in the question above.
He added that people cannot be considered as individual pieces who can be moved around at will. When people are working in teams, they go through the maturity cycle of forming, storming, norming and performing. This takes time. Once the team is performing well, it is usually bad to disturb a high performing team. The idea should be to keep the high performing team intact as long as possible. So, instead of assigning people to projects, it would be better to assign projects to high performing teams based on their capacity and skills. This however, would be different for specialists who would still have to move across projects given their special skills.
A related problem highlighted by Joe Ocampo is the matrix allocation of people. This boils down to percentage allocation of a person across projects. Hence, as an example
Developer UberBob – Is assigned to
According to Joe, he has seen this matrix model work for large RUP based projects but this does not work well in Agile projects. In Agile projects it disrupts the team dynamics, communication and hence the velocity.
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.
For managing large number of projects in an organization, Roland suggested a slow down approach. According to him, an organization should queue up the projects for the team instead of having the team work on multiple projects simultaneously. Given the market and business dynamics this might be difficult to achieve but it helps in the projects getting better prioritized and the desired focus. This way teams would be able to achieve throughput and delivery on selected projects instead of working on multiple projects and focusing on none.
Thus the implicit message is to focus on people. Agile projects would benefit if people are utilized in the best way. Hence, it is in best interest to work projects around teams rather than people across projects.
Agile Development: A Manager's Roadmap for Success
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Every "resource" with which I've worked in 21+ years in IT has been a person... at least in the context of "resource" in this article and how managers use the term.
When I coach teams, I quite literally ban the use of the word resource when referring to a person. It's dehumanizing and leads to the Taylorist view that we're all just cogs in a wheel that can be moved about or replaced without any adverse effects. That thinking has been proven wrong for knowledge workers on multiple occasions - Google for "costs of multitasking" to see for yourself.
As for the last two paragraphs, this is exactly correct. In my experience, organizations always have an optimistic view of their capacity to do work, neglecting potential bottlenecks such as manual testing and mounting technical debt.
Dave Rooney
Mayford Technologies
Completely agree with you, it is people. That is the reason that the commentary that you would find in the post except "quotes" is always PEOPLE and not resources.
The idea should be to keep the high performing team intact as long as possible.
This is an interesting idea. In the 10 years (man I'm getting old) I've been doing this, I've worked with such a team only once and met another. The first team - the one I worked with was very cliquish and (arguably) did not work well with other (teams).
Furthermore, I've heard conflicting advice stating that the essence of a high performing team is not a set of people who know each other and get along, but a set of people who are focused on a task bigger than all of them such that they are completely dependent on each other.
@Dave Rooney - I couldn't agree more. We are no longer even referred to as individuals (Resources) we are simply 'Resource'. Come on, developers are people too :).
Simon,
If we're @Resource, does that mean we can be dependency injected?
I don't think I want that to happen to me. :)
Barrett
Cheers to you, sir. It depresses me to no end that large organizations often intentionally use language and processes designed to dehumanize humans and abstract away the actual products being built. Effective groups of people building worthwhile products are... well... people. Building products. Sadly, in most cases the language used is symptomatic of the underlying culture, and not the other way around.
I think unstable team will doom any agile project to failure - setandbma.wordpress.com/2009/02/25/unstable-req...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply