Agile used to be a buzzword. Either you were IN or you were OUT when it came to understanding the “agile” model. Today, agile is still alive and well, and driving some of the most innovative development teams in the world. Of course, there’s probably an agile 2.0 model that we don’t even know about yet, but looking at a few of the agile processes can help us in any aspect of team leadership, project management, and even self-leadership.
For the first agile team I was part of, the Daily Standup meeting was the key to the entire process. We had a small team (2 developers, 1 writer, 1 creative, 1 account manager) that made up the bulk of the company. And one of the founders of the company, a developer, brought showed us how agile could make our work more pleasant, more trusting, and a lot more efficient.
Here’s how we did it.
1. Morning standup. (flexible timing between 7 – 9 am – after all team members had arrived)
Process: each member of the team states what they are working on, what they hope to accomplish for the day, and what they are struggling with.
What the standup does is puts everyone on the same team and with the “known objectives” of the team at the start of the work day. If someone has ideas about any of the issues, they can be mentioned at the standup and taken into discussion after the meeting adjourns. If one of the team members is constantly missing their objectives, or doesn’t know their objectives for the day, this gives leadership some visibility into the problem and immediate opportunities for repair or replacement of that team member.
2. EOD Standup. (flexible timing between 3 – 5 pm – when the first team member requests to leave)
Process: each member of the team states if they accomplished their daily goals, what they will work on overnight or begin anew tomorrow.
Again, if a team member is constantly missing their objectives at the EOD standup meetings, there is an opportunity for support and adjustments.
3. Iteration Meeting. (every other Thursday, we would have an accountability and forecasting meeting)
Process: Look at the cards (tasks are written and described on cards) and see how close the team was to meeting expectations and estimates of time spent. Assess the upcoming task and reshuffle the cards and time estimates based on learnings and any changing priorities.
In the iteration meeting every team member got to evaluate and report on their own successes and failures based on the work completed. And everyone got to hear each team member’s explanations and reassessments of work to be done or recently completed. With this data the team becomes a learning organization. Expectations and estimates of effort required to complete a task can be reset based on new information. Tasks (cards) can be moved around the next two week iteration plan based on updated priorities and requirements.
I’m wondering now how agile could be used to manage and firm up someone’s personal output and goals?
The last concept from agile that I want to cover today is Velocity. Here’s how that works.
- Create a task card and assign a number of hours required to complete it.
- In theory each individual would have 40 hours of work in them, IF their velocity was at 100%. Of course, the theory of 100% velocity is helpful in setting the goals, but ACTUAL velocity is estimated at 50%.
- So assigning 20 hours of your time to a task, means it is going to take you the entire work week to complete.
Sad, but the actual velocity numbers can be worse than 50% unless you actively guard against things like meetings, email, phone calls.
Today, I will have two standup meetings with myself. I’m curious to see if these agile leadership principles can be useful in managing my life, as well as my teams.