Wednesday, November 17, 2010

Performance Reviews - bogus, fraudulent, dishonest, bad management


Performance reviews are a predictable part of office life. Whether the employees write their own, or sit before a panel of bosses, it can be a grueling process. Often, managers only conduct them because they're told to, and workers embellish and obscure their accomplishments and failures. Some business leaders argue the reviews are all but worthless.
Samuel Culbert, author of Get Rid Of The Performance Review!, couldn't agree more. "It's the most ridiculous practice in the world," he tells NPR's Neal Conan. "It's bogus, fraudulent, dishonest at its core, and reflects stupid, bad, cowardly management."
Culbert sees performance reviews as a tool management uses to intimidate employees. "They know what it takes to get a good review," he says, so they tell bosses what they want to hear, instead of giving them "the real story."
Allan Polak, president of ALP Consulting Resources, agrees with Culbert. "It's much more often a nightmare than anything that's valuable," Polak says.
He traces performance reviews back to a collusion between HR and legal departments at companies, "in order to create a written trail when somebody isn't doing their job well." But over the years, "it's morphed into the annual ritual that is inflicted upon everybody."
"Nine times out of 10, it's more harm than good," Polak says.
Polak and Culbert both realize management and employees need a way to communicate about goals and accountability. But, Culbert says, performance reviews are the wrong solution.
"It makes it impossible for people to have authentic, honest conversations about what we need to be doing differently" and what's imperfect in a workplace, he says.
And "if it really is intended to be a valuable conversation for the employee," Polak says, the annual review needs to be wholly separate from conversations about money — raises, promotions or bonuses. That way, the conversation focuses on a boss wanting to help an employee succeed.

ScrumDay Berlin: A Practical Guide to Great Scrum

On 17 November 2010, the keynote presentation at ScrumDay in Berlin was on how to systematically create hyperproductive teams. Slides are available at the link below. Available also is the Systematic Ready Ready Checklist for Product Backlog discussed during the presentation. The talk was based on the Agile 2009 experience report:
C. Jakobsen and J. Sutherland, "Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.

In the field of Large-scale application of Agile, the best data set comes from a CMMI Level 5 company that is providing data collected from over 100 highly disciplined Scrum teams. Based on the lessons found in this data, Jeff will describe how a new team can follow the path of Systematic Software Engineering and double productivity by focusing on "product DONE," then double it again by focusing on "product backlog READY." Current research shows that any team can achieve hyper-productivity in a few sprints, even in a dysfunctional company. This presentation will show the audience how to do it and how easy it can be, if they work to remove impediments.

Tuesday, November 16, 2010

Cost of Defects in Requirements

     Tom Gilb, Jeff Sutherland, Kai Gilb

Requirement defects cause rework. Every defect is a bug that causes extra work. So it is important to check your requirements for defects.

Tom Gilb has an agile one hour workshop that will take a random page of your specifications and identify the number of defects. You can then multiple the defects discovered on this page by the total number of pages of requirements to estimate the total number of requirement defects that you are planning to implement.

Defects are things like:

1. The requirement is not clear to the developer implementing it.
2. The requirement specifies technical details instead of the user requirement.
3. The requirement is not testable.

In a recent paper, Tom describes a one hour workshop with management in a large company. They identified 33 defects in an hour. He has data from many decades of work showing that the first time through you will only identify 1/3 of the defects. If you spend another hour you will find many more defects.

So in one page, many companies have 100 defects. Any major defect has been shown to take about 10 hours of extra work. In one of the examples in Tom's paper he tells the management they have 2000 hours of rework ahead of them. They are surprised and ask him how he knows that. The project team has been working for a year and was supposed to be finished after about 2000 hours of project time. However, they still have another year of work.

So take a look. 100 defects for every page of product backlog items may be slowing your projects down. Tom Gilb. Agile Specification Quality Control: Shifting Emphasis from Cleaning to Sampling Defects. TE Testing Experience. March, 2009. Here is a link to Tom's paper.

Monday, November 01, 2010

8 Lessons Learned from the first Scrum team



A few years back I received a call from Stephen Denning, an Australian author best known for his books on organizational storytelling. Stephen wanted to talk with me about my work at Easel Corporation in the 1990s for his upcoming The Leader's Guide to Radical Management. Until Stephen called, I hadn’t thought much about Easel. But his interview brought all the memories of the “first scrum team” back, and with it a recollection of the lessons I took from Easel.

Background
I worked at the Burlington-based Easel Corporation for over four years in the early and mid-1990s, joining the company out of school and leaving it after its acquisition by VMARK. I was a software engineer on the team developing Synchronicity, a suite of software development tools based on our proprietary Smalltalk environment. I like to call this period of time my PhD in object oriented technology. Long before Hibernate, Ruby and Eclipse, we were building a modern development environment that included a dynamic object-oriented programming language, visual programming editors, integrated analysis and design tools, platform independent run time, two way code generation, object to relational persistence framework, local object store, and more. More ...