Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Build the Team  Build the Team   The Agile Team Ethos   The Agile Team Ethos

If you are asked to organize a trip to the moon, understandably you would not plan a journey with a team of trainee novice astronauts. This is because this type of project can be, to say the least, a little tricky. In all project types the domain experience of your human resources influences the outcomes and the likely success of the project. This domain experience guidance applies to agile projects also.

However, on an agile project, in our experience using The Big Agile Toolkit, you are not mandated to fill your project with resources that are especially experienced in agile techniques. This is one of those fortunate circumstances where the soft skills of the individual make a more positive impact on the success of the whole venture, and on the team, than pure project related expertise.

Therefore, the first obvious optimal quality for your optimum agile team members is pertinent domain experience. This is expertise and knowledge about the business or technical domain in which the project is going to operate.

A blend of experience, a mix of different levels of experience, is useful also. So a team with a mix of people with average, as well as high, levels of pertinent domain experience will be preferred. This is done in order to avoid a particular influence, what we call corporate sympathy and respect, for a historic business dogma or approach.

A suitably merged set of business backgrounds will offer your project a lively coagulation of opinion and contemplation which, in turn, will allow greater consideration, exploration, understanding and validation of the objectives of the organisation to deliver the proposed change. In this way, your project can boot out linear old dogma rather than simply toe the line.

You will need at least a small smattering of personnel with broad agile experience who have worked on an agile project before and would ideally select those team members who have worked on successful agile projects in your organisation before. Of specific interest would be those personnel who played an influential part in the successful delivery of an agile project.


If nobody exists in the organisation then you will need to explore the agile resources marketplace for a broadly skilled agile coach or a broadly skilled agile project manager. We say broadly skilled so that you do not hire someone dogmatically forcing your team and your organisation down a specific agile route with financial burdens of training, one-off templates or a route that demands the official endorsement of specific agile vendors.

Willingness to participate in an agile project is the next optimal characteristic you would investigate and an unsolicited request by an individual to join your project is an indicator of willingness and suitability. If someone has asked or applied to take part then this can be taken as a positive indicator of their enthusiasm and interest. Motivation and enthusiasm are two qualities you will look for in optimal team members and an in-depth interview of the candidates is the way to confirm their enthusiasm and interest. You do this to distinguish the likely positive drivers from the negative passengers.

It is a performance management reality that some people will exhibit, or will be assessed as exhibiting, poor performance and competence failures on projects within your organisation. Negative assessment outcomes will, of course, occur at some point in almost every other organisation too. Such assessments represent that a particular individual is demonstrating a lack of achievement that verifies their deficiency in matching the performance measures demanded by their organisation. This demonstrates their inability to offer positive operational improvement to the organisation. The natural offspring of this process unleashes performance improvement activity to allow the individual to overcome the perceived failings in their delivery capability. An element of this performance improvement activity may involve their temporary, or more than temporary, assignment to another project.

This can be a positive opportunity for individuals to extend their capability and to develop their skillset. Therefore, it is an evident reality that those individuals who are positively motivated to improve, on your project, will prove to be a positive impetus, to your project. However, it is a brutal reality that sometimes these performance improvement opportunities are misused. In this instance, failing personnel on a project are sent for periods to other projects not for improvement but as punishment to the individual or as a malicious intent to manage the person off a project or out of the organisation altogether. However, even this seemingly damaging circumstance can be counter intuitively turned round 360 degrees to assist both the project and the individual.

It is probably an instant response to consider immediately rejecting such people. But, they can be genuine contributors and in some instances ideal for your project. On an agile project, in our experience using The Big Agile Toolkit, you are not mandated to fill your project with resources who would be naturally and positively selected via the established and conventional narrow roads offered by performance management. We said before that a mix of personnel is welcome and advised.

It is certainly good practise to measure the true capability of your intended project team. Nobody would recommend you blindly employ random groups of people or to unquestioningly accept people who you know were sent to your project by project managers intent on punishing you or your new agile project. Wantonly relocated personnel very often carry negative past project experiences and bring these to a project whether it wants it or not. Project team members who are blanket bombed onto a project are not always the most suitably motivated people to join a new team.

This is especially the case when this is a new agile team, breaking new agile ground and hitting that very same ground running straight away. So it is correct to beware and thus seek to delay the arrival of project personnel who are eagerly transferred by other project managers within your organisation. But we bear in mind that poor performance or competence ills on other projects within the organisation do not mean an individual is unsuited to work on an agile project. You must work closely with all people assigned to your project to ensure they are motivated and supplied with support and the resources they need.

This necessity is strikingly important when taking on board individuals who have had poor performance experiences elsewhere or who you suspect have been apportioned to your project for less than genuine reasons. These individuals may have not operated at full performance on conventional projects. This does not mean they are unable to run at full throttle on an agile project. Their previous failings can, of course, be due to a number of influences. It will be worthwhile finding out what failed performance attributes were assigned to the individual, if your organisational performance management data is available. Oftentimes, this managerial markdown was due to what were perceived as unconventional, challenging or questioning behaviours. These are not considered to be negative behaviours on an agile project. Agile projects are perceived as unconventional, challenging and questioning the activity of normal projects so you may see the parallels.

People also need the bandwidth: the time or opportunity to get involved and to contribute. You do not want team members who get involved for a few early weeks only to leave when the serious delivery gets underway. They have learned little and contributed about the same. So it is wiser to avoid these and to select personnel who are there for the duration of the project. Seek and take project personnel who can commit to the length and the pace of the project. The executive supporting this change in your organisation or one of the project team will have to agree to the resources Commitment and agree that the personnel will stay with the project. In this way, you have an important commitment of resource for the duration of the project.

Swapping people in and out of an agile project is a very serious threat to the delivery of the project. Your project will rely on people skills and depend on the delicate finely tuned person-to-person collaboration to minimize wasted conversations and debate. These delicately small interactions are characteristics of individuals delivering in high performance teams. So try to retain these people and seek to find team members who have done this sort of project before, who want to be a part of the team, to bring positive project experiences and have a will to overcome daily obstacles. If you also find people who are swift efficient communicators with the time and space to get involved then you have achieved a great deal. Get them on your team, fast. Help them, coach them and train them to deliver your project. But get them onto your project first to build an agile ethos.

Buffer



 Build the Team     Build the Team   The Agile Team Ethos    The Agile Team Ethos



Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z


#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Optimum Agile Teams






   


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
   
Topic: 47  Page: 47/444  Progress: 10.6%
 About    |    Author 
Follow @BigAgileToolkit


This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.