Basil Vandegriend: Professional Software Development » continuous improvement

My System for Writing

Basil Vandegriend — Wed, 25 Jan 2012 13:23:47 +0000

People from time to time ask me how I manage to write all the articles on my website despite having a family and a demanding full-time job. My simplistic, off-the-cuff answer is "one sentence at a time" :) Seriously, however, over the years I have developed a personal writing system that I would like to share with you. My system consists of three interdependent aspects: time, discipline, and motivation.

Time

The first key is to make time to write. Ideally this should be a decent period of time each day during which you are undisturbed and at peak mental capacity.

The minimum period of time that I find effective is usually around 15 - 30 minutes. This is because it sometimes takes time to get into a good flow of writing. The maximum period of time that I find effective ranged from 45 minutes to 1.5 hours. This maximum is based on how well I can maintain my flow of writing and my motivation / discipline. If I get stuck, especially on a new section for which I do not have a clear outline, I tend to stop and let it percolate in the back of my mind. The longer the writing session goes, the more likely I am to run out of steam (motivation / discipline) - e.g. by getting distracted by email or my RSS reader. I find that practically this means that I am generally unable to continue writing for more than 1.5 hours.

So how do I find the time to write? I get up early each morning, before the rest of my family, and use the time to write. I sometimes write in the evening, but I find I often do not have the mental energy for this after a long day at work. So I tend to save the evenings for other activities, such as exercising, and dedicate the mornings to writing. Successfully doing this day after day takes motivation and discipline.

Motivation

The second aspect of my system is maintaining a high level of motivation. I have found that if I am not motivated to write regarding a particular topic or section then my progress is usually quite slow and I am easily distracted.

One way I keep my motivation high is extremely simple: I primarily choose topics that I am motivated to write about. When a new idea comes along, motivation to write about it is usually quite high initially and decays over time. So the ideal is to start writing about such ideas immediately. Other times I am wrestling with a topic at work or researching it on my own and gain some insights that I feel like sharing.

My motivation in these cases is linked to the goal of helping others learn and grow, which is part of my professional vision. In some cases, as I have started writing about an idea, I realized that I only had a sentence or two of meaningful content, which by my standards is not enough to share via an article. This typically rapidly deflates my motivation, and I move on to a different idea.

This concept of linking the act of writing to the achievement of a larger, more personally-meaningful goal is another valuable technique for boosting motivation. In the last year I have started to tackle some larger projects (which is one reason for the decrease in my posting frequency), and I find that having this linkage is extremely powerful in maintaining motivation over the long term. Having this motivation helps in dedicating the time to write.

Motivation is powerful, but it tends to fluctuate. When motivation fades, discipline is needed to maintain consistency of purpose.

Discipline

The final key to my system of writing is discipline - consistently applying deliberately-designed techniques and practices that help me write. Discipline has also helped me discover these methods through ongoing reflection and improvement on what is working versus what is not

A large part of discipline is consistency, which helps build up productive practices into positive habits. One example is my practice of getting up early each morning to write - I do this every morning, weekends as well as workdays.

I have found that there is an initial hurdle to overcome when sitting down to write, especially if I am struggling with a section. This difficulty often caused me to switch to email or the web as a distraction from which I tended not to emerge, resulting in me making no progress for that block of time. One practice I have developed to overcome this is to have a firm plan in mind the night before of what specifically I am going to write the next morning. As I get up in the morning, I immediately begin recalling my plan as a way to help prime my mind for action. Not only does this help me stay focused, but I also find it reduces the start-up time necessary to get into the flow, thus allowing me to be productive with even a short block of time.

Outlines are another practice I regularly use, even for short pieces of writing such as this article. These outlines are often quite informal, focusing on the main points I plan to write about. The purpose is not to identify all the content, or how it is organized - I often add more points that come to mind as I write, or restructure as the material comes together. Instead, I use outlines to help eliminate one of the causes of getting stuck - not knowing what content to write about. (It is still possible, unfortunately, to get stuck regarding how to write the content.) Outlines are also helpful in dividing the writing into sections: each section acts as a mini-milestone that I can aim to complete during a writing session, thus helping me remain motivated to write.

I have a technique for maintaining the flow while writing and minimizing distractions that involves the use of 'todo' labels. The general idea is that when I identify something to do or consider that falls outside my current focus, I document it with a 'todo' prefix. This keeps it preserved for later action, which helps to get it out of my mind now. Here are some common examples of how I employ this technique:

When I want to link to an article on my website or elsewhere, I leave a 'todo'. Finding the link is often quite quick, but I do this to avoid distractions.
When I have an idea for a piece of content for a future, unwritten section, I jot down a brief note with a 'todo' in that section, then return to what I was writing.
When I get quite stuck on a particular paragraph or section, I leave a 'todo' comment and switch to another area. This is especially common when I have a long list of points outlined: I start writing the points for which I have the most motivation, leaving 'todo' flags on ones I skip. I then use the momentum I have built writing these more motivating points combined with the promise of almost being done them all to return to these few remaining points and grind them out.
When I have an outline consisting of sections, like this article does, I start by writing down the section headings with 'todo' labels on each. This serves as a road-map for me to follow while writing. It also helps me see the overall structure of what I am writing.

This is my system for writing - it may not work for you. But I do suggest at least experimenting with some of these techniques and practices if you have not tried them before. I encourage you to leave a comment describing what practices or techniques you have found helpful.

How to Become an Expert Developer

Basil Vandegriend — Tue, 12 Jan 2010 04:46:10 +0000

What if I told you there was only one activity you needed to do to become an expert, high-performing software developer? You might be doubtful of my claim. Yet this is exactly the finding reported in the book Talent Is Overrated by Geoff Colvin. Across multiple professions research points to the same activity as being the key factor to becoming an expert or world-class performer: deliberate practice. The use of the word 'deliberate' is crucial: this practice does not just involve doing one’s regular work or playing around. It instead is a focused, disciplined activity whose goal is to improve a specific aspect of performance for an individual. Both the quality and quantity of practice are critical to becoming an expert.

Quantity of Practice Required

The research is surprisingly consistent on the quantity of high-quality practice necessary: approximately 10,000 hours. This amount of practice seems to take a minimum of about 10 years to achieve which works out to a rate of 20 hours of practice per week, or about 4 hours per day excluding weekends. It is interesting that this rate of 4 hours per day corresponds to what the research says is the apparent maximum amount of quality practice that can be performed each day. The activity being practiced can be performed for longer, but improvements due to practice do not occur. The reason for this limitation is mental: deliberate practice requires high levels of concerted mental effort that can only be maintained for a limited duration, and a period of sleep is needed during which the brain consolidates the learning that occurred during the day. These limitations explain the 10 year minimum duration: you cannot double the amount of practice you do per day and cut the total duration in half.

Key Elements of High-Quality Practice

It is quite common to see workers with more than 10 years of experience who are nowhere near being an expert. This is because simply performing an activity is not the same as deliberately practicing an activity, although the difference may not always be visible to laypeople. Many people just go through the motions in their work, repeating what they have learned and done before, and thus fail to continue to improve. I have heard this described as having one year of experience repeated for nine years. This explains, therefore, why there is no correlation between the years of 'experience' a developer has and their ability to write code.

So if our goal is to become experts, how do we ensure that we are engaged in high-quality practice rather than just repetitively performing the activity? Here are some key elements of high-quality practice:

Practice must be specifically designed to improve performance for an individual. The practice must push or stretch the individual beyond their current abilities, outside their comfort zone, but not too hard that it causes anxiety and complete failure.

Each practice session should focus on one (or more) specific elements of performance. The more precise your goal(s) for the session, the better the quality of your practice. You need to seek out what you are not good at. Clearly identifying this yourself can be difficult for a number of reasons. Your ego tends to cause you to fail to notice areas of weakness. You might simply lack knowledge about specific areas. And for areas of performance you know about, it may be difficult for you to evaluate your performance compared to the level of an expert. The guidance of a coach or mentor is therefore extremely helpful. In the realm of sports, even experts like Tiger Woods have coaches to help them improve.

In business, unlike sports, access to coaches and mentors is much more limited, if not completely non-existent. So as software developers we need to be more creative in finding ways to obtain guidance. One option is to engage in as much pair programming as possible with as wide a variety of developers as possible. You will not always be paired with an expert, but with a wide variety you will encounter situations where your partner reveals some aspect of development you were unaware and can learn from. Another option is to seek out material – blogs, articles, and books – produced by respected developers about coding & design and study their material carefully to absorb their approach to software development. One example of this is Robert C. Martin’s book Clean Code which provides step-by-step transformations of code into a cleaner form. He also provides on his website a presentation and even a video demonstrating the process of doing test-driven development.
Practice activities must be easily repeatable. To reach expert level requires putting in lots of repetition during practice. The number of repetitions performed by experts during individual practice sessions and over the lifespan of their career can be mind-boggling to laypeople.
Repetition is especially important for those aspects of a field that normally occur less frequently. If a specific aspect is normally only encountered once a year and you never practice it then you will function essentially as a beginner each time you encounter it.

A good example of this in the field of software development is performing the actions leading up to the release of the software: integration / stabilization of the software, acceptance testing, and final packaging / deployment. Traditionally under a waterfall methodology this is done once in the last phase of the project. Modern Agile development methods instead mandate more frequent releases, with some potentially being practice releases that are not actually provided to real users. Activities such as code integration or acceptance testing that were traditionally done once prior to a release are done much more frequently as part of each iteration.
Practice must include feedback regarding the quality of the performance: what was done perfectly versus what can be improved. The more specific the feedback, the easier it is to adjust your actions and tailor future practice sessions to address deficiencies. Feedback should be available immediately, without delay, as part of the practice session.
One of the best ways of obtaining feedback is through a coach or mentor who can evaluate your performance and make recommendations for improvement. Without such a resource there are still ways of gaining feedback. One approach is to find problems done by an expert, solve them yourself, and then compare your solution to the expert's. Another approach is to regularly set aside time to reflect on your performance and identify specific improvements.

Obtaining sufficient feedback soon enough is challenging in the field of software development. Many modern development practices are deliberately designed to maximum the feedback developers receive. Test driven development provides immediate feedback regarding the correctness of the code. Pair programming provides immediate feedback regarding the readability and maintainability of the code. Root cause analysis of defects helps identify specific mistakes that practice can address.
Deliberate practice is mentally highly demanding. This is a consequence of pushing beyond your comfort zone. If you are able to do an activity on auto-pilot, without really thinking, then it is too easy. To grow and improve requires you to be sufficiently challenged.
Research suggests that one’s ability to sustain mental concentration and focus is the main governing factor determining the amount of effective practice that can be performed. The limit seems to be about 4 to 5 hours per day, divided into sessions of no more than 1 to 1.5 hours in duration. (I find it interesting that this maximum session duration for deliberate practice is the same as the recommended maximum duration for code review sessions, which is no surprise given that both activities require a high level of focus and concentration.) It would be interesting to know what kind of rest and recuperation between practice sessions is recommended, but I have not seen this discussed.

Conclusion

To become an expert requires approximately 10,000 hours of high-quality deliberate practice, which must consist of training activities designed to improve performance, lots of repetition, specific and immediate feedback, and sustained high levels of mental effort.
This is simple to state but is definitely not an easy endeavor to do, which explains why in every field there are so few experts and why the majority are at much lower levels of performance. Yet if becoming an expert is your goal, then this is the path you need to take.

Presenting My Continuous Improvement Framework

Basil Vandegriend — Mon, 04 Jan 2010 14:00:39 +0000

I will be presenting my continuous improvement framework at Agile Edmonton at 12:00 noon on January 6, 2009 at the IBM Innovation Center (10044-108th Street Edmonton, Alberta). In addition to the framework itself I will be covering lessons learned from championing and implementing continuous improvement.

I look forward to seeing you there!

Lessons Learned Championing Continuous Improvement

Basil Vandegriend — Mon, 23 Nov 2009 13:30:10 +0000

For over one year now I have been championing continuous improvement across multiple teams. I have seen and struggled with various problems, some of which I have seen reoccur time and time again, and I have identified successful strategies for dealing with some of these issues. In this article I present my lessons learned in the context of my framework of continuous improvement.

This article is organized into a set of common problems, many of which loosely correspond to the stages of my framework. For each problem I identify various causes that lead to the problem, and then present a solution to resolve or mitigate each cause.

Continuous improvement not being done

This first problem is generic, covering any or all stages of my continuous improvement framework. A team might be holding retrospectives and discussing issues and ideas, but not taking action. Management might be taking action to address issues but not following up. There are some common, general causes responsible for this.

Cause	Solution
People are too busy.	People need to work at a maintainable pace (this is Agile principle #8) with sufficient slack to allow time for continuous improvement.
No room in project budget / schedule.	Continuous improvement should be included as a regular activity in every project.
People do not strongly believe in the benefits that continuous improvement brings.	This is the root cause behind the two prior causes: people will find the time (personally and in projects) if they believe strongly enough in continuous improvement. I have no real solution other than trying to educate and sell others on the benefits of continuous improvement. Unfortunately logical arguments are not enough - you must persuade people emotionally in order to see a lasting change in behavior. Probably the best way to do this is by having people experience successful improvements.
People’s primary duties or more urgent activities consume their attention and time, leaving little to none for continuous improvement.	Each team needs to have a champion of continuous improvement who is responsible for scheduling and facilitating retrospectives and ensuring that actions and follow-up happen afterwards. This is not a full-time role. Most commonly it is part of the duties of the person leading the team (team lead, manager, project manager) or coaching the team (scrum master, agile coach). People need to understand and prioritize non-urgent important activities over urgent, non-important activities, which is a key message of the book First Things First by Steven Covey.

Retrospectives and reflection not being done

Retrospectives for the team and reflection for the individual needs to happen in order to become aware of how the team or individual is doing and identify opportunities for improvement. Yet far too often I have seen teams fail to hold retrospectives despite much encouragement and coaching.

Cause	Solution
Forget to hold retrospective meeting or do reflection.	Regularly schedule these sessions so a pattern is established and they are not forgotten. For retrospectives, hold them either at the end of each iteration or at a minimum frequency of once a month. For personal reflection, I like doing this once a week, as part of my weekly review process.

Ideas not being discussed - only issues

An extremely common pattern I have seen is that when a group first starts holding retrospectives, almost all of the discussion and points raised revolve around issues – essentially complaints about how things are, rather than ideas for how to improve. While this does improve as time passes, subsequent meetings still tend to focus more on the issues rather than ideas. While it is important to be aware of your current state and what your issues are, at some point the discussion must move on to ideas for improvements.

Cause	Solution
Typical behavior pattern. People tend to vent, given an outlet. It is harder to think of ideas for how to solve issues than to identify the issues.	Dedicate a portion of the retrospective to discussing issues and a separate portion to discussing ideas for improvement. One format I like is to first solicit issues, then prioritize them, then for the highest priority issues brainstorm or do root cause analysis to come up with ideas on how to resolve them. It helps to have a strong facilitator to keep the discussion focused.
Root causes of issues are external to the team and/or beyond the team’s capability to resolve.	Management support must be in place so that these types of issues can be escalated to them to be dealt with at the appropriate level. Each management level should actively be doing continuous improvement and ensuring that continuous improvement happens in the level(s) below them.

Ideas not being put into action

Too often I have seen teams discuss issues and ideas during a retrospective, but seen nothing happen afterwards as a result.

Cause	Solution
Lack of clarity regarding what to do next after the retrospective is finished.	Determine the next steps to take regarding the key issues / ideas before leaving the retrospective. As part of the meeting identify and write down action items or an action plan for implementing at least one of the ideas.
Lack of follow-through on completing identified actions.	For each issue / idea, have a clearly identified champion who will own the issue or idea. This person needs to be self-starter who is passionate and motivated to get the idea implemented and the issue resolved.
Lack of focus: team has too many issues / ideas being worked on.	Have the team prioritize the issues and select the top few to focus on. One suggestion I have seen in the lean literature is for the team in each retrospective to pick just one idea to implement, but to then have the team commit to achieving the improvement (or at least make progress) by the next retrospective. I personally like to have as many improvements happen concurrently as the team can handle, which depends on the team and on the ideas being implemented. It is probably best to have each person on the team actively involved with only one improvement at a time.

How to Always Get Better: A Framework for Continuous Improvement

Basil Vandegriend — Sat, 14 Mar 2009 23:05:19 +0000

If you believe like I do that organizations must develop a culture of continuous improvement in order to flourish, then the question is how to achieve this. Throughout my career and especially in the last few years I have promoted effective software development practices and a philosophy of learning and growing as a professional. I came to the realization that trying to impose these ideas onto teams from the outside or from above is difficult, time-consuming, and often ineffective. Having a single superior or external expert be the sole source of ideas and motivation for growth is not scalable nor sustainable – what happens when this person moves on? It is far more effective to have individuals and teams adopt a culture of continuous improvement so that they can learn and grow on their own.

This led me to investigate and research methods of developing and encouraging this kind of culture. I came across a superb book called The Toyota Way by Jeffrey Liker which explains how the concept of continuous improvement (kaizen in Japanese) is one of the core management principles at Toyota that has enabled its sustained success and growth over the decades. While this book and others do a great job of presenting the philosophy of kaizen, they have fewer details on how to specifically implement continuous improvement. I gleaned what guidance and information I could from these books and combined this with my own experiences in promoting continuous improvement to create a framework for continuous improvement. This framework provides a concrete model for discussing, implementing, and assessing the practice of continuous improvement within a team or organization.

The Continuous Improvement Framework

Fundamentally continuous improvement is about personal and organizational change to move towards the goal of consistently exceptional performance. We cannot, however, jump directly from our current situation into a better changed state: change is a multi-step process, and the framework explicitly recognizes this. The diagram below illustrates the stages of the framework. These stages are explained in the sections that follow.

Current State

The current state represents the starting point: where we currently are. One of the key motivations behind developing a culture of continuous improvement is the observation that a high performing team that is stagnant and remains stuck in this current state will eventually be surpassed by a team that is continually improving.

Moving beyond the current state requires a clear picture of what the current state truly is. A classic management mistake is to attempt some improvement, usually to address some critical issue-of-the-day, by instituting measures that in the end do not work or have unintended consequences due to a lack of understanding of what is really going on.

Gaining this awareness can be done through a number of approaches whose common theme is adopting a critical, analytical, and investigative mindset:

Retrospectives (aka postmortems or lessons learned) after key milestones.
Quantitative analysis of metrics based on collecting data such as defect rates.
Qualitative analysis of the work based ideally on personal observation or through secondary means like surveys or interviews. The Japanese have an expression that translates "go and see" (genchi genbutsu) which reflects the idea that managers need to go to where the work is actually being done and carefully observe.

Being clear about the current state makes it much easier to identify what needs to be changed. This most frequently involves identifying issues with how things are currently done, which advances us to the next stage in the continuous improvement framework.

Issues

The identification of issues - what is currently wrong or suboptimal - is the next step leading towards the end goal of change. Issues arise from a number of sources:

Problems with the work being performed. In software development these often manifest as defects or production failures. A key activity for each problem is root cause analysis which involves asking "Why?" five times in order to get to the heart of the issue.
Identification of non-value-add activities, referred to as waste (muda) by Toyota. Value-add activities are those that directly contribute to a service or product used by a customer. Anything else is considered waste. There are many different types of waste:
- Unneeded process steps. For example, an approval process for a change that has the supervisor rubber-stamping the request without really reviewing it.
- Defects. The work necessary to track, analyze and fix defects is all considered waste as it is preventable. In contrast, activities such as reviews and testing that are performed to ensure the quality of the work before it is passed along are considered value-add, not waste.
- Waiting. Any kind of waiting is classified as waste. This is even true if you are waiting for a machine to do the work, such as waiting for the code to be compiled or waiting for a document to be printed: the machine might be producing value at that moment of time, but you as the operator are not.
- Misuse of people. This includes overburdening people (i.e. with too much overtime), not having work for people to do (another form of waiting), or having untapped creativity or productivity - a typical result when morale is poor or insufficient attention is directed towards motivation.
Management strategic goals or department targets. When the goal or target is announced, if a team is not in compliance with the goal then this becomes an issue that the team needs to address. A variation on this theme is when management believes that while performance is currently adequate (i.e. no significant problems), it could be better and pushes for improvement.
Retrospectives (aka postmortems or lessons learned). Reviewing what has worked well versus what hasn't is a good mechanism for identifying issues.

Identifying and clarifying an issue does have some value, but it is really still a precursor to actual improvement which begins by generating ideas for how to address or avoid the issue. This is the next stage in the continuous improvement framework.

Ideas

A discussion of issues that does not include generating ideas for dealing with them is really nothing more than a gripe session that provides very limited value. Beyond the basic utilitarian benefit of an idea, coming up with suggestions requires a positive, engaged mindset instead of the largely negative mindset associated with griping about issues. Thinking about how to improve a situation is a key shift towards adopting a mindset of continuous improvement. This is one reason many companies have suggestion boxes for soliciting ideas.

Ideas do not have to be revolutionary nor do they need to involve major shifts or changes. Toyota deliberately encourage the submission of as many ideas as possible, no matter how minor, from all employees. Toyota values this so highly that the metric of average number of ideas submitted per employee per year is one of about ten key metrics that is used to assess the health of an organizational unit. This is because it is key to developing a culture of continuous improvement – a true learning organization: everyone (not just management) needs to be involved with and thinking about how to continuously improve what they do and see.

One technique for generating ideas is to start with an issue, analyze and discuss it to understand it thoroughly, and then brainstorm ideas to address it. Out-of-the-box thinking is important during the brainstorming: you do not always have to directly deal with or fix an issue. Can you prevent it from occurring altogether? Avoid the negative aspects so it becomes irrelevant? Convert it into a positive?

Performing a root cause analysis on an issue is another great source of ideas. The answer to each "Why?" question usually reveals an idea for a countermeasure that can be adopted to prevent the issue from reoccurring.

In the majority of cases ideas arise from issues that people are experiencing. Even when you have a "eureka"-style idea that pops into your head out of thin air or have ideas submitted via a suggestion program that do not appear related to an issue, there is most times an unstated, underlying issue. I recommend in these cases spending the effort to uncover the underlying issue. Doing so allows you to analyze the issue (perhaps via root cause analysis) and brainstorm other options for addressing it.

Despite my last point and what my continuous improvement framework suggests, ideas do not always have to be linked to issues or improvements. There can be ideas for trying something new in order to learn about it or to verify that the current approach being used is indeed better. Product innovation often benefits from ideas about new features unrelated to customer feedback.

Ideas are a necessary factor in achieving continuous improvement, but by themselves they do not produce change. You must take actions to implement an idea in order to initiate actual change, and this is the next step in the continuous improvement framework.

Actions

To action an idea requires that you develop an action plan for how you will implement the idea. This plan can be simple or complex depending on the nature of the idea. Small-scale ideas are much easier to put into practice, perhaps as a single activity, whereas revolutionary ideas might require a strategic corporate initiative. This is the advantage of smaller ideas: they can be implemented much faster with much less effort which further reinforces that culture of continuous improvement. Slower or smaller but constant improvement is superior to large, intermittent steps.

Actions plans fall into the following categories:

Action Item: When the idea requires a single activity to complete it can be assigned as an action item: the activity is assigned to a particular person to be completed by a particular date. The manager for the team is usually responsible for maintaining a tracking list of action items and following up to ensure they are completed. (This is already alluding to the next stage in the framework.)
Project: A project is used when a large number of activities, perhaps done in parallel by multiple resources, are needed to implement the idea and there is a clear end point when all the activities will be finished.
Experiment: For an idea with a broad or significant impact it is often beneficial to try out the idea first on a smaller scale to evaluate its effectiveness. I call these experiments. They are also referred to as process trials or pilots. I prefer the term experiment because of the stronger connotation that a negative outcome is not only possible but is acceptable: the organization has still learned something.
Many organizations have dysfunctional cultures where failure is not acceptable, and as a result managers are often unwilling to alter decisions that prove to be wrong. I have seen it myself where a high level manager makes a decision regarding how to change something and the results prove to be a disaster. This manager admits in private that the decision is a mistake, but is unable (unwilling) to publicly acknowledge this, even implicitly, by changing the decision. In such cultures using experiments to verify ideas provides a way of bypassing this problem. In an organization such as Toyota that fully adopts a culture of continuous improvement such political considerations are not necessary, but experiments are still valuable in vetting ideas before they are more broadly rolled out.

The key point of any experiment is the evaluation: how you will verify that the idea is effective and achieves the desired results. This typically requires that you implement the idea and monitor the results over a period of time before being able to reach a conclusion. For more information see my article Continuous Improvement Experiments.

Taking action – implementing your action plan – is the start of actual change, but more is needed. You need to follow-up to ensure that the change persists, and this is addressed by the next stage of the continuous improvement framework.

Follow-up

Follow-up ensures your actions are being executed and are effective. There are three important categories:

Evaluate: Has improvement happened? Were the expected benefits of the action taken achieved? Were the planned actions actually performed? Was the original idea implemented as intended? Was the underlying issue resolved? Actions frequently have unanticipated and unintended consequences that must be dealt with. In some cases such consequences mean that the original idea is unworkable and must be scrapped or significantly altered. This is a normal part of the continuous improvement process and should not be penalized as failure. Sometimes adjustments or tweaks to the action plan can be made as part of the follow-up phase. In other cases issues found during follow-up initiate a new improvement cycle of new ideas, actions, and follow-up.
Standardize: Once the actions have proven effective, the improvement needs to become permanent, which I define as becoming the officially approved approach that is the normal practice throughout the organization. This is especially necessary if the idea was initially put into action as an experiment. Toyota achieves this by carefully defining standard work processes and policies and updating these standards whenever a better approach is found via continuous improvement.
The culture in North America, especially in I.T., is generally less enthusiastic about standardization of work (although this will depend in part on your mindset towards rules. While there are a number of factors influencing this, one worth discussing is due to how standards are created and evolved. Too often work standards are imposed from above with limited discussion or training (if any), poorly understood and followed by the actual workers, and difficult or impossible to revise, especially by the workers who are supposed to comply with the standard. Given this, is it any surprise that workers have a negative attitude towards standards?

Standards may seem to lie in opposition to continuous improvement. You may ask how you can continue to improve a process that has been standardized. Such a question reflects a particular mindset about standards – that they cannot or need not change – which is incompatible with continuous improvement. A different mindset is needed to successfully integrate the two: a standard represents the best but never perfect way we know now - today - of doing an activity. Because a standard is based on our knowledge and understanding which grows over time, the standard should be continuously improved as we identify better ways of doing the activity in the future.

Toyota considers standardization a key aspect of continuous improvement for several reasons:
- Standards support the development of a learning organization by providing a basis for propagating knowledge of improvements via training. This assumes you do effective training. After reading the book Toyota Talent that explains how Toyota approaches training and development of its employees, I suspect that most companies are ineffective in their training.
- Standards provide a baseline for future improvements. If standards do not exist or are not followed, the process being performed will be ad-hoc and chaotic with a high degree of variance. This makes it very difficult to assess what needs to be improved, especially in terms of general trends.
- Standards help sustain improvements by providing a basis for evaluating whether the improvement is being used in practice.
Two keys to making standardization work are first to have those doing the work write the process and second to keep the process simple and practical so it is actually followed.
Sustain: Once a change has been evaluated and standardized the last phase of following-up is to ensure that the improvement becomes permanent rather than being a temporary change that eventually fades away. Psychology research has found that 85% of people trying to change will relapse back to past behaviors. So you need to explicitly take steps to ensure a change is sustained.
The basic approach to sustaining an improvement is do an ongoing assessment of the state of the change by observing whether the standard is being followed correctly. When a deviation is discovered corrective measures should be taken - the most appropriate usually being additional education or training on what the standard is and how to follow it.

This assessment is more commonly referred to as "auditing", which is a term I am not fond of. Too often the audits I have observed have involved auditors external to the team (usually from quality assurance) only assess the paper trail of what has been done rather than evaluate the actual work or the work products. Usually such an audit merely motivates people to produce the documentation required to pass the audit without actually linking it to the work being done. To be effective, assessments should be done by those knowledgeable about the work and the standard. In Toyota it is the responsibility of management (at all levels) to regularly audit the activities of those under them. Scheduled, random audits are a preferred mechanism for achieving this: once a week select a random person to observe and assess their work.

One key point is that these assessments are ongoing – the need for them never really goes away. The frequency of assessment may decrease over time as adoption improves, but employee changes (transfers, turnover) and continuous improvement of the standards means that sustaining is an ongoing responsibility.

With proper follow-up an improvement becomes part of the normal job routine. This leads to a new current state and the start of the next cycle of continuous improvement.

Conclusion

The continuous improvement framework presented here provides a concrete model for discussing, implementing, and assessing the practice of continuous improvement within a team or organization. This article only provided a basic introduction to the framework and is almost too long as it is. A discussion of the practical application of the framework and examples of it being applied will have to be deferred to future articles.

Continuous Improvement Experiments

Basil Vandegriend — Mon, 24 Nov 2008 04:55:41 +0000

If, like me, you believe strongly in championing continuous improvement then an obvious question is how exactly can continuous improvement be implemented? One answer I have come up with is something I call continuous improvement experiments - CIE for short.

What is a Continuous Improvement Experiment?

The idea is simple: a CIE provides guidance via a formalized structure for thinking about and doing continuous improvement. A single CIE involves explicitly changing a current practice and regularly evaluating the results. A change can be any number of things - a new procedure, use of a different tool, a new process, the elimination of an existing activity, etc. - for which there is a reasonable expectation of improvement.

Write it Down!

I believe the best way to manage continuous improvement experiments is to write them down. Consider recording the following information for each CIE:

Short description of the change.
Name of the champion(s) driving this change.
Experimental approach: how will be the change be adopted for the purposes of this experiment?
Evaluation criteria: how will the change be evaluated? What is the expected improvement? What are the criteria for ending the experiment and fully adopting or rejecting the change?
Time frame for the experiment: when is it starting, how frequently will progress be measured, and when might the experiment be ended?

This write-up should ideally be no more than a single page. At the bottom of this article I provide a sample CIE for adopting continuous improvement experiments.

Why Experiment?

I deliberately chose the word "experiment" instead of words such as "trial" or "activity" because I wanted to emphasize the idea of learning and de-emphasize the notion of failure. If the outcome of a CIE is to not adopt the change then this is a valuable lesson learned – not a failure. Many workplaces, especially bureaucratic ones, tend to have an attitude that it is better to fail following the status quo rather than risk failing via a different path. This attitude runs contrary to the spirit of continuous improvement.

The word "experiment" also suggests that the adoption of this change is temporary and can be reversed. This makes it easier for people to accept the change. More importantly, it makes it much easier for the change to be rejected without negative political impacts like publicly admitting a mistake was made. More than once I have seen large organizations make a significant shift in a practice which was later found to be ineffective or even harmful. But the change could not be undone because executives were unwilling to even implicitly acknowledge publicly that a mistake was made.

How Much of a Good Thing?

I believe that every project, every team, and ideally every individual should have at a minimum one continuous improvement experiment active at all times. In a true culture of continuous improvement identifying, experimenting with, and adopting improvements should be a normal and regular occurrence.

Integrating with Formal Processes

One issue I have seen arise in organizations with formal processes, especially those audited by a quality assurance (QA) group, is how to apply continuous improvement experiments to such formal processes. Any deviation from the documented process would be recorded as a deviation by QA which leads to a failure to pass the audit. Many formal processes have a defined mechanism for changing the process, but this does not support experimentation, especially not for a single team or group rather than all followers of the process. A common 'solution' I have seen to this problem is to simply experiment as you see fit, deviate as needed from the process, and risk the failed audit. While this simple solution has its merits, I do not feel it is ideal. In a true culture of continuous improvements there should be a simple, officially recognized method for performing continuous improvement experiments involving such formal processes. Not officially allowing the experiment goes against this culture. Assuming you cannot eliminate the formal processes, a better solution, therefore, is to define a formal process for continuous improvement experiments by which they are allowed to modify other formal processes. This CIE formal process would typically involve having an appropriate level of management approve CIE that affect formal processes and have these CIE logged so that the QA auditors have documented evidence for their audits. This might sound bureaucratic, and it is, but that is the consequence of having such formal processes in the first place.

Sample Continuous Improvement Experiment

To conclude I will present the write up for a continuous improvement experiment involving the adoption of CIE as a regular practice, which serves both as a concrete example and as a guide to your adoption of continuous improvement experiments within your workplace.
Description: Adopt regular use of continuous improvement experiments
Champion: Basil Vandegriend (put your name here)
Experimental approach: Introduce the concept of CIEs to a single team and have them identify several experiments to start. Record the CIE in a team log. Meet regularly (monthly) to evaluate existing CIEs and identify new ones. This could be a part of regular team meetings or done as separate meetings.
Evaluation criteria: The expected improvement is that the team will adopt a number of changes based on CIEs which will improve the team's performance and/or morale. This experiment will be evaluated based on the number of CIEs attempted, the number of changes adopted, the lessons learned (irregardless of adoption), and the amount of improvement in existing objective and subjective measures of team performance. This change will be permanently adopted if the team is in consensus that it is beneficial, or if the team's performance shows observable improvement.
Time frame: The experiment will start January 1, 2009 with quarterly evaluations (every 3 months). The experiment is tentatively planned to end after nine months.

Becoming a Champion of Continuous Improvement

Basil Vandegriend — Mon, 17 Nov 2008 01:34:24 +0000

I am pleased to announce that I am a Champion of Continuous Improvement.

The story of how I became such a champion starts a few months ago when I spent some time reflecting on my mission / purpose / vision as a professional software developer and architect. I was inspired to do so by two sources. The first was the book The Professional Service Firm50 by Tom Peters, which advises readers to create a cool job title for themselves that is motivating and inspiring. The second source was an online article by Steve Pavlina titled How to Discover Your Life Purpose in About 20 Minutes which provides a simple yet effective process for creating one's personal life purpose statement. This process involves brainstorming statements and then using your emotions and intuition (your heart) to evaluate and evolve them rather than logic (your mind).

I decided to use Steve's process to create a cool job title. (I also used Steve's process to draft a mission statement for myself.) Reproduced below is my brainstorming list – at least those items I actually wrote down – with some commentary.

Problem Solver: My starting point because lately when coworkers ask me what I do, I tell them I solve problems. I wear too many hats to be able to easily describe all my roles :)
Visionary
Leader
Do Things Better
Quality
Technical Growth Visionary: With this item I knew I was close to the core idea. Most of the remaining brainstorming ended up focusing on selecting the most meaningful words to capture this idea.
Improve
Coach
Guide
Professional Development
Change Provocateur
Change Agent
Technical Improvements Leader
Personal & Team Technical Growth Leader
Services
Software Development Services Leader
Champion of Continuously Improving Software Development Services: This is the last draft version before the final version. It seems like a big jump from the prior items since both the words "Champion" and "Continuously" are introduced for the first time. I suspect I did some mental brainstorming prior to this item that I never wrote down.

The final version of my cool job title is Champion of Continuous Improvement of Software Development Services. This is a bit of a mouthful so I tend to shorten it to "Champion of Continuous Improvement". The clause "of Software Development Services" is still important, however, since it provides a scope or boundary for my continuous improvement activities. I deliberately restrict myself to the realm of software development where I am most motivated and have significant expertise, and exclude activities such as service delivery management, program management, and infrastructure support. I have the word "Services" on the end to avoid restricting myself to only software development activities such as coding or debugging. I deliberately wanted to include related activities such as quality assurance, project management, and enterprise architecture.

Now that I had my unofficial title, I found myself strongly motivated to make it as official as possible. My first step was to print out the title in large font and post it outside my cubicle. I then added it to my short term career goals and discussed it with my manager. One interesting comment I received from more than coworker was that the sign was unnecessary in the sense that they already knew that was what I did. I found this encouraging since it meant my title aligned well with my past actions.

Speaking about past activities, I was already chairing a process improvement group and leading a technical practices review – or at least trying to. My efforts in these areas had stagnated somewhat, due largely to a lack of clarity about an effective way to move forward. With my new title, however, the path forward became much clearer and my motivation much stronger. I transformed the process improvement group into a continuous improvement group and at the first meeting discussed the topic of championing continuous improvement. The discussion was spirited and the topic seemed to resonate with the other senior technical resources at that meeting. This provided me a boost of confidence that I was on the right track.

Another key step I took was to discuss my new title with my manager. Together we brainstormed various ideas regarding the next steps I could take and I began implementing the most promising ones. I was fortunate to have such a supportive manager since management support was essential.

At this point in time my road ahead as a Champion of Continuous Improvement was clear to me, and I felt that I had earned the title by my actions, both before and after I came up with it.

That is my story of how I became a Champion of Continuous Improvement. I plan to write further about my experiences as champion, and would love to hear from you concerning your experiences with continuous improvement, both good and bad.

How to do Root Cause Analysis

Basil Vandegriend — Thu, 27 Jul 2006 15:00:52 +0000

Root cause analysis is an important activity whenever a problem occurs - whether it is a defect, an operational outage, or something else. Whatever the problem, your objective should be to not only resolve the issue but also prevent it from reoccurring in the future. To do this, you need to determine the root cause - the key factor(s) that caused the problem to occur and that need to change in order to stop it from happening again.

Root cause analysis is essentially a learning exercise, and as such should be a fundamental practice if your objective is perpetual learning or continuous improvement. It disappoints me to so often see it done poorly or not at all. The good news is that the ability to do root cause analysis can be trained and improved.

At its essence, root cause analysis involves asking "Why?" coupled with the determination to find answers that will help permanently resolve or at least improve the situation being dealt with. To start, you simply ask "Why did the problem happen?". If the answer tells you how to fix the problem but not how to prevent it in the future, then you need to keep asking why. Even once you start getting more profound answers, you can often continue asking why questions and learn still more.

Asking why is easy - figuring out the answer is hard. Both analytical and creative thinking skills play a role. At times you may feel like a detective, ferreting out clues like Sherlock Holmes. When faced with a question concerning a situation with no apparent answer, I've found it helpful to brainstorm ideas for what possibly could have led to the situation, and from there try and determine whether each possibility could have occurred.

Root cause analysis is not for the faint-at-heart. Asking probing questions and searching for answers about why things went wrong can make you unpopular, especially if your investigation involves other teams and other managers. You need to be careful that your efforts are not perceived as laying blame or trying to score political points by making others look bad. Instead, emphasize that it is a learning exercise whose purpose is to prevent future occurrences of the problem.

Next week I'll present some real-life examples of root cause analysis that touch on the above points. But you don't have to wait. You can start practicing root cause analysis today - just ask "Why?".

Continuous Improvement

Basil Vandegriend — Thu, 13 Apr 2006 15:00:03 +0000

After writing my article on Perpetual Learning, I came across the same concept in the book Core Performance Essentials by Mark Verstegen and Pete Williams (a fitness and nutrition book). To quote from the book: "It's like the Japanese concept of Kaizen, which we translate in this country as 'continuous improvement'. In America, we tend to look for quick fixes and dramatic turnarounds, whether in business or fitness. There's nothing wrong with that mentality, but it often does not come with a foundation for long-term success. Kaizen strives for steady, uninterrupted, incremental change. It's originally a Buddhist term meaning 'Renew the heart and make it good'." (page 97)

Verstegen has a lot more to say about exercising and staying health in this book. While he is talking about physical workouts and trains professional athletes, the same principles apply to professional software developers, except our 'workouts' are mental. One quote in particular really jumped out at me: "No matter how busy you are, there is a window of opportunity. ... Set some manageable goals, and then find that one period of the day where you can make it happen, and schedule it. This is no different from what I do with professional athletes. We take their year-long schedule and daily routines of practice and games and work in training around it. I know, I know; if you had an exciting, high-paying job contingent on being in top physical condition, you too would feel inspired to work out harder. But here's the funny little secret of my business: Most athletes, because of the grueling travel and rigid schedule of competition and practices, plus family, do not have much time for day-to-day conditioning. The reason they are world class is that they find the time in their day." (page 196, emphasis mine)

As software developers, I think we can relate: we are so busy with our daily jobs that it is hard to find the time to learn and grow. However, if we want to excel in the craft of software development, we need to find the time each day or week to train our craft. Regular, consistent improvement is the path to mastery.