Re-quote du jour


Any process that does not have provisions for its own refinement will eventually fail or be abandoned

– W. R. Corcoran, PhD, P.E., The Phoenix Handbook: The Ultimate Event Evaluation Manual for Finding Profit Improvement in Adverse Events, Nuclear Safety Review Concepts, 19 October 1997.

Improving any process has a few requirements
1) a baseline defining what is actually being done
2) a baseline of process performance
3) a performance target
4) a mechanism to change the process in a controlled way

It helps to have a model and some detailed, step by step data.

You can only know if you have improved when you know not only what changed but also how much the outcomes changed. Sometimes change is big, but most improvement comes from a series of small improvements.

Posted in Uncategorized | Leave a comment

Do you need a serious requirements document?

Some don’t seem to think so,–did-it-deliver-.html

Getting everyone on board still can be an issue, however. “One of my guys keeps telling me that he would like to have more specified requirements. I keep telling him we’re going faster because we don’t have specified requirements,” Weston says. A hardcore requirements document is a “waste of time,” he adds.

When I see comments like this I immediately want to know

  1. what is the domain?
  2. Is your industry regulated or safety critical?
  3. how large is the overall effort?
  4. what other systems does your product interact with?
  5. who are the customers? How many? how diverse?
  6. who are the other stakeholders?
  7. how long do you expect the product to be in use?

Without context, I don’t now what to make of a statement like “A hardcore requirements document is a “waste of time,”. If, for example you are doing embedded systems in a medical device or changing a component inside a bank’s accounting system  I think I’d want the requirements stated pretty explicitly.

Some documents are a waste of time, sometimes they are part of the delivery.   Often they are tool to make communication precise, persistent, distributable  and reviewable.  Context matters.

Posted in Uncategorized | Leave a comment

SEI Webinar, When Measurement Benefits the Measured

With Mark Kasunic and your’s truly we discuss some early summaries from our collected software project data.

Recorded Wednesday April 23, 2014, This will be placed into the archives for viewing at your leisure. Until then, just register for the webinar to gain access.


What constitutes stellar performance and best practice? You can’t really say what’s good or best … unless you measure it.

High-performing athletes rely on measurement to understand and improve so that they can compete effectively and win. Can knowledge workers such as software engineers use measurement in a similar approach? Absolutely. But the measures need to be practical, relevant, trustworthy, and actionable. They need to be used by the individual to benefit the individual.

Join us to:
• see the emerging empirical results of over 100 software project teams that have collected accurate performance data
• learn about the techniques that were developed and used to validate the accuracy of the collected data
• learn how four basic measures can provide close-looped feedback to help software engineers understand and improve their performance

You don’t need to measure everything. It only takes a few basic and easy-to-collect measures to help you and your team manage schedule commitments and software quality. Tune in during this webinar to find out what those key measures are, how you can collect them, and how you and your software development team can use them effectively.

During this webinar, we will share the performance results of over 100 software teams that have carefully tracked their schedule performance and the quality of their work. We will show you how high-integrity empirical results such as these can be used at the individual, project, and industry levels to characterize performance in meaningful and insightful ways.

About the Speakers:

Mark Kasunic
Mark Kasunic is a senior member of the technical staff at the Software Engineering Institute (SEI) at Carnegie Mellon University. He is currently a member of the Team Software Process Initiative within the Software Solutions Division. Since joining the SEI in 1994, his work has focused on transitioning performance improvement technologies into practice through applied research, course development, coaching, and training. His current research and development interests include data quality assessment and improvement, project performance measurement, and practical measurement and analysis approaches that help individuals and teams improve their technical performance. Mark has an extensive list of technical publications and conference presentations addressing software engineering and measurement. Before joining the SEI, Mark was an engineer and manager at Boeing in Seattle. He has a Masters Degree in Systems Engineering and is a senior member of IEEE. Mark is a certified TSP Mentor Coach and a certified Scrum Master.

William Nichols
Bill Nichols joined the Software Engineering Institute (SEI) in 2006 as a senior member of the technical staff and serves as a Personal Software Process (PSP) instructor and Team Software Process (TSP) Mentor Coach with the TSP Initiative within the Software Solutions Division (SSD). Prior to joining the SEI, Dr. Nichols lead a software development team at the Bettis Laboratory near Pittsburgh, Pennsylvania, where he had been developing and maintaining nuclear engineering and scientific software for 14 years. His TSP publications include the the PSP and TSP Bodies of Knowledge, The TSP Coach Mentoring Program Guidebook, and various publications addressing software quality planning. Research publications include an algorithm for use in neutron diffusion programs, design and performance of a physics data acquisition system, and experimental results in particle physics. He has a doctorate in physics from Carnegie Mellon University.

Posted in Uncategorized | Leave a comment

Carpe per diem

“No massive bureaucratic machine that depends on well-timed “heroics” will ever be reliable.”

– Scott Sumner (economist)

Any process that relies upon getting the best people, at best, won’t scale up. A well designed process helps everyone perform better. 



Posted in Uncategorized | Leave a comment

Expanding and sustaining process improvement

On the SEI blog I write about some of our experience at Nedbank. There are two broad categories of challenges associated with scaling process change in general or TSP in particular to larger organizations:

1) The logistics of rollout and sustainment, such as support, training, and resource coordination
2( The change management problem of motivating the staff involved to take on different roles and adopt different patterns of communication

Read about it there.

Posted in Uncategorized | Leave a comment

Building software team performance

My contribution to the SEI technical blog describes what I’ve been up to in Africa. I wrote about a experience with a development team at a bank in Johannesburg.

Check out the video where the developers describe their experience in their own words.

Posted in Uncategorized | Leave a comment

Plan for Success !

My article in Software Quality Professional just came out.

It is available for download if you register. The content is technical, and includes a model I built, but the message is simple.

To succeed in software development, plan for quality. You will almost surely save time and cost. You have to plan because it won’t happen by accident.

Posted in Uncategorized | Leave a comment

Carpe per diem

Science advances one funeral at a time.

Max Planck, early 20th century physicist

A more literal translation might have been

“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.”

Change management is hard. Even when we understand something intellectually, getting it emotionally and actually taking action are very different things. It is as though different parts of the brain were at work.

If you have to change yourself or manage change in an organization, try not to get frustrated because this is just the way it is. Have a plan, create a supportive environment, and try to get repetitions with increasing levels of pressure and complexity, start easy and build up. Under pressure we will revert to our old ways.

Posted in Uncategorized | Leave a comment

Measure and Mismeasure of Man

Regarding a Tenure decision, Richard H. Thaler remarked

“What his résumé lacked was five bad papers.” By that, he meant that while the candidate had published several papers containing enough genuinely important ideas to satisfy any rational hiring committee — more than could be said of most faculty members — he had too few to satisfy the bean counters, who fretted about how uninformed outsiders might react to the appointment.

HT to Tyler Cohen,

Data and facts do not live entirely alone, but within the context of other facts. Decisions using measures without context can lead to management dysfunction as described in Robert Austins book Measuring and Managing Performance in Organizations .

That is not to suggest that using measurement to make decisions is wrong! On the contrary. But getting the whole story takes some work. It is also quite a bit of work to explain just what a measure means. It is no wonder people distrust being measured, they are afraid of how the measure might be used against them.

Posted in Measurement | 1 Comment

How to Write a Good Abstract and Title for Presentation at a Conference

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
Translation: I would have written a shorter letter, but I did not have the time.
-Blaise Pascal

Writing a good abstract and title for a presentation requires distilling the gist of a complex topic into a few short sentences. Poor abstracts make acceptance of the proposed presentation less likely and discourage potential members of the audience who would benefit. On the other hand, a good abstract and title allow the reader to quickly determine the relevance of the topic and provide confidence that the presentation is well structured, informative, and useful. Anyone who might wish to present at the symposium would benefit from following some simple rules to structure the abstract and title. This document lists some characteristics of good titles and abstracts and provides some practical guidance on how to write a good abstract.

The Abstract
A conference abstract can typically include four sections that answer at least four questions. The sections include Background, Approach, Findings, and Conclusion. At a minimum, answer the questions that correspond to these four sections.
– Background: Why did you do this?
– Approach: What did you do?
– Findings: What did you learn or discover?
– Conclusion: What does it mean?

Here are some questions to consider when you’re drafting your abstract. For each section, select the appropriate questions for your topic, answer them, and then combine the answers to create your abstract.

Background (Why did you do this?)
– What is the problem you are addressing? How are things done today?
– What is the difficulty and why?
– Why has this problem not been solved before?
– What did you expect or what is the hypothesis?

Approach (What did you do?)
– What kind of data did you collect and how did you collect it?
– How did you assess the data?
– Who were the subjects? How many?
– Is this a case study? An experience report? A pilot? Did you set up experiments?

Findings or Results (What did you learn?)
– Did a new technique or approach work or not?
– What new information or data is provided?
– What was confirmed or refuted?
– Were there surprises?

Conclusion (What does this mean?)
– What can we now do differently or that we couldn’t do before?
– Who will be affected by these results? Does this apply to team members? Team leads? Coaches? Other stakeholders?
– Will something be cheaper, faster, or better?

The Title
State your take-home message, or key idea, in a single short sentence. The title should accurately summarize the abstract. The title helps to classify your presentation and set the proper expectations. You may use a title and a short sub-title. It is useful to include important aspects of your presentation in the title. For example, a practical presentation might include “How to”. Similarly a research topic might include “Pilot”, “Case Study”, or or “Survey”. Strive for clarity rather than being clever or provocative.

Posted in Uncategorized | Leave a comment