I can't help but align with sports analogies here. Nearly every sport has the notion of recording team and individual performance so that one can then review their performance and plan improvement strategies. It turns out that these observations are different than the anecdotal feelings one has during the game. It gives you a perspective and view into the reality of your performance and not simply your perceptions of it.
Read More
Visibility alone simply provides data. One can still be disengaged or a back-seat driver with data. However, the agile mindset couples visibility with collaboration and engagement. Stakeholders are encouraged--no almost required--to get in the game and become an active part of the team and participating in all aspects of the project.
Read More
It started as it always did. My boss came into my office --
Bill: Bob, we need you to deliver this new set of functionality in 6 weeks. Our sales are down and we've determined that this release will really make a difference and provide pop on the sales front.
Me: But, Bill. We haven't got a clue yet as to exactly what is required nor how long it will take to deliver it. It will take some time to sort things out and put a thoughtful, accurate plan together.
Bill: Bob, that's why you're here. To work through the tough problems. I need you on board with this and the business is really counting on you. We simply have to do it! And I really mean in 6 weeks, so delivered on April 1.
Me: Alright. I trust your assessment of the business climate. The team and I will do our best and meet this challenge. You can count on us.
Read More
Amongst many events, I regularly speak at software testing conferences. A few months ago I attended a very interesting vendor presentation at a conference in Washington, DC. The speaker was the founder of a technology start-up company who was developing a new genre of testing tool.
He clearly mentioned early in the presentation that he didn't want to be perceived as a snake oil salesman. You see this is particularly important in the testing tool arena because automation vendors, beginning with Capture-Playback features, have been promising effort and maintenance free automation development for years. Truth be told, they've never been able to deliver on the promises and many a tool is collecting dust on office shelves scattered across corporate America.
Read More
Read More
In a recent post on Joel on Software, Joel wrote passionately about management consultants and their tendency to focus on performance metrics when analyzing software organizations. Simply put, he doesn't think that technical team performance can be effectively measured. In fact, he referenced a previous post from 2002 on the same subject–so this is a relatively long held belief on his part. Here's a snippet to share some of his thoughts:
Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.
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
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...
