The 1st Principle - Eliminate Waste

Eliminate Waste

The main goal is to add value to your products. Anything, that does not add value is considered waste.

  • Partially Done Work
    Unfinished program parts tend to become waste. Finish what you have started before you begin on a new task.
  • Extra Processes
    Limit the number of processes required to fulfill a given task. Do not add extra review sessions or procedures if these do not add value to the project.
  • Extra Features
    Programmers sometimes add extra features, because they want to experiment. Managers often want to add extra features, because they think this will add value to the product. Extra features increase the complexity of the system and most of them end up as dead code, which makes is harder to read and understand the program, which makes later development more inefficient.
  • Task Switching
    Avoid having your developers perform task switching. For each switch you loose time, knowledge and inertia. You also increase the stress level. This type of waste frequently result in partially completed tasks.
  • Waiting
    Waiting for something before you are able to continue on your current task is among the most irritating factors encountered during development. It frequently leads to task switching, because nobody likes to be idle.
  • Motion
    The distance between knowledge required to complete a task and the development team is exponentially related to the speed at which you can progress with your tasks. Motion describes the times wasted to access necessary resources. A high motion factor leads to waiting.
  • Defects
    Defects are unavoidable. Do not complain about the number of defects in a system, because the number is just an indicator of something being wrong in the process. All other types of waste will result in an increased number of defects.

Real Life Experience
One of the worst assignments I have ever worked on also had the worst kind of waste production. The manager made deals with the customer, he was an expert in the problem domain and participated in the development process. The project members often waited, since the manager was very occupied talking to the various customers and information about the problem domain was hard to get (Motion required to get needed information).
Task switching was a daily event as many projects had to be delivered within the same timeframe. This lead to partially completed work and finally to defects, which were the result of forgetting how far the developers had completed the task when they needed to switch to another one.
In the beginning the developers were very committed to the work, because the tasks were very challenging and the solutions were deployed in time-critical environments. Your work mattered and the customers expressed their happiness.
As time went by, the deliveries did not meet the deadlines. The developers were under severe stress and defects were encountered more frequently. Consequently, the customers were not longer pleased. The manager promised the customers additional features, because he believed this would make the products better and the customers happier.

The 2nd Principle - Amplify Learning

Amplify Learning

Learn from mistakes and do not repeat them. During a given timespan experience gained is maximized at the beginning of a new task.

The learning progress is better achieved when feed-back is followed close after a part is completed.

  • Iterations
    A timespan between 1 and 4 weeks per iteration is a good guideline. Longer iteration time will result in a larger deviation from the customers wishes and makes the development time estimates much harder to get accurate. Try to start with two weeks iteration length and adjust it depending on the type of tasks solved during the iterations.
  • Iteration Planning
    Do not solve the easiest parts first. Take the hard ones and leave the simple task for later. Each iteration must result in a delivery with as little defects as possible. Do not include unfinished features.
  • Commitment
    It is vital for project, that all members are committed to the tasks to be solved. The customer has to sign off for the features to be implemented in the next iteration and he must understand the importance of each deadline, where he must allocate the time necessary to test and comment results of the work.
  • Convergence
    You often overhear the fact of development: "The last 10% of the project took 90% of the time". Some people tend to perform Gold Plating on their programs and designs. Do not waste time to make anything better than correct. Over optimisation is waste of time and does not add value.
  • Negotiable Scope
    Prioritising is a key element in iterative development. Always look at the tasks to be performed in the current iteration and prioritise these. Take the most important and most complicated first. The customer will more willingly accept that some lesser features are moved to a later iteration than missing a vital part or become frustrated over defects in the main part of the system.
  • Set-Based NOT Point-Base
    A set contains more value in the sense of information than a point. Avoid single uncorrelated information, ie. do not ask how much information typically is processed, but rather in which range the number of data items occur. Set-based also means that you for example present the customer of a choice between two sets of features you are able to deliver. This is more helpful than giving him a complete list of features, where he has to pick the ones he would need.
    You had your reasons why you arranged the features in the sets you presented. It show your state of knowledge about the system. It will then be easier to discuss the pros and cons of the resulting implementation.

Real Life Experience
Our booking and administration system is based on the principle of amplified learning. It is an extremely powerful way of delivering software to customers who are non-IT-Professionals. We have 7 or 14 days iteration length depending on the currently ordered new features complexity. At each meeting with the customer we address up to three topics:

  • The new version and its features
  • Defects found by the customer in the previously delivered version
  • The next features to be added

The 4th Principle - Delivere as Fast as Possible

Deliver as Fast as Possible

Deliver often to get feedback often.

You need feedback in order to amplify learning and you need feedback to judge your decisions. Faster deliveries will get you there, but do not make haste. Haste will only lead to waste.

  • Pull Systems
    You need a system where you store your tasks. This may be small business cards sized paper variants or a software tool. Each task can be owned and processed by a project member. When the person has finished his work on the task, it will be available to the rest of the project members again.
  • Reduce Cycle Time
    • Steady Rate of Arrival
      New tasks should arrive at a steady rate. The machinery will come to a standstill if too many tasks arrive at the same time. Invent a way to control the rate of tasks arriving for your kind of projects.
    • Steady Rate of Service
      When tasks are handled continuously, they also need to be verified at the same rate. Testers must be able to follow up on the implemented items at the same rate as features become available. When this is not the case, you will produce a lot of waste: unfinished work, waiting and defects.
    • Slack
      It is better to run constantly at 80-90% efficiency instead of 100%. No slack means you are vulnerable to the effect of changes.
  • Feedback Loop
    Look at the quality of the feedback you get. Since this is the only true way to increase the knowledge about the system, you want the best feedback you can get. Try to change the iteration length once in a while to see if this has positive or negative impact on feedback. Motivate the customer to give you qualified feedback.

Real Life Experience
I had the pleasure of being on a team who worked together with people from A.T. Kearney. During the early state of the project, it was not altogether clear how the different parts, which were contributed by the different expert groups, would fit in the whole solution. The project manager introduced the "post-it-notes-system" or kanban system, as soon as he noticed this problem.
All groups listed from their perspective necessary tasks and each task was written down on a post-it note. Afterwards the whiteboard was partitioned into sections, where each represented one of the different aspects of the complete system. For each post-it node we assigned the item to one of the sections and then these were grouped based on each expert groups area. Next, the tasks were scheduled and milestones defined.

The 3rd Principle - Decide as Late as Possible

Decide as Late as Possible

Decisions, decisions... People make more false than correct decisions during their life, but this is the best way to learn something new.

The learning progress is high in the beginning and irreversible false decisions have the biggest impact when made early in the project.

Keep your options open as long as practical, but no longer.

  • Breadth-First vs. Depth-First
    In order to decide as late as possible it is better to implement programs breadth-first instead of taking a part of the whole and complete it first.
  • Intuitive Decision Making
    Decisions are often wrong in the beginning of a project. The task is not analysed and understood thoroughly yet. Professionals rely on long time experience and their gut-feeling often lead to good intuitive decisions. Do not hesitate to make an intuitive decision - it is often better to make a wrong decision than making none at all. You learn more from an error than from a success.
  • Simple Rules
    Do not make it hard for the people to make or change decisions. There is no point in following a wrong course, just because it would be complicated or because it would be a humiliation to admit an error.

Real Life Experience
I recently participated in another proof-of-concept project, where the depth-first approach was chosen. It was the intention to implement a simple part of the whole system completely and based on the experience from the small part we tried to estimate the time it will take to implement the rest. Furthermore the first part should eliminate all the possible obstacles in order to get the rest done without any complications.
The breadth-first method would have revealed the complexity of the other parts and would have given a better basis to estimate the total amount of time for the system. We were too narrowed-in on the part system instead of seeing the whole.

The 5th Principle - Empower the Team

Empower the Team

A company with developer teams has more than just a collection of developers. Teams only exist when the environment permits it and the leadership allows it.

Simple fact of life: without workers, no work gets done. Unmotivated developers slow the process down and can even block the whole process.

  • Belonging
    You care more about things you own opposed to things you have no ownership of. It is a good sign, as soon as you overhear developers referring to software parts as my baby. There is a better chance for that part of software to have a high quality. Just keep an eye on the developers that they do not start gold plating.
    Belonging is also important with respect to the other developers and to the company itself.
  • Safety
    Developers need a safe environment. Avoid disturbances and keep away problems which are unrelated to the development of the software. Disturbances are also caused by announcing defects too often. It is better to collect a number of known issues and publish these as a set. Safety also means, that people are not punished for making mistakes. People who become afraid of taking a change once in a while will never be innovative.
    A good leader will describe his job like this: "My most important function is to provide assistance to the team members, so that they have no obstacles in their path".
  • Competence
    Hire competent people. It is ok to hire a freshman once in a while, just remember to place this person in an environment where he does not hinder other developers but still can learn a lot in a short time. Try to find a coach for him.
  • Progress
    Do not reward individuals but the whole team. Rewarding a team leads to a good climate. Rewarding individuals leads to rivalry and teams will break apart.
  • Leadership
    A good leader will practice the following disciplines:
    • Set Direction
      Do not give orders, but set a common goal. Professional people know how to solve a given problem.
    • Align People
      All people act differently, even in a team. Figure out what drives the individual team member and use it to move him into the common direction.
    • Enable Motivation
      Money is not a good motivator for creative people. Money often satisfies the need for safety, but to motivate a developer requires challenging tasks, clear and simple rules and room for individuality.
      Have a clear focus on the professional goal and an open environment for peoples personal style.
  • Experts
    Professionals will become experts in certain areas. Most often because they favourise special disciplines in software development. Use these experts as a special task force to remove problems.
  • Standards
    Standards help people to have a common ground to operate on. Coding standards for instance will help everybody to read other peoples code more easily. Just remember not to standardise everything. This will reduce innovation.

Real Life Experience
Working for different customers on site reveals the known fact, that no two companies are the same. The biggest difference is the way employees are treated and motivated. The worst place I have been to is best described as a coding farm. The developers were placed in a large room and from time to time they were instructed by a project manager what to do next. No one had the feeling of being part of something and no teams were formed. Consequently the motivation was very low and number of defects were high.
Another company had a better understanding of how to treat people. They did not know about agile development, but the managers had learned to motivate the employees by giving the general directions and by setting up a framework, which people should try to follow as best as possible. One of the guidelines was that everybody should try to be as efficient as possible and reduce the amount of waste. After some years most of the employees had leader experience and became experts in different fields.