Applying Flow Time - What to Consider?
This post will focus on 3 uses for Flow Time within software teams –
- Adapting project and team work flow
- Virtual team analysis and adjustment
- Focusing specific, high impact engineers towards project challenges
The first consideration for me in Flow Time is adjusting my overall oject dynamics to create increased flow periods within the work week. I like to review Flow Time at a project level by day of the week. This give me insight into the ebb and flow (pun intended) of the team—or consider it the teams’ biorhythm.
You are looking for peek and valley times of flow on specific days or times within the average working day. Usually teams will have 1-2 days per week when their Flow Time increases. There may also be a daily pattern, perhaps early each morning when the same occurs. You’ll want to identify these places and (1) insure that they remain uninterrupted and (2)look for ways to expand or replicate these conditions more broadly.
Team Flow Time then becomes a critical consideration when scheduling meetings, reviews, training, and other team or organizational activity.
Using Flow Time to Analyze Virtual Team Productivity
You can analyze individual Flow Time as well. One valuable aspect of this is using it in a distributed or virtual team. You can actually determine when individuals are most productive and correlate it with their physical location. You might find that some folks working from home are ultra productive, while others are not. This allows you to influence location changes and patterns that align with increased Flow Time.
In fact, general analysis of virtual team productivity via Active Time and Flow Time is something that 6th Sense Analytics uniquely brings to the table. There’s really no other way to get this level of insight to influence and adjust your overall work location and patterns within software teams.
High Impact Engineer Productivity
While we sometimes don’t want to consider it, teams are made up of individuals with potentially great variance in skills and capabilities. I think one of the central aspects of great software leaders is how they correctly evaluate and leverage the talent within their teams.
One part of this ability is gaining an understanding of the strengths and weaknesses of their individual team members and guiding them towards their strength areas. Another part is then increasing the flow in those strength areas. For example, in my book Software Endgames, I discuss the fact that some software engineers are good debuggers while others are terrible at it.
In the book I allude to detecting these individual strengths and keeping a profile per engineer that will guide work assignments throughout the project and endgame. Unfortunately, this data is more driven from observed or anecdotal activity than from true data.
However, using 6th Sense Analytics, you can actually look at Active Time spent in debugging and testing and then correlate this against defect repair check-ins. Once you isolate your strongest debuggers, then you’ll want to analyze their specific flow patterns—particularly when you are in the Endgame of each release, in order to increase their productivity.
I’ve gone as far as to totally isolate critical team members from interruptions to increase their creativity and productivity in resolving Endgame defects, with great impact to the success of the project. Now I can accurately quantify those decisions and the results.
You could take this same approach with:
- Finding and focusing your best J2EE developers at critical, early iteration architectural development
- Focusing on your most productive engineers when you’re in a final push towards a code freeze point
- Finding the sweet spots for any team member or group when you’re in “crunch mode”
Next topic discussion:
We’ll extend Active and Flow Time to consider the notion of Slack…
Previous Post:
Helping Your Development Team to Help You
Next Post:
Slack Time
