The online panel discussion, "Building Software in a Flat World," stimulated a tremendous number of questions from the audience. Some were answered as part of the panel discussion. Others that we could not cover will be answered right here, front and center, for all eyes to see. This first set of questions are answered by 6th Sense Analytics co-founder and CEO, Greg Burnell.
Read More
Continued from this post...
The execution section of Fowler's book is about day-to-day activity—how you're delivering value to yourself, your team and your projects. The emphasis here should be at the team and project level. Fowler suggests that sometimes we get wrapped up in ourselves and expect everything to revolve around us, which can cause our overall performance to decline. Instead we should be focusing on the quality of our job and deliverable—daily. Loving what we do, even the maintenance or drudge work, and truly embracing our profession. What a concept!
Other good points he makes relate to not burning ourselves out with overtime and learning to say "No" more often, and learning how to fail. Failure implies that we're stretching ourselves and taking risk—that we're trying to do things outside of our comfort zone and that with each failure comes a later, more experienced success.
Read More
Despite the quirky title, Chad Fowler has written an essential read for today's developer:
My Job Went to India (And All I Got Was This Lousy Book) 52 Ways to Save Your Job
Fowler's book is a Call to Arms for software developers about what it takes to succeed in a flat world in which technical skills are globally transferable. He attacks the complacency that I see so frequently in software teams complacency that surfaces in engineers who think that their contributions and their value will always be self-evident. He points out a potentially fatal blind spot in the developer community: an unwillingness or lack of recognition for the need to continuously change, evolve and expand their skills. Today's professional developer must have the deep skills of a specialist, together with the breadth and soft skills of a business generalist. The combination is compelling, powerful and utterly differentiated. And it is the future.
Read More
The debate about sending IT work overseas has moved out of the political arena and turned into economic and structural discussion. This piece from IT News crystallizes that debate by talking about some of the mistakes organizations make outsourcing and some of the common challenges.
Outsourcing typically goes wrong when delays occur, you get poor-quality programming, and support and operational costs increase. These problems crop up when there’s a lack of skills, planning or infrastructure to manage the outsourcing relationship.
This paragraph in particular stood out:
“Most companies looking to outsourcing or distributed development continue to have unrealistic expectations or insufficient processes and infrastructure to adapt to this new development paradigm. Many simply adopt inefficient manual processes (e.g. more meetings, more travel) to manage the challenges of distribution, or turn away from the problem altogether, unable to see a viable, short-term solution to solve the pains of distributed development.”
That’s important because it gets to the heart of the issue: innovation.
6th Sense’s hosted an online debate this week on building software in a flat world. Among the points raised… the need to innovate and add modern practices to a discipline that’s hardly changed for decades.
Metrics are a vital component of any modern process because they help you establish a real-world infrastructure to manage outsourced projects. Metrics that are captured at the developers’ desktop in particular are the key to progress. They let you know what’s really going, so you can conduct due diligence on your current infrastructure and establish metrics to manage the new relationship.
As Delphi Group founder and Smartsourcing author Thomas Koulopoulos said during our web cast, these are early days for taking this modern approach, but things are clearly changing. Koulopoulos characterized it as the birth of printing: “We are at the very beginning of making a true science of application development and automation technology. We like to think we are much further along - [however] we are at the stage where Gutenberg invented the press rather then Heidelberg mass presses,” Koulopoulos said. Bring on the industrial revolution.
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:
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.
