Continued from:
http://www.6thsenseanalytics.com/blog/posts/702/
Principles Revisited in a Metric-Driven & Self-Directed Context:
1) Know more about the issue than anyone else in the organization
Instead the ENTIRE organization has general visibility into the issue. There should be general consensus on its existence and many should have knowledge. The key challenge usually becomes determining what to do next?
2) Grow a small number of like-minded allies
Very little need, as this should occur organically as the inquisitive nature of the team increases with the metrics visibility. Like-mindedness comes from examining, analyzing and changing based on metrics counsel.
3) Initiate a grassroots effort to begin educating a wider base of colleagues
If anything, you can initiate wider engagement by brainstorming and analysis around root causes of the issue and perhaps even looking for trends supporting change or adaptations that might work to resolve it�much more quickly and proactively than trying to make a case and garner support.
4) Practice before going on stage
Forget practice and forget the "stage." The stage is your metric-driven organization and everyone is a player in this production. Not only a player, but an engaged, proactive, inquisitive, and empowered player!
5) Make sure your goal is to help the organization rather than to attack individuals
One of the neat things about letting data and metrics drive the discussion is that it naturally becomes more of a systemic discussion than an individual one. You won't (or shouldn't) attack any individual whether it be team member (us) or stakeholder (them), both are unnecessary and inappropriate.
6) Claim your personal power
There is something wonderful about metrics data�particularly in the Metrics-Driven team. It sort of speaks for itself. Now some can chose to ignore it or not take it seriously, but the team will generally detect and adapt. Instead of personal power, it becomes team-based power.
7) Timing is critical. You need to choose an effective time to speak truth to power
Timing IS indeed critical, but not in this context. In the metrics-drive context, you want to see performance in REAL-TIME. Then make immediate, team-based, trend-based, adjustments within you efforts. Then LOOK for effects of the change and any need for adjustments.
8) Be respectful
Of course. But also be pragmatic and insightful and call it the way you see it.
9) Offer options, including the "do nothing" option
Options should be driven incrementally from the analysis and your ability to adjust and check results. This should drive some courage into the organization that circumvents the "do nothing" option. Metrics-driven organizations should never "do nothing"!
10) Be humble and egoless
Ok. Perhaps I can buy some of that. But adding to it, the team should be inquisitive, ever vigilant, data and metrics driven, incrementally forward focused, looking for insights, empowered to make changes, always checking for the results of change and adapting, and above all—courageous in making bold, metrics-driven changes.
I certainly want to give all due respect to Norm Kerth, his work and this article. Of course I'm not saying that these situations don't occur in today's technology teams. We are always dealing with POWER and there is always the potential for danger. However, instead of focusing our strategies towards that reality, I'd rather we invest in becoming much more metric-driven and team-driven in our interactions with our people, processes, and projects. I'm guessing that Norm might agree.
In the current issue (November 2006) of Better Software magazine, Norm Kerth has written an article regarding Speaking Truth to Power � How to Break Bad News to Those Who Can Crush You. Norm is well known for his book on Project Retrospectives, published in 2001, which is still fresh and resonating well within today's Agile teams as the guide on how to run an effective and powerful project review.
In the article, Kerth discuses 10 principles that help to guide your interactions with power in delicate situations. I'll simply list them to give you a flavor for the content �
Principles:
- Know more about the issue than anyone else in the organization
- Grow a small number of like-minded allies
- Initiate a grassroots effort to begin educating a wider base of colleagues
- Practice before going on stage
- Make sure your goal is to help the organization rather than to attack individuals
- Claim your personal power
- Timing is critical. You need to choose an effective time to speak truth to power
- Be respectful
- Offer options, including the "do nothing" option
- Be humble and egoless
Now I'm a big fan of Norm and his work. However, these principles strike me as being a bit "old school." There is an overwhelming implication that the principles apply to us (team members, colleagues, the powerless, etc.) in dealing with them (management, "the man," the all-knowing, the powerful, etc.) when it comes to the inner workings of things in technical organizations.
The reality is that we'll detect broken things—things gone awry or about to go awry—that management won't be privy to and really don't want to hear. You see, management is often bent on hearing good news only—they often operate under the self-deceptive notion that all projects complete successfully on time, on budget and with the obligatory celebration.
If there is ever a need to burst through that bubble of nirvana, than one needs to proceed very, very carefully. (I almost envision Elmer Fudd making this point :-)
However, if you turn this view around and reframe it as a situation in a metrics-based organization—one that values visibility and team-based empowerment—then the entire article changes.
In this case, everyone has the visibility to see the data that would surround and reflect the situation. Not only would it be visible, but the team and the organization would be reviewing and analyzing their performance transparently, in real-time, and determining next-step progress. If something shows up that is a concern, mostly everyone should detect it—or at least more than a single voice or small, lonely group.
So if we have energy to devote towards change, I would encourage everyone, instead of learning how to Speak Truth to Power, to drive ourselves, our teams and our organizations to more clear visibility into organizational metrics. To learn how to invest in real-time analysis of our project and personal metrics—reviewing our trends, and reacting to our actual performance.
And when we detect an issue that needs attention, we shouldn't worry so much about how we say it. Instead, the very nature of our model is metrics-driven insights that lead to pretty much self-evident performance, issues, adjustment, and then issue resolution.
So let's revisit Kerth's principles from the perspectives of (1) a metrics-driven development organization and (2) from an Agile, self-directed teams. I think it will fundamentally change things and we'll do that in the next post.
Continued in a future post...
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!
This week we heard the death rattle of a dying breed. Vodafone, the world’s largest cell phone company, signed a seven-year application development outsourcing deal with services giants IBM Global Services and EDS estimated to be worth more than $2bn. The companies will also provide application maintenance in eleven countries.
Five years back, mega deals were all the rage. According to separate reports from IDC and Technology Partners International (TPI) last month customers are now signing up to shorter contracts. Five to seven years, instead of seven to 10. TPI thinks we could even see sub-five-year deals. TPI said $1bn plus deals are at their lowest point in four years. IDC said such deals fell 3.1% in 2005. Mini deals are up: contracts worth less than $250m were up to 23% in 2005 from eight percent the previous year.
Smaller deals and more of them - a blessing and a curse.
Small deals mean suppliers must prove value and return on investment sooner than ever before. That accentuates the issue of how to measure and demonstrate value. Traditionally, project reporting software is used with other techniques. This can take time to bed down and fine tune… time service providers no longer have. Such tools are also notoriously bad at providing an accurate picture of events, which becomes a critical liability in short projects.
This trend is creating a growing demand to measure projects using real-life metrics gathered from the developers’ desktop and viewed in real-time. Such an approach provides the immediacy and clarity needed to measure and manage short-term engagements, which are the equivalent of a hurdle race versus the marathon run of mega projects. One minute mis-calculation or oversight in a hurdle race, and down you go - you’ve lost. In the marathon even if you go down, you stand a chance of getting back up, re-adjusting and coming from behind.
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.
Roundtable Includes Global Services Magazine Editor-in-Chief, CEO of Delphi Group, Harvard Business School Professor and 6th Sense Analytics CEO
MORRISVILLE, NC � November 1, 2006 — Offshore development has been embraced by the vast majority of commercial software vendors and enterprise application development groups, supported by the belief that a world flattened by globalization makes it possible to improve competition by taking advantage of low-cost, high-quality technical skills. Unfortunately, despite the cost advantages, the practice of sending development offshore introduces a whole new series of risks and unknowns. 6th Sense Analytics, a pioneer in improving software development metrics, will host a free webcast roundtable discussion on globally distributed software development. The event will feature industry leaders including Rusty Weston, editor-in-chief of Global Services magazine; Thomas Koulopolous, founder of Delphi Group, managing director of Perot Systems Innovation Labs, and author of Smartsouring; Robert Austin, Harvard Business School professor and Cutter Consortium Fellow; and Greg Burnell, CEO of 6th Sense Analytics.
The free webcast, "Software Development in a Flat World," will be broadcast on November 16, 2006 at 2:30 p.m. ET. "As a practical rule, organizations need to be ready to address an explosion of challenges when software development efforts are sent offshore," said Greg Burnell, CEO of 6th Sense Analytics. “Without accurate visibility into software development processes, the decision to send projects offshore can quickly introduce new business risks."
During the free 60-minute webcast, attendees will gain insight into the specifics of what it takes to make offshore or distributed development successful. Articulate, expert practitioners and visionaries will lead a series of thoughtful presentations and a moderated roundtable discussion that will enable businesses to ask the right question when it comes to creating a global development environment. Ten attendees will receive a complementary copy of Smartsourcing, a new book by roundtable participant Thomas Koulopolous, exploring the radical social, organizational and economic impact of globalization and innovation.
"Many IT organizations lack a true understanding of their internal costs and service levels, and just put money into IT because that was the cost of doing business," said Thomas Koulopoulos, author of Smartsourcing, founder of Delphi Group and managing director of Perot Systems Innovation Labs. "Unfortunately, the costs are often buried and there are no benchmarks, so those businesses must know the right questions to ask."
The host of the roundtable, 6th Sense Analytics, offers a powerful and unique solution that arms development organizations with accurate and up-to-date visibility into development processes. With easy-to-use and highly configurable reporting capabilities, teams can quickly aggregate the collected data, clearly understanding development trends, relationships, opportunities and risks across distributed development teams. All of this allows software development teams to improve their ability to deliver successful project outcomes, critical to the overall success of a globally distributed software development effort.
Registration Information
Register for the free 60-minute webcast online at (http://www.6sa.com/webcast/). The event will be held on November 16, 2006 at 2:30 p.m. Eastern Time.
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...
Who works in a learning organization? OK - what is a learning organization?
That’s the subject of Peter M Senge’s The Fifth Discipline, which explains organizations most likely to survive against the competition are those that encourage and capture new patterns of thought and nurture an on-going desire to learn from past experience. This helps repeat successes and avoid failures.
The Fifth Discipline outlines the five steps organizations should take to become smart learners. As the title suggests, it is the fifth discipline that’s the hardest to master: combining all those smaller experiences and wisdoms into one big picture.
Senge’s book has proved something of a management classic since first appearing in the early 1990. However, the book’s message applies strongly to application development. It’s that ability to record and learn from experience gained in previous software projects that is so basic and yet that has proved elusive.
Thinking like Senge’s marries with the 6th Sense philosophy. Giving organizations visibility into projects using metrics and tools helps capture past performance and will help turn IT shops and businesses into dynamic learning organizations.
Importantly, 6th Sense helps make that difficult fifth step - connecting the dots. Senge-like thinking and 6th Sense practice are going to become indispensable as software becomes more critical to the running of business.
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�
