6th Sense Analytics

Applying Flow Time - What to Consider?

This post will focus on 3 uses for Flow Time within software teams –

1. Adapting project and team work flow
2. Virtual team analysis and adjustment
3. 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…

Helping Your Development Team to Help You

There's something really weird about being a member of the IT industry and going to a conference that feels the need to discuss the importance of "innovation." I've always believed a fundamental acceptance in the concept of innovation was table stakes for this game.

Apparently not, though, if the level of discussion at last week's start-up and VC dominated Supernova 2006 conference in San Francisco, California, was anything to go by. No wonder the US is worried about China and India.

It's not just in new business and technological break throughs, though, that people should be concerned. Innovation is a relative concept. Yes, the eggheads at MIT are finding bold new ways to cool super-heated chips, but what does that matter to organizations trying to solve business problems using software or to solve their software delivery problems using improved processes?

To these people, innovation is a relatively small but equally vital affair: it comes in the form of realizing an idea in code or finally solving the bug that kept causing a new application to fall over. Often, though, this level of innovation cannot flourish because there is poor insight into software projects. This means innovators are not receiving the resources they need and problems cannot be identified early, so software projects run late and over budget.

That's where 6th Sense Analytics comes in. We believe a vital component of successfully delivering software is insight. That means, having a view into how your application development people are working so you can know where they need resourcing in order to deliver the day-to-day breakthroughs that allow your company to successfully deliver its software projects on time and on budget.

We provide the data that gives you the information you need to act pro-actively. Our data is unquestionably accurate: unlike some tools, the data you will base your important decisions on is pulled straight from the developers' desktop, not some after-the-fact reporting tool, meaning you know exactly what's has happened in projects, not what someone imagines has happened. Plus, we deliver the data from all the open- and closed-source assets in your application development portfolio, not just one vendors' tools or just a single platform.

Data is important, however at 6th Sense Analytics we give you more. We give you the information that empowers your people to innovate and that helps drive your success.

Why Flow Time is Valuable

At 6th Sense Analytics we have 2 essential data types that represent team effort: Active Time and Flow Time. Simply consider Active Time to represent all work time and Flow Time to represent immersion or focused time.

I think every software engineer understands intuitively the periods where they are in the flow. It’s those periods when you can truly focus on your work without interruption. I'm of the habit of getting up at 5am and working. My most productive period of the day is from 5am - 7am each morning -- even though I'm arguably not a “morning person”. Why is that?

Because of how quiet that time is. I can immerse in my work without interruption. It's also my most creative time. Not so much in getting ideas, but in bringing them forth in code or in my writing. My point is that we've all experienced flow and its benefits. The trick is to track that highly productive state in detail and then expand the periods where you can immerse -- thus increasing your overall effectiveness.

There are 3 primary references in the technical team leadership literature that I want to explore in understanding Flow Time and its value -

Tom DeMarco and Tim Lister discuss immersion time and software team productivity in their classic exploration of software development leadership in Peopleware. In it they explore the importance of knowledge workers (programmers) to be able to immerse in their work. They speak in terms of increased productivity, but also creativity in creating software and solving the inherent problems in that endeavor. It is the latter that truly intrigues me, as software engineering is about solving problems -- in the most creative and effective manor possible. Flow truly enhances this ability.

Tom DeMarco has also published a recent work entitled Slack - Getting Past Burnout, Busywork, and the Myth of Total Efficiency. In Slack, he makes a much more compelling case against the management myth of work time equaling efficiency and productivity. For example, which do you think is the more efficient team?

a) The team who works at a level of 30 hours of Active Time with 2 hours of Flow Time or

b) The team who works at 20 hours of Active Time with 10 hours of Flow Time

I would venture that the latter is the more creative and truly productive, even though they are physically working less hours. Slack covers other aspects of efficiency and I'll probably focus on them in a later post.

Mihaly Csikszentmihalyi has written a book Flow and another Creativity that explore the psychology of discovery, creativity and invention. While not focused solely on software development or programmers, it applies perfectly to our realm. He also touches on the attributes of enjoyment as it relates to flow:

1. There are clear goals every step of the way
2. There is immediate feedback to one’s actions
3. There is a balance between challenges and skills
4. Actions and awareness are merged
5. Distractions are excluded from consciousness
6. There is no worry of failure
7. Self-consciousness disappears
8. The sense of time becomes distorted
9. The activity becomes autotelic

And you can clearly see that many of these attributes map quite nicely to software development effectiveness, while also leading to work enjoyment and satisfaction.

As a team member, group leader or manager, you want to drive your team into the flow as much as possible. When you first install 6^th Sense Analytics you’ll want to encourage each engineer to analyze their Flow Time; looking for patterns of productivity and creativity across the week and trying to understand the drivers for them. You'll also want to look at flow from a team or project perspective, again, looking for the same patterns.

In both cases the goal is the same - to increase your Flow Time by changing your work patterns and behaviors to enhance your productivity, efficiency, and creativity.

Fun stuff like timesheets and…

It's hard to miss Apple's new advertising campaign. One of the recent editions really caught my attention. The PC was describing the "fun stuff" he can perform, and he mentioned "timesheets." Of course this is completely tongue-in-cheek.

Timesheets are not fun. It's interesting that of all the "un-fun" things a PC can do, Apple chose to lead with timesheets. [BTW, I would have chosen "doing taxes," [but that's just me.] I wonder if their hourly employees use them. I certainly haven't met many people who like filling out a timesheet.

However, timesheets fulfill a necessary function -- they account for money. Human capital (or time as we like to call it) costs money. Timesheets account for it.

So it's obvious why they exist and are necessary. Why aren't they fun? Honestly, they typically result in someone getting paid for something. Getting paid is fun -- yet not the timesheet.

I think it boils down to a few issues:

• It's really hard to remember what happened. Unless you are uber-anal about doing time-tracking every day, it's tough to remember what happened a few days ago -- especially when you are immersed. There is scientific evidence that when knowledge workers are in the flow they have a distorted sense of time.
• It's a necessary evil. Ultimately, filling out a timesheet doesn't contribute to the outcome. Most people get their fulfillment from accomplishments. For me, it's building and selling software.

We think that we can help out in this area. While I don't think we will make timesheets or a PC "fun'" I know we can address some of the pain encountered when filling out a timesheet.

We have the data on where the time was spent eliminating the deep thought about what happened last Tuesday at 10:36AM. Hopefully this data will enable folks to get timesheets out of the way quickly and return to what they love -- accomplishing something.

More Adjusting…

In my last post we explored an example of using Active Time, by project / team, by activity type to explore whether a teams' effort is balancing appropriately for a given project. We’re going to extend that example to cover a specific methodology.

In this case, our team is using Extreme Programming (XP) for development – so they are Agile in nature. They actively pair program and subscribe to TDD principles. Iterations are 2 weeks in length. When we analyzed Active Time / workflow over the iterations we noticed the following patterns for a “normal” iteration:

There are several things we can use this historical trending for. First, we can place some risk triggers in place for subsequent iterations. For example:

• If we’re not below 30% in Analysis & View Active Time by iteration day #3, we may have a problem. In this case, we’re lagging behind in understanding the work technically (research time) or getting sufficient story (requirement) clarity. In either case, it indicates a progress problem that the team needs to be aware of.

• If debugging time exceeds 35% at any time during an iteration, check with the team at a daily meeting as to what might be the root cause. Between us, it might indicate:
• Inexperience on the part of members of the team – struggling to implement difficult or complex features
• Many incoming defects from testing (unit, acceptance, and others)
• It might indicate tools or technology inexperience within the team

• If testing ever gets below 20% of team time, check with the team at a daily meeting to ensure they're not compromising product quality for speed. This might become particularly evident during the last few days of each iteration.

Of course there are other risk triggers that could be set, but you get the idea. You shouldn’t set too many though, just ones you consider significant for a particular iteration, then adjust as you move forward.

I should mention that you’ll need to modify your interpretation of the data in a paired programming environment. In this case, only one of the pair will be tracked at a time – so the recorded Active Time may represent the effort of two.

Part of your adjustment reaction should be correlated to the amount of historical data you have from the team. If you’ve only stored a few iterations worth of data, then clearly you don’t want to overreact to the trending. You instead want to observe and learn the general tendencies. However, if you have many iterations and truly have consistent trending, then your adjustments become nearly self evident.

Next topic discussion:

I want to switch gears a bit and discuss piloting with 6^th Sense analytics…

Learning to Adjust

In my last few posts I presented the Explore – Discover – Adjust model and MAQ questions for 6^th Sense Analytics data analysis. Now I want to explore the most challenging aspect of the model—the Adjust phase. What makes it so challenging? Having the wisdom to determine:

A. How much change to introduce at one time?

B. For how long?

C. How to determine the effectiveness of the change?

D. Then how to guide further analysis and more adjustments…

I’ve learned the hard way that I’ve got an early adopter mentality as a leader. This drives me to try new things easily and to take a whole lot on at one time. This tendency finds its way into all aspects of my work—even when making adjustments. Given that tendency, I need to be cautious when initiating changes. Care should be taken not to take too many on at once or to assume that the organization can tolerate high levels of change all at once.

Good metrics programs need to be incremental or iterative in nature. They are part of creating a learning organization that is continuously adjusting and improving its practices. Also, as your technical, team, and project landscapes change, the same adjustments don’t always work.

Here’s an example:

• You notice that you’re team has been spending 75% of their time in coding activity for a specific project. The chart in this case is Active Time, by project / team, by activity type.

• MAQ’s in this case, point you towards analyzing:
• Is this percentage normal for this current phase of the project?
• Comparing this percentage against other activities, is the balance correct – again for this phase of the project?
• At an individual team member level, what is the variation between Min and Max?
• Is that variation of concern, more so at an overall project variance level (for risk)?
• Finally, are any adjustments in order?

• Let’s say in this particular case, the project is just beginning. Requirements are ill defined and the Business Analysts are working feverishly to write system use cases. Given that level of clarity, a 75% level of coding might be very excessive. Possible adjustments or actions to take might include:
• Investigate where the coding is occurring and ensure that requirements are reasonably clear in those areas. If not, then perhaps the construction needs to be slowed down a bit. Then, if the development team is truly “idle”, perhaps they can assist in requirement definition?
• Check if the balance of the development effort is right. If this were an Agile team, you should reasonably expect more testing time to be occurring and that 75% coding indicates a general process break.
• If you do find it to be an issue, determine what level you should be at? And also try to predict when this level might be expected? That will help you to create visible triggers for the Active Time data within the teams’ normal workflow.

In this example, the focus was on development team work balance relative to where the project is in the methodology or SDLC.

Next topic discussion:

Another example for adjusting…

Taking the Time to Pause & Think

In 2001, Anna Allison coined the term Metrics Analysis Questions or MAQ’s in an article in STQE (now Better Software) magazine. MAQ’s fit quite nicely into the Explore – Discover – Adjust model in that they can guide your thinking as you explore the data.

In essence, MAQ’s are simply lists of predefined questions. You can also think of them as heuristics that guide your exploration and discovery activities. There are two important aspects to MAQ questions.

First, they help ensure that you don’t overreact to superficial aspects of the data. Instead, they drive you to deeper and broader analysis. Instead of looking for a specific conclusion based upon specific details, you’re looking for meaningful trends and patterns.

Second, they are tailored to your environment – your team, projects, and technology dynamics and historical performance patterns. You build them over time as you make important observations and learn the true nuance of your team and project performance.

Let me give you an example for MAQ usage. Let’s say you notice that Active “productive” Time has declined within a specific project team over the past 2 weeks. Instead of reacting to that specific event, you might want to use the following MAQ’s to get closer to the root cause:

• Are there any active team personal actions that would explain it (vacations, illness, training sessions)?
• Has there been an increase in corporate or overhead activity (increase in meetings, corporate events, benefits sign-up, all hand meetings, etc.)?
• Review trending from a longer term view (zoom out). Is this is part of a cyclical pattern – perhaps related to normal development methodologies?
• Look deeper at individual performance (zoom in). Is this related to a specific team member? Perhaps look into how they may be struggling. Is this expected – or is something else going on?
• Compare the results to the project schedule and planned activities / deliverables. Is this expected – or are the results surprising?
• Along those same lines, is another project having an influence? One starting up or is another project pulling in more resources then planned.

As you can see, MAQ’s require no rocket science. They’re simple questions or heuristics that remind us to examine the surrounding situation so that we correctly interpret the data. Oft-times they lead to further questions and analysis.

What I really like about them is that they cause me to pause and think – so that I don’t overreact to the data after an initial glance. Something you never want to do with this level of insight into the inner workings of software teams.

Next topics discussion:

We’ll more deeply explore the “Adjust” part of the model, which is probably the most challenging aspect…

6th Sense Analytics sponsors Gartner App Development Summit

6th Sense Analytics is proud to be a Silver Sponsor of the 2006 Gartner Application Development Summit in Phoenix, Arizona, September 25-27.

From the Gartner site:

"The Gartner Application Development Summit will spell out the steps you need to take to steer your organization in the right direction. You'll learn to sharpen your focus on SOA even more as we dive deep into discussions of agility and speed -- and the new requirements demanded of your management, architecture, infrastructure and people. The Summit will cover the most pressing issues surrounding BPM and how to solve new challenges presented by packaged applications, Web services and much more."

More information about the summit here: http://www.gartner.com/2_events/conferences/ad8.jsp

Seeing Traditional Metrics in a New Light

There is a traditional metrics model that intends to guide metrics definition. It is the GQM or Goal - Question - Metric model. The premise goes like this -- all metrics should start with a clearly defined goal, and subsequently a set of questions surrounding the support of the goal. Finally, metrics are defined to support measurement and attainment of the goal.

Here's an example:

• Goal: Reduce post System Test defects to 50% of the last project
• Question:
  • How many defects were released (pre and post System Testing) in the previous project?
  • How many defects should be found prior to start of system testing?
  • How many defects are found in system testing for the current release?
• Metric:
  • Number of defects per component in the previous release
  • Number of components in this project / release
  • Number of defects found pre, in and post System Test in this release

Keep in mind that GQM is basically an iterative process and it truly helps to focus metrics collection efforts more narrowly towards business goals. This addresses two of the most common problems with metrics efforts -- a lack of a clear connection to business goals and a habit of focusing on too many metrics at once.

From a 6th Sense Analytics perspective, I feel that GQM, while not necessarily bad, is too simple a model for effectively analyzing your data. Why? Because it can drive binary, metrics event triggered thinking when analyzing the data and driving subsequent action. In my experience, software development analysis can not be programmed or managed by triggering events from metrics. There is too much complexity and too many variables to boil it down to a simplistic "if we reach this metric, we are ok or are in trouble" position. Instead, I propose a modified method for 6th Sense Analytics data analysis.

Instead of Goal, define an Exploration phase where you focus on collecting finely grained data from yourself and your team in meaningful time frames. By meaningful, I'm implying sufficient depth and breadth across your project activity. Minimally, that's a 1-2 month sample of data per relevant project.

Next, I suggest a deep analysis step where you ask a lot of questions and truly drill into your data. This is a Discovery phase where you look for patterns at different levels of the data. You also look for internal and external influences as you search for root causes.

Finally, based on your discovery, you'll plan project and team level Adjustments to influence your project direction and guide it towards successful release. The focus should be on small, high priority adjustments that can clearly be observed for their effectiveness.

As in GQM, Explore - Discover - Adjust is a highly iterative and agile process. The emphasis is towards making small, high potential adjustments in real-time. Then analyzing their effect and continuously improving and adjusting as your projects evolve. It's analogous to game film analysis by sports coaches. They're looking for patterns leading towards requisite adjustments that will improve overall team performance. In fact, this analogy perfectly describes our analytics. They're your "game films" as you improve your personal or team performance to that of truly championship teams. While it might sound corny or trite, deep data insight has that capability.

BarCamp RDU

BarCamp is headed here to the RTP area and we are very excited to be part of it. Judging from the wiki it's shaping up to be a very cool event. 6th Sense Analytics is now a proud sponsor of the event. Plus, we'll be sending a few folks from our team (including me, Todd Olson) to chat about AJAX, SVG, and Software Development Metrics. We look forward to seeing everyone at the event on July 22.