As a leader you may find yourself in the situation of having introduced a new tool. And then maybe you observe that the team doesn't know how to use it. The reason might be that they haven't yet fully understood the underlying principles and so if they hit a road block they might not be able to adapt.
Resist to the temptation of then doing the work for them. It's not worth it and doesn't scale. Instead work with the team and demonstrate to them how the tools is supposed to be used. Then give them another try encouraging them to come back to you for more assistance if they get stuck.
For instance: Assume you have introduced a spreadsheet based tracker (for an example see the Agile Tracker) including a backlog and a burn down graph. One way of introducing this could be to identify a significant portion of the work that is very similar and of which the items can be counted. The resulting backlog may not contain all the full piece of work required. Hence you and your team don't know yet whether the work can be completed on time. Ask them to include every single piece of work that is required. Ask them to prioritize - or if necessary triage - all tasks. If they struggle how to do that, use a few examples to demonstrate the use of the tool (the tracker in this case), then ask them to try the rest by themselves.
I believe this works better than if as a leader you would be involved all way through. Be available when needed. Make sure it is understood that asking for assistance is not a sign of weakness but a sign of strength. Briefly discuss their experience so far. What went wrong? What worked? Then provide just enough to get them going again.
Subscribe to:
Post Comments (Atom)
1 comment:
This seems like a common problem, and I think your solution points to its root. Given the frantic pace of many projects, it has been my experience that each team member will often just 'do' what they think is best, perhaps without consulting the rest of the team. Sometimes, this works well. Other times, you run into the problems you have described, especially if that new tool is likely to have an impact on how the rest of the team will work.
When encountering a problem, perhaps during a retrospective, I believe it is more effective to communicate how a new tool would alleviate some of the team's pain and get buy-in before introducing the tool. If there is skepticism, it can be addressed. If someone else comes up with an even better suggestion that the team gets behind, great. Either way, you will save time and waste by aligning the team before you roll-out something new.
Post a Comment