My previous post focused on engineers taking the time to understand the time related to their personal work patterns. However, in today's environments we're heavily multitasking. I hear this over and over again from engineers. Rarely is it the case that they're working on a single project.
Instead, they contribute to many efforts. And their time is often interrupted across them. It seems to be a side effect of today's economic climate that teams are understaffed and overloaded. Managers and project managers seem to take pride in the fact that they're operating "lean and mean" within their teams. In small teams and start-up environments this almost seems to be the modus operandi.
Clearly I'm not implying that all of these cases are bad. In fact, economics should come into play within teams. And the assumption that there is one bit of focused work for every engineer is clearly flawed. However, there is another factor involved here. These teams not only think they're operating quickly and frenetically, but they also think they're operating efficiently and effectively as well. I would respectfully challenge the latter points.
In their breakthrough work Peopleware (and I've quoted from it more than once in this blog) Tom DeMarco and Tim Lister explored the impact that multitasking has on knowledge workers (your) productivity. They spoke in terms of 20% productivity hits for each additional project that was added to an engineer or team of engineers. Each time you switch your focus from one project activity to another, you perform a context switch. Depending on how often you switch and the durations of the switches, you'll potentially lose 20% of your time per additional project.
In our early experiences, we've seen many teams that average about 60% Active Time within a week. Given a 40 hour work week (I know, who does that nowadays) that means that a typical engineer is coding for 24 hours. Using the Peopleware assumptions, if we now introduce a three-project multitasking scenario on that engineer, they will lose 40% of that time to task switching, bringing their Active Time coding down to 15 hours.
6th Sense Analytics™ data won't necessarily help the engineer avoid multitasking. As I said, it seems to be a pervasive practice. However, you will be able to capture and illustrate what multitasking is actually doing to your personal productivity within your team. The data will lead you to impact conclusions that you can use to adjust your own work patterns, but also communicate to your leaders adjustments they might want to make at a project level to improve overall efficiency.
This broad level of project impact analysis and partnership with your leaders is a change for most developers. It requires a bit of extra effort to look across your projects. It takes a bit of courage to go out on a limb and challenge current project and work practices. But in this case, you're using data and real impacts to drive the discussion towards productivity improvements. I think most managers will get that.
There's another broader view that you can take with this information. Often in heavily multitasking environments, little thought is put into the priority of the work. It's more important to react to the moment and often team members can be focusing in the wrong areas or doing things in the wrong order from a high level efficiency perspective. I'll give you an example.
Your manager tells you that Project x is your highest priority, Project y is next and Project z gets the remainder of time. They also specifically tell the team to spend at least 50% of their overall time on Project x. This sort of time balance is important to meet project commitments for the three projects. Well that's all well and good, but how well do you and the team actually meet this direction?
In this case, you can actually review your own data and then step up to look across the project as well. Again, remembering that you want to partner with leadership to make a broader impact, you can provide workflow and balance guidance across your team.
Quite often teams think they're supporting overall project multitasking priority properly, but when you look at the data, the real driving factor might be the loudest customer or the first task to hit you in the morning. No wonder it's so hard to effectively multitask and meet project goals.
So to wrap up this blog series, I hope I've motivated you to start really analyzing and understanding your personal and project level time. Step out there and really make adjustments on what you see. Your projects will love you for it. And your career might get a boost as well. Happy hunting!
I do quite a bit of teaching, both in public and on-site classes. One of the most common challenges I get to suggestions for trying new techniques is this:
"That would work in a perfect world, but I'm barely staying afloat with the work I have to do. How do you propose to solve that problem?"
It bothers me on one level because the implication is that the rest of us live in a perfect world� immune to the ravages of time pressure, multi-tasking, unbridled demands and occasional blinding chaos. Nothing could be further from the truth. Personally, I feel that I've had a healthy dose of all of these. As a consultant one of the things I pride myself on is my connection to and my experience with reality.
However, I choose not to allow the daily frenzy to totally drive my behavior. You see, I feel that even in an absolutely crazy environment, we still make choices in how we will behave. We can be victims or take a more empowered perspective. It's all up to us and the point of view we select. I know this might sound like rubbish, but it's really true.
It takes WORK to actually take control of your time.
Once you decide to choose empowerment, the next step is slightly more difficult: Where do you begin to change your focus? How do you gain insight into the chaos to make the right, high impact changes that will create momentum towards more effectively managing your time?
It really starts with data. I'll give you an example. One of the first things that PSP training asks of software developers is for them to keep a discrete log of the activities for a period of time � say a day. The point is to capture where your time goes throughout the day so that you understand the nuance of your development time and specifically where time is being invested.
Usually, some shocking revelations occur. For example, "What do you mean I�m only coding for 17 hours a week!" or "Jeez, I'm doing pretty well when you consider the meetings, status reports, design session, HR reviews, etc. that sucks up over 50% of my time!".
One of the other revelations from the exercise is that there is no way any engineer in their right mind will keep track of their time manually. While they see the tremendous value, it�s simply too painful and time consuming to do it. Out of this very dilemma of how to unobtrusively collect meaningful time data came the foundations for 6th Sense Analytics™ tools and approaches.
6th Sense Analytics painlessly collects data so that you can peer into it and see what happened to your day. In exhaustive detail you can tell -
Exactly how many interruptions you had
-
Exactly how long each one was
-
How long it took you to recover from an interruption � to get back "into the flow"
-
Or whether you lost the flow for the afternoon
-
You can also correlate your time spent with your productivity
-
How much code did you produce
-
What testing did you do, for how long, before checking files back in
-
And on and on�
Are these insights free? Of course not. At times, you�ll have to review your project task commitments, look at your Outlook calendar or check other activity artifacts as part of your analysis. You'll also need to pull things together -- looking for patterns of good and bad practices and habits that are part of your own personal work behavior and/or your environment.
So again, 6th Sense Analytics data is not a silver bullet unto itself. But it does provide data that a curious, insightful and dedicated software engineer can use to truly understand their where their time goes and take action to adjust their work patterns to change and maximize their time investment.
Continued from this post.
In my final blog post in this series, I want to explore conversations related to exploring 6th Sense Analytics data with an eye towards developing your Personal Improvement Plan. Here we'll look at contrasting your personal data against group data:
Group Analysis
Virtually every suggestion I made in the last post can be extended towards comparison with your teams' and community data. Everything should be focused towards seeing how you stack up against the group in a constructive way. Look for strength areas that you can leverage to increase your contributions, project impact and overall visibility within your teams.
Remember that the data can also serve to support your performance in personnel reviews. You can use it to drive powerful discussion within your leadership team regarding your project contributions and capabilities.
Beyond the analysis points in the last post, there are some unique perspectives you can gain from analyzing broader data. You can extend your vision beyond that of an individual contributor by taking interest in more broad issues across your projects. This broader influence can often be rewarding and add significant value to your projects.
Realize that your value isn't solely tied to your direct contributions. You can also make a big impact by showing your awareness of the big picture. There are several ways to do this. One is by analyzing Project Active Time by Activity from a group perspective. Look for trends that indicate how the overall project is performing or how the team is supporting the schedule.
For example, you can view group Active Time velocity and map it against the project schedule. If you see some trends that are of concern, bring them to the attention of your boss or the project manager. The same analysis can be made from a methodology perspective. For example, look for code construction or testing activity percentages to align with your specific SDLC. If you find the work not aligned with your process, raise a flag for analysis and a readjust.
Compare your performance data against the team. Look for areas where you clearly are ahead of the team norms, for example, in breadth of technology used, or tools capabilities, or simply delivering quality work. Look across the team for those who are struggling in your strength areas and try to mentor them towards improvement.
Believe me, this sort of unselfish mentoring will get noticed--within the team and by leadership. The more you can engage the team in overall improvement and strengthening the stronger you will develop solid leadership skills.
- Another area to make a difference is by analyzing how the overall team is performing within the project from a Flow Time perspective. 6th Sense Analytics data can be immensely helpful in providing insights into the internal dynamics of your team. Look for areas of improvement and serve as a catalyst for changes to improve productivity and efficiency.
Remember that increasing your value and skill isn't solely a technical pursuit. In My Job Went to India, Chad Fowler makes a fairly compelling case that many programming skills are becoming quite commoditized by the global economy. In order for us to grow and thrive, we need to reframe ourselves in different directions. Of course while also leveraging our natural strengths.
Taking a broader view to software development projects from a methodology and leadership perspective is another way to shift your value proposition. Consider this when you're crafting your Personal Improvement Plan.
Continued from this post.
In the final two blog posts in this series, I want to explore two conversations related to exploring 6th Sense Analytics data with an eye towards developing your Personal Improvement Plan. In this one, we'll first look at analyzing your personal data:
Personal Analysis
It usually starts by analyzing your projects. Analyze each project you're working on by average Active Time by file.extension. This will explore the technology mix associated with the project and start to sensitize you to where you�re spending the majority of your time specifically by technology type.
You'll want to compare this against two things: Where you thought you were spending the majority of your time and where �the project� thinks you're spending the majority of your time. You're looking for disconnects or gaps. Also look to see how these percentages map to your strongest technical abilities. For example, if you're core strengths are developing low level J2EE server code and your spending 90% of your time writing Javascript, then you are clearly not leveraging your strengths. You should look to migrate towards your strengths.
Beyond the technology part is workflow or work balance. I think of this as the question that asks: (1) where are you spending the majority of your time; and, (2) does the mix reflect where you should be spending the majority of your time?
In order to sort through this, you'll want to look at relative Active Time by Activity across all of your work and probably also by specific technologies and tools. You're looking for patterns in this case. For example, what is your average balance in pre-development (analysis, research, TDD), development (coding), and post-development (unit testing, debugging, check-in) and is it appropriate for the sort of things your team is building
One thing I think is truly important is to check your overall effectiveness--not in terms of counting lines of code or other module-level counting. Instead, I'm talking about understanding how adeptly you're able to focus by analyzing Flow Time. You'll want to fully understand the dynamics of your personal Flow Time per day of the week and over specific activities. For example, are you more likely to get into the flow when you're coding versus when you're testing? If so, you might look for opportunities to improve your testing focus by perhaps changing offices or working from home.
While reviewing your personal metrics is a significant aspect of how you'll grow, it's only part of the insight puzzle. You really need to see how you stack up against your team, organization, or overall community. That's where we're going next...
I left off the last post discussing the need to be receptive to feedback. Following from that is the revelation that feedback can come in many forms.
Another revelation from my early career is that feedback can come in many forms. Written, verbal, what's said and even what's unsaid. Even verbal communication has nuance from the words, to the intonation, and the associated body language. Did you know that the rough percentages associated with those bits are 10%, 40% and 50% respectively? Surprising isn't it? But it does explain why we have so much difficulty communicating by e-mail.
With the introduction of 6th Sense Analytics, feedback now comes in another form. You now have access to two very powerful layers of performance data. First, you'll gain access to your own development patterns via Active Time and Flow Time measures. You can use this data to fully understand the nuance of your own development patterns�gaining insight into your strengths and weaknesses.
But that's only half the equation. In order to truly accelerate your impact on the organization, you need to compare yourself against it and the industry. In that way, you can understand the breadth of your gaps and the core strength and competency areas that you bring to the table.
As I said in the beginning of this series, strength amplification and finding opportunities in your work to leverage your strengths effectively should be your prime directive.
How can 6th Sense Analytics help you here? First you can compare yourself against groups within your own organization. While we mask out (intentionally) individual characteristics, you can gain tremendous insight into the dynamics of your teams and organization--looking at how you stack up.
We're also aggregating data from all of our clients. Part of our vision is to create an ever increasing community of shared data that can be analyzed for insights across technologies, organizational models, software development methodologies and even continents. This is truly the sort of community data that will allow for comparison against the industry.
How do you leverage such information?
I can think of some clear steps. First is using it to refine your Personal Improvement Plan. You have one don't you? This is the plan that does the following:
- Assesses generally your specific professional / technical strengths & weaknesses
- It identifies the core requirements for your current position
- It does a gap analysis on your current role versus your strengths�looking to determine if you�re in the right role
- If you're not, then there is an Evolution Required section where you explore the right positions for you that amplify your strengths and a roadmap to make the transition.
Data in your PIP should be gathered from all of your traditional and now 6th Sense Analytics data sources. In the 6SA case, you'll want to gather personal, immediate team and community views towards performance that mirrors your primary focus.
In the next few posts in this series, we'll walk down two conversational scenarios where we interrogate 6th Sense Analytics data for PIP planning and mapping. As in the old Project Management adage -- you get what you plan for�
In a recent pair of posts on Creating High Performance Teams, I put the onus on the group leader or manager to develop their teams by truly focusing on and amplifying the team's strengths. However, that's only one perspective to it. It's also incumbent on today's software developers and testers to commit to understanding and improving their own skills.
The emphasis here truly is on understanding your performance, your strengths and weaknesses. Even more importantly are two other considerations:
- How do you stack up against others at your project team level?
- Are you in a job that accentuates your strengths? Where you truly make a difference?
Going back to my blog entry on creating high performance teams, I want to again reiterate that success is not about schlogging to improve your weakness, as Buckingham and Coffman eloquently and compellingly point out. And please don't construe this as a license to ignore your weaknesses. It's not. Instead though, true excellence and true difference making is gained from finding your strengths and amplifying them. To quote the Army, to "be all that you can be" should be your goal.
But there is an important first step to consider. How receptive are you to feedback?
First, Be Open Minded to Feedback
I remember when I first started as a development group leader my boss pulled me in for my first performance review. In my particular case, I'd always been a pretty fair developer, which led to the increased responsibility of leading a small team. I took my coding very seriously and really worked hard at my craft. I guess I was also a bit of a perfectionist.
Given that, I didn't like to listen to criticism and usually construed anything outside of positive feedback to be such. So during my review, I received some great comments -- keeping in mind that I'd just been promoted.
However, we also began to explore areas where I could improve. Sort of picking at my contributions on recent projects and using them as examples. From my point-of-view, he was simply nit picking--searching for anything negative to comment on because he had to point out improvement areas somewhere. I became quite animated and agitated by it all. Ok, I became defensive and somewhat argumentative.
We finally closed what should have been a very positive meeting in a very negative manner. We were both frustrated and the tension lasted for quite some time. What's the lesson here beyond the fact that I had some growing to do? At least for me, it's that it takes effort to properly receive feedback. However, it's crucial that you learn to do it well.
In performance discussions, if you aren't open minded and receptive to feedback--literally from anyone--your boss, your peers, your project manager, and your team--eventually they'll stop giving it to you. It's simply not worth the effort to give it. However, this is the worst possible scenario. Your performance gaps will still exist; just nobody will be talking to you about them.
So what's the point here? As you'll discover in later posts in this "series," I'm setting the stage for your learning from your own performance. However, in order to do so, you need to be receptive, inquisitive, thoughtful and willing to take action to change your focus and adapt to feedback. As illustrated in my example, this isn't always as easy as it sounds�
Continued from S Curves within 6th Sense Analytics
I've been so focused on looking at S Curves from a work perspective that I forgot to illustrate their flexibility. Simply put -- they really can be applied to nearly anything that examines cumulative work over time. Another good software centered application is for testing and defect trending.
Defect Discovery Trending
If you think about it, project defect discovery should also follow an S Curve for any given release. You'll get a flat period as the software is turned over to the testing team for initial Smoke Testing and acceptance. Then you should see an acceleration period as defects are discovered. Finally, there should be a settling period as the testing phase is concluded.
What's interesting here is that we're not viewing work, but actual defects. And in this case, we're viewing total defects found (the work in this case) over time. The same interesting rules apply. For example, you should very well see similar S Curves for early testing cycles as opposed to late, pre-release testing cycles. Early ramp-ups might be very rocky as the testing teams gain familiarity with new features, while later ramp-ups should reduce in time.
You should also see different acceleration levels depending on where you are in the development lifecycle. Again, if you're testing early software, you should see slow acceleration and even more flat sections as you encounter show stopper or test blocking defects. These should certainly disappear as the testing cycle and product matures.
Read More
Continued from "S Curves - An Introduction"
In this post I want to map some of my ongoing S Curve discussion to 6th Sense Analytics data. The reason I�m bringing up S Curves in the first place is I feel they are a solid complimentary tool for traditional project tracking and management. Additionally, using Active Time as your project work indicator is particularly useful because of its accuracy and relationship
to true project work, as it naturally filters out much of the noise associated with the work.
I want to share a couple of Active Time S Curve charts from real 6th Sense Analytics development work so you get a more concrete feel for their format and usefulness.
Individual Project Team Member S Curves
Chart 1 illustrates a 3 team member effort that was focused towards server level work within the 6th Sense Analytics engine during a 2 month period of time. While there were 3 engineers physically assigned to the work, as you can see, Peter is the only fully engaged contributor. In fact, if the project assumptions had all 3 contributing at the same rate, then this chart would indicate a resource dilution or diversion from plan.
So this chart is useful for verifying resource assumptions at a more gross level as they contribute to the project and you can clearly see the S shaped curve for Peter.
Chart 1 - click to enlargeProject Based S Curves
As you saw, the individual S Curve view to a project displays the nuance for each contributor. However, an equally powerful view is seeing how the entire team is contributing, and subsequently how well the overall project behavior matches your expectations. In Chart 2 the 3 engineers are rolled up into a project S Curve for the same period of time.
Now keep in mind that the roll up in the example is not that spectacular because Randy & Todd were not contributing very heavily during this time interval. However, if there were a team of 5 contributing fully, you�d see a fundamentally different (cumulative) picture.
Chart 2 - click to enlargeLonger Duration S Curves � Repeated Cycles
As you extend the duration for the S Curves, you see the curves cycling or repeating over time as the Analytics Server project gets worked on by the team. In Chart 3 below you see the same teams� contribution rates increase over time, with Randy and Todd starting to increase and Peter�s actually tapering off abut thru the middle of 2006.
If you examine their cumulative trends you�ll see individual S Curves represented within each. For example, you see flattening periods around April 9th and May 14th that surely represent completion of specific work items. In order to figure out exactly what they were, we�d have to cross reference against their plan details.
Chart 3 - click to enlargeChart 4 represents the same time period and engineers, just at the project level. It�s a bit simpler here to see the ongoing project S Curves as the project progresses through several development iterations.
Chart 4 - click to enlargeOne of the reasons I�m so bullish on 6th Sense Analytics data is the cumulative power of Active Time views for generating S Curves. By toggling between individuals, technologies, and projects and adjusting your durations to cover interesting project milestones, you can create and extremely powerful project management view into your work and progress!
This post will be continued�
In my last post I introduced the notion of S Curves as a mechanism for managing projects. While it's not as exact as tracking to a schedule, it does provide meaningful patterns for determining project status and progress against historical baselines. It's also a quick way to analyze and gain visibility into the workings of your projects.
Project Start-up and Close-down
As we discussed, the initial flat period in the S Curve represents the start-up of your projects. The final flattening period represents the project closing. You should monitor your project start-up and close-down durations and notice a similar period for most efforts. Also become familiar with the average number of days it takes your team to ramp into a project, taking note when you exceed or surpass this average as performance indicator for follow-up action.
Project Acceleration
Project acceleration is the period of focused work in most projects. The S Curve clearly represents your work acceleration and accumulation over time. I like to compare my acceleration across similarly scoped projects, using a historical project as a baseline and then compare my current project against it. Depending on the results, again, I might see some troubling gaps that indicate a lack of expected forward progress or even a premature flattening�loss of acceleration. All of which would cause me to take a more detailed look into the dynamics that created the change.
Overlaying Milestones
By themselves, S Curves give you a graphical sense for progress. When you compare them against any historically similar projects as baselines, they can also give a comparison point to look for performance gaps. However, you need to overlay appropriately detailed project milestones (plans) against them to truly manage your projects.
For example, if you planned for a new project to begin accelerating after 5 days and it has taken 10, then you clearly have a problem. Many things could have contributed to this.
- You might have a new team that is struggling with tools or technologies for the given project and just not coming up to speed as you expected.
- You might have had a delay in resources joining your project from another project as planned. Heck -- you might look at the other projects S Curve to gain a feel for when you'll get your folks�
- It could also be that requirements have not been sufficiently finalized for the team to begin actively creating content.
You get the idea as to the possibilities. The S Curve gives you a quick indication of a problem that you need to sort out for root cause and then rectify. They also can give you a quick indication as to how effectively you've corrected the problem and how well you're accelerating through it.
Keep in mind that you can and should contrast your project S Curves with planned data (milestones and baseline expectations) and historical S Curves from similar projects (scope, complexity, type of work) in order to gain a feel for how well you are stacking up.
Read the next post in this series.
Project managers often track project schedules and milestones as a mechanism for managing the project and detecting risk. The monitoring is usually at a task level of detail and often quite labor intensive. As it turns out, there is another mechanism for monitoring project state. While it�s not at the finely grained level of detail as the individual task, it does provide wonderful insight into the nuance of a project.
You see projects have a tempo to their development that is usually consistent over time and that can be represented graphically by plotting cumulative effort vs. time. The tempo usually takes the form of an S Curve which represents the normal ramping of a project.
S Curves Defined
An S Curve is a graphical display of cumulative cost, value, labor hours or in our case Active Time vs. time. The name derives from the S like shape of the curve, flatter at the beginning and end and steeper in the middle, which is typical of most software projects. The beginning represents the typical slow, methodical start to projects, as the team sorts through the work and determines how to approach the project. The end represents a deceleration as the work runs out and the middle is the acceleration period as the team attacks the work.
Other Terminology
Often S Curves are used to determine project variance according to a plan. In this case, a Baseline S Curve is established from the initial project plan, for example for hours. As the project continues, natural changes occur. These are then mapped as the Target S Curve, which represents all new, approved work beyond the initial baseline. Finally, the Actual S Curve is graphed cumulatively in real-time for the project. The comparative differences between the 3 curves, Baseline, Target, and Actual can shed interesting details on progress and challenges within your project.
Figure 1, provides an example of these curves. In this example, the curves illustrate growth in Baseline to Target�in other words, expansion of the originally planned scope.
figure 1
Tracking Progress
While analyzing Baseline S Curves can be interesting, the real value comes from comparing Actual against your expected Target S Curves. Target in this case can be assumed to be your planned level of progress.
Comparison of the Target S Curve and Actual S Curve reveals the relative progress of the project over time. In most cases, the Actual S Curve will sit below the Target S Curve for the majority of the project. Towards the end of the project the curves should converge and meet. If the project is ahead of schedule, the Actual S Curve will rise above the Target S Curve. However, the Actual S Curve can never finish above the Target S Curve.
figure 2
Acknowledgements
The 2 graphs in this post were references from Midori Media which produces an S Curve graphics plug-in for Excel.
Read the next post in this series »
