Before you protest too loudly, think back to your last project. If you had to quantify what percentage of project rules of engagement you actively engaged team members in defining, would it be above or below the 50% threshold?
You might argue that as a project manager you are expected to be the subject matter expert on project management practices. After all, a senior software designer is hardly expected to come to you to ask how to design a particular algorithm.
You might feel that your team members would prefer to jump right into their assigned work to reduce the risk of deadlines being missed and should not have to worry about how progress reporting, issue management or team recognition will be performed.
Unfortunately, these are both Theory X views.
A basic tenet of agile project management is that the team should define their work practices and this applies equally well to traditional projects.
I’m not referring to financial or project management policy – that is required to be adhered to. But if your organization’s project management standards focus on what is expected to be done as opposed to prescribing how, have you found yourself defining the standard for your team in many cases instead of actively engaging them in developing those practices?
None of us will want to manage a project in which everyone works however they wish. Self-determination is not an excuse for anarchy! What I’m advocating is the importance of guiding your team through a decision-making process to come up with a common set of practices, then empowering your team members to hold themselves and the rest of the team (including yourself) accountable for following these practices.
Have no illusions – this is not likely to be easy for your team members or for yourself!
For some of your team members, this could be the very first time that anyone has ever asked for their input into such practices and they may lack the confidence to participate fully. For others, they might not understand why you are asking them to participate and might take it the wrong way – “Why are you asking us to do YOUR job?”. Worse yet, others might have had the unfortunate experience of working with project managers who had claimed to support self-management, but then demonstrated through their actions that they really preferred things to be done their way.
Faced with such challenges, a very natural temptation might be to follow the path of least resistance and establish rules. The better approach is to seek to understand – start with asking why and keep probing till you believe you have identified the root cause. Coaching them through their concerns might benefit from the use of analogies or storytelling to help team members understand the importance of self-determination.
For some, a sports analogy might help. For example, a good golf coach doesn’t try to have all of their students execute the golf swing in exactly the same fashion, but rather adapts their teaching methods to the specific strengths and weaknesses of each student.
For those team members for whom all of this is new, provide basic structure by identifying the specific practices which the team will be working on and how the definition process will take place. Once they understand the scope of the exercise and have the opportunity to work with their new team members on defining one or two practices, they will likely be eager to complete the process. Given that most practices have only a finite number of permutations, you could also help to guide the definition process by providing examples for each and letting the team choose which they wish to use.
So when’s the right time to hold such a practice definition exercise? Team working practices should be formed as early in the lifetime of the project as possible to avoid the natural temptation just to impose what you have used in the past. You might want to consider spending a few hours on this during a kickoff session or as a follow-up workshop to a briefer kickoff meeting.
While you won’t be able to entirely avoid the storming phase of Tuckman’s ladder, spending time on norming-type activities very early in the team’s development won’t be wasted effort.
It’s also important to understand that practices will evolve over the lifetime of the project. Whether you run a formal retrospective or not, it’s a good idea to discuss work practices on a periodic basis with the team and have them assess what’s working well and what needs to be tweaked. When new members join the team, it is also a good idea to have them review the current set of practices and provide their thoughts on which might benefit from some fine tuning.
Letting your team members define how work should be done is the first step to unleashing their creativity. Time to ditch the old proverb “A bad workman always blames his tools.”
Don't forget to leave your comments below.