People vs Process

It’s a false dichotomy.

Glen Alleman touches on several topics in a recent blog People versus Process

one of several I’d like to highlight  is the discussion of people versus process. He points out that one can focus on process, or instead on the people. If you choose to focus on people you can take a couple approaches, get “the best people”, the “A-Team” approach, or strive to improve your average performer “a rising tide lifts all boats”. The best organizations recognize this as a false dichotomy. Ignoring one or the other leaves gaps that cannot be readily overcome.

My go to example is how Herb Brooks assembled the famous 1980 Olympic hockey team that upset the mighty Soviet team. When criticized for not taking some of the best players,  he responded something to the effect “I’m not looking for the best players, I’m looking for the best “team”. By this he meant that he had a vision of what it would take to beat the Red Army Juggernaut. He had a system  (process) that required certain skills (speed, endurance, and tenacity) in addition to traditional hockey skills. Also, it should go without saying, was a willingness to play within that system so that the team could be greater than the sum of it’s individual parts.

This wasn’t the “A” Team, but they were perhaps  the “A^-”  or “B++” team, there were no free riders.

They went through a rigorous year of development (overall improvement) , and

They played a demanding system.

They had to get a bit lucky to beat the Red Army team, but were in a position to do so because Herb had employed all three elements implied by  using process to make the most of his people.

Watch the movie “Miracle” sometime and pay attention to the leadership and team building skills on display.





Posted in Uncategorized | Leave a comment

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