Software Quality | Quality and Innovation

Tag Archives: Software Quality

Lessons Learned Must Be Actionable

Posted on February 17, 2011 by Nicole Radziwill Leave a comment

I spent last week at the 2011 International Conference on Software Quality in San Diego. On Wednesday, I hosted a session of lightning talks, where anyone in the audience can volunteer to “have the stage” for 5 minutes. Some people give presentations with slides, some give presentations without slides, others present ideas or comment on other conference sessions, and yet others lead a short discussion or ask the audience a question they would like to have answered. The best part about lightning talks – and what makes them so fun – is that when the timer (that everyone can see) reaches 0:00 the audience is required to loudly and aggressively clap the speaker off the stage! It’s a great way to get (usually) introverted scientists, engineers and techno-geeks actively involved in discussion.

One of the guys who presented a lightning talk (I unfortunately can’t remember his name) was an ISO 9000 auditor. He shared a little nugget with us that really stuck with me, and I’d like to share it with the rest of the world. His insight came from many of the quality systems he’s reviewed and audited, and he said he noticed this with some of the conference presentations as well. I paraphrase:

Lessons learned must be actionable. So many times I see people present their lessons learned, but they’re not doing anything as a result, or they haven’t figured out how to do something in response to the lesson – they’re not changing their processes, attitudes, or strategies in response to what they’ve uncovered. If it’s merely an insight, it’s just a lesson… if it’s an insight that results in changing or adapting behavior, then it’s a lesson learned!

It struck me that since lessons learned are such an important component of Baldrige assessments as well (via ADLI), organizations that are currently working on an application might also benefit from this perspective.

If anyone remembers this guy’s name, please post it. He was tall and had lots of fluffy white hair.

Maker’s Meeting, Manager’s Meeting

Posted on August 14, 2009 by Nicole Radziwill 2 comments

In July, Paul Graham posted an article called “Maker’s Schedule, Manager’s Schedule“. He points out that people who make things, like software engineers and writers, are on a completely different schedule than managers – and that by imposing the manager’s schedule on the developers, there is an associated cost. Makers simply can’t be as productive on the manager’s schedule:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

This concept really resonated with us – we know about the costs of context switching, but this presented a nice concept for how a developer’s day can be segmented such that ample time is provided for getting things done. As a result, we attempted to apply the concept to achieve more effective communication between technical staff and managers. And in at least one case, it worked extremely well.

Case: Ron DuPlain (@rduplain) and I frequently work together on technical projects. I am the manager; he is the developer. More than we like, we run into problems communicating, but fortunately we are both always on the lookout for strategies to help us communicate better. We decided to apply the “makers vs. managers” concept to meetings, to see whether declaring whether we were having a maker’s meeting or a manager’s meeting prior to the session would improve our ability to communicate with one another.

And it did. We had a very effective maker’s meeting today, for example… explored some technical challenges, worked through a solution space, and talked about possible design options and background information. It was great. As a manager, I got to spend time thinking about a technical problem, but temporarily suspended my attachment to dates, milestones and artifacts. As a developer, Ron got the time and attention from me that he needed to explain his challenges, without the pressure of knowing that I was in a hurry and just needed the bottom line. As a result, Ron felt like I was able to understand the perspectives he was presenting more effectively, and get a better sense of the trade-offs he was exploring.

We had the opportunity to meet on the same terms, all because we declared the intent of our meeting up front in terms of “makers” and “managers”. Thanks Paul – this common language is proving to be a powerful concept for achieving a shared and immediate understanding of technical problems.

Disorganization and Changing Your Mind are Both Expensive

Posted on August 5, 2009 by Nicole Radziwill 4 comments

Ron DuPlain forwarded me an interesting post from November 2008 (via @duanegran, I believe) called How much do websites cost? It’s a great comprehensive overview of the different kinds of web sites that can be built – the spectrum of customization, interactivity, and intent that dictate whether a web site will cost $200 or $2 million. But what really struck me about this article was one tiny little section that talks about value, emphasizing the relationship between quality, waste, and the changeability of human wants, needs, and desires:

2.) A small company site that has 5 to 10 pages describing the products/services offered by the company. $500 to $2,000 depending on how prepared you are, and also on how clear in your own head you are about what you want. Disorganization and changing your mind are both expensive.

Disorganization is expensive because it blocks action. When your house is disorganized, you waste time and energy trying to find stuff. When the processes you use in the workplace are disorganized, time and physical energy can be wasted engaging in non-value-adding activities, and mental and emotional time and energy wasted in unproductive communications. Wasting time and energy can generate short-term real costs (for example, moving parts or products around a factory or supply chain can delay time-to-market while costing more in fuel for transport), long-term real costs (e.g. reinforcing negative behaviors that lead to breakdowns in interpersonal relationships, teamwork, or morale) or opportunity costs.

Changing your mind is expensive for the same reason: it either blocks new action from taking place, or it eliminates the value that could have been added by prior work. A task is not actionable unless you have the 1) resources to do the job, 2) the information and interest to complete it, 3) the skills and capabilities to make it happen, as well as a clear idea of what needs to be done, and 4) an execution environment that supports getting things done. Changing your mind can erode #2 or #3.

To reduce the risk associated with development, and to control the costs of the project, find out:

How much do you really know about what you want?
What essential elements are you pretty sure you’ll still want or need in 3 months, 6 months, 1 year, 5 years?
What parts do you have the resources, information/interest, capabilities/skills/clarity, and execution environment to get done now? (I call this RICE to make it easier to remember)

The lesson: to get higher quality and lower costs (that is, greater value), focus on those parts of a project that are least likely to change and do those first. This is, of course, if you have the luxury to be agile (highly regulated environments may impose restrictions or limits). Then stop – figure out what your experience working on those parts tells you about how you can approach the problem more systematically and effectively– and repeat the cycle until you iterate to the desired solution. This is the essence of applying organizational learning to your day to day tasks.

Quality of an Interactive System

Posted on June 23, 2009 by Nicole Radziwill Leave a comment

Today, I spent some time in a remote visualization tutorial presented by John Clyne of NCAR. He referenced a 2005 answer to the question “What is meant by interactive analysis?” by Mark Rast of the University of Colorado:

Definition: A system is interactive if the time between a user event and [the system’s] response to that event is short enough to maintain my full attention.

If the response time is…

1-5 seconds: I’m engaged
5-60 seconds: I’m tapping my foot
1-3 minutes: I’m reading email
>3 minutes: I’ve forgotten why I asked the question!

I liked this because it defines a quality attribute: a high-quality interactive system maintains the user’s attention.

Software Quality

Not Invented Here

Posted on June 19, 2009 by Nicole Radziwill 5 comments

peacock If you are part of the software development world, no doubt you are familiar with “not invented here” (NIH) syndrome. It is the scourge of the software development culture, the unfortunate tendency within a group of software-minded people to attribute value to the code that members of the group or the group itself has written, while devaluing code, modules or COTS packages that have not been written by members of the group.

“Not invented here” is so prominent that it has a wikipedia entry, with text that assures us that this tendency is indeed a facet of many a social, corporate or institutional culture. Bloggers and even Harvard Business Review have touted its benefits, suggesting that this characteristic of a culture may catalyze innovation.

Today, I attended a meeting where I had an even bigger revelation about NIH. About 10 people attended, and we talked about how to search a large archive of metadata across multiple data sources. Attendees spoke of the problem as something that really needs to be done, as something that our organization really needs to spend time on – and we need resources to do it. There’s only one problem with this picture – a couple of people within the organization have been working on this problem for the past 18 months, have produced a prototype that’s consistently getting about 100 hits a day (which is substantial given the problem domain), and have received positive reviews and helpful suggestions for moving forward from the user community. The releases have been published in inter-organizational emails, the company newsletter, and other venues where it would be very easy for everyone in this meeting to have learned of the new functionality and used it. But apparently no one has bothered to pay attention!

The moral of the story: when a NIH culture is observed, perhaps the resources and opportunities that are available to a group or an organization that could use them are truly invisible to the people who need them. The people can not see the opportunities because they are not looking; they are not paying attention.

Is paying attention to opportunities a value within your software development organization? It requires conscious effort.

The ITEA Criteria for Software Process & Performance Improvement

Posted on February 20, 2009 by Nicole Radziwill Leave a comment

(I originally wrote this article for the ASQ Software Division Newsletter compiled in the first quarter of 2009. I’m reproducing it here because I’ve found the ITEA criteria to be remarkably useful for all kinds of planning since I was introduced to it last year.)

For software professionals, particularly those of us who manage product development or development teams, it is important to track progress towards our goals and to justify the results of our efforts. We have to write effective project charters for software development just to get things moving, evaluate improvement alternatives before making an investment of time and effort in a process change, and ultimately validate the effectiveness of what we have implemented.

This past fall, I had the opportunity to serve as a preliminary round judge for the ASQ International Team Excellence Award (ITEA). My subgroup of judges met at the Bank of America training facility in Charlotte, North Carolina, where we split up into teams to evaluate almost 20 project portfolios. A handful of other events just like ours were held at the same time across the country, giving many people the opportunity to train and serve as judges. Before we evaluated the portfolios, we were all trained on how to use and understand the ITEA criteria, a 37-point system for assessing how well a project had established and managed to its own internal quality system. The ITEA criteria can be applied to any development project or process improvement initiative in the same way that the Baldrige criteria might be applied to an organization‘s strategic efforts. For software, this might include improving the internal processes of a software development team, using software improvements and automation to streamline a production or service process, and improving the performance or quality of a software product. (For example, I can envision the ITEA criteria being used to evaluate the benefits of parallelizing all or part of a software system to achieve a tenfold or hundredfold performance improvement.)

You can review these criteria on the web at http://wcqi.asq.org/2008/pdf/criteria-detail.pdf yourself. There are five main categories in the ITEA criteria: project selection and purpose, the current situation (prior to improvement), solution development (and evaluation of alternatives), project implementation and results, and team management and project presentation. An important distinction is in the use of the words Identify/Indicate, Describe and Explain within the criteria. To identify or indicate means that you have enumerated the results of brainstorming or analysis, which can often be achieved using a simple list of bullet points. To describe means that you have explained what you mean by each of these points. To explain means that you have fully discussed not only the subject addressed by one of the 37 points, but also your rationale for whatever decisions were made. Sustainability of the improvements that a project makes is also a major component of the ITEA criteria. Once your project is complete, how will you ensure that the benefits you provided are continued? How can you make sure that a new process you developed will actually be followed? Do you have the resources and capabilities to maintain the new state of the system and/or process?

The ITEA criteria can serve as a useful checklist to make sure you‘ve covered all of the bases for your software development or process improvement project. I encourage you to review the criteria and see how they can be useful to your work.

Quality is Better When You Feel Good

Posted on February 5, 2009 by Nicole Radziwill 2 comments

How you perceive quality is influenced by your expectations. And sometimes, your expectations are subconscious or emotionally driven.

For example, a product may have all the features you, as a consumer, could possibly want and need – and it might perform well too! But it still might not satisfy everyone, or generate the magnitude of sales that were originally projected. How could this be?

Understanding the psychology of quality and value, based on affect, provides insight into how this can happen. Merriam Webster’s Medical Dictionary defines affect as “the conscious subjective aspect of an emotion considered apart from bodily changes.” In short, affect describes how something makes you feel. For example, working on a task that you really enjoy promotes positive affect. Spending time with “de-energizers” who are negative, critical, and generally unhappy can create negative affect.

Research in psychology indicates that positive affect corresponds with the ability to solve problems more readily and effectively, while negative affect can impede problem solving, even for simple tasks. As a result, usability can be considered a function of the positive or negative affect that is generated when a user interacts with a product. This applies to all products, including software and web-based applications.

These studies also suggest that effective design translates to positive affect – meaning that before use, perceived quality and perceived value are more closely related to the perceived quality and value that will be experienced after use. Aesthetics thus play a role in promoting positive affect. As interpreted by Don Norman (2004) in Emotional Design, where many of the aforementioned studies are referenced,

“the emotional system changes how the cognitive system operates… [it is] easier for people to find solutions to the problems they encounter… [there is a] tendency to repeat the same operation over again is especially likely for those who are anxious or tense.”

An entertaining example is the ATM case, which I’ll write about tomorrow.