For a long time, I've been fascinated from afar by Agile programming practices, which have proven themselves on all these levels. I've wondered why they haven't been adapted for use by all types of teams, because they hold the potential to make teams far more flexible, innovative and productive.
So here's my shot at adapting those practices into four simple principles that all business teams can use. My hope is that they can help teams both execute and innovate in an excellent manner. I'd also like to acknowledge that Toria Thompson helped me develop some of these ideas.
This is a work in progress - I welcome your comments and will be happy to embrace any suggestions you have that further strengthen this approach:
Value the value: Too many teams operate without clear metrics, and thus they end up making fuzzy decisions. This is a slippery slope to disappointing results. Instead, teams should assign a tangible value to every deliverable, and – this is the important part – teams should track and validate these projections as work goes on. In this manner, team members can’t game the system, inflating values to give their pet projects priority treatment.
The philosophy underlying this principle is simple: businesses exist to make money, and if a project doesn’t support that goal in a tangible way, the team shouldn’t be doing it.
- State the value of each project.
- Create metrics that quantify the stated value.
- Validate the value actually delivered, and reward team members for it.
Look at the way your team currently operates. Is the purpose of every action crystal clear? Do you know why Lisa has been locked in her office for three days, or why John is conducting 32 interviews this week?
Clear and open communications have immense benefits. It should be obvious to everyone who is doing what, and why. When team members get stuck, they get help faster. When they succeed, others follow faster.
- Avoid private communications.
- Conduct disciplined weekly progress report sessions.
- Hold daily “stand-up” sessions (you stand to keep them short).
- Use images, mockups, etc. to make things clearer.
- Make it easy to understand the purpose of every work product.
The longer a team works before delivering a tangible result, the more likely the deliverable is to fall short of expectations. A far better approach is to break large projects down into smaller pieces, and to regularly complete deliverables.
By shortening workplans, teams also make it easier for team members to explore new strategies and take risks. This is because the cost of taking a risk and failing is minimized; you lose a week instead of six months. This tactic also maximizes flexibility, because at the end of each project the team can decide what to do next.
- Shorten the length of time between deliverables.
- Try to make every deliverable useable and functioning, rather than just a description of something that still needs to be done.
- Whenever possible, make processes and deliverables reusable and adaptable for other purposes
This is the best way to get a team to function like, well, a team. It also fosters insights, flexibility, and resilience.
- Create shared metrics.
- Partner team members from different disciplines.
- Have members with similar skills swap tasks often, even in the middle of working on a deliverable.
- Share responsibilities, ideas, concerns and alternatives.
Bruce Kasanoff is a writer and speaker.
Image credit: photo by Flickr member VisualPanic.
by:Bruce Kasanoff
No comments:
Post a Comment