The 6th Principle - Build Integrity In

Build Integrity In

The customer only sees the user interface, no matter how much work the developers have put into an application. It is important that the look and feel of the system comes naturally and features are helpful and not disturbing.

The result of your work must not look like a collection of small solutions, but as one integral system.

  • Perceived and Conceptual Integrity
    Perceived integrity is when a system appears to be knowing what the user wants of it next. Study the workflow of the future users and try to build this into the application.
    Conceptual integrity is the way the system is designed. When you need to rewrite most of the system in order to make small changes, then your design is rotten. Always keep in mind that development includes learning, making decisions and it is a process - you will never reach perfection.
  • Refactoring
    Complex problems do not always require complex solutions, but to find a simple solution requires more than one attempt. Use refactoring in order to maintain the integrity of the system. Refactoring means rewriting code which is no longer good enough or you have discovered a better solution during your learning process. Do not hesitate to do it, because stronger integrity adds value to your product.
  • Build and Smoke Test
    It is a best practice to run Build and Smoke Tests. Introduce an automated build process running every night, if practicable. The build process is best followed by an automated test run. This way you can easily keep track of progress and developers get fast feedback from effects of recent implementations.

Real Life Experience
Refactoring and automated builds are used at a company we know. The daily routines and processes are in place. However, the automated build process is not followed by automated tests. During the day someone gets stuck with his work, because of a problem he cannot explain from his part of the system. He starts to ask other developers, if they know about this. In most cases the problem was introduced as a side effect of an implementation someone else did. This results in a lot of wasted time, because the developers often wait for this problem to get fixed. It is less likely that you need to spend time asking around and waiting by using automated tests, because then you would already notice the problem in the morning and someone could take care of it.

The 7th Principle - See the Whole

See the Whole

An overview of the whole project will give you an advantage to adapt to changes, which is the most important factor in agile development.

Do not sub-optimize in order to get the details right, but worry about the system as a whole.

  • Measuring
    Be careful how and what you measure. All features may be implemented in time in every iteration and the customer may still be unhappy. Measuring changes the focus. When you measure the hours spent on paid projects compared to internal time, then you can optimize this to have almost every hour spent on paid projects. Unfortunately, you will discover that the quality of the software will fall, as people will not have enough variation in their daily work.
  • Appropriate Contracts
    Time and material contracts are among the only kind of contracts which are suitable for agile development. Fixed priced contracts demand knowledge and in-depth analysis of the problem. Customers rarely sign time and material contracts, because they fear that the costs may run away. In these cases try to make fixed price contracts for the well known parts only.
  • Scope, Price, Time, Resources
    These are the four main factors when doing a project. You cannot have them all constrained. When you begin on working on a project make it clear for yourself which of the factors are fixed and which are negotiable or mutable.

Real Life Experience
I have worked on a lot of fixed prize contracts. None of these projects were to my or the customers satisfaction. The most successful of these had a fixed price contract in the beginning and a time and material contract afterwards. There was put a lot of work on scheduling and analysis - often with wrong estimates, which was bad for product quality.
The problem was often caused by the sales people, not the customer. The customer wants to have a price tag on the product he orders, which can be done with a reasonable error margin. Unfortunately, the salesman typically takes the approach: Look what we did before; How long did it take? What have other companies done? We want the project and we are of course better than all the competitors, so we base our fixed price contract on these facts. The developers are sometimes asked to give an estimate too, but they have little time to do so, because the time they spent is not paid by any customer.
Learn to have a tight communication between the customer and the developers from the very beginning and avoid making early decisions, when knowledge about the details is missing.

Lean Question and Answers

Questions and Answers

This page is a result of an interview concerning the use of Lean in Software Development. You may find it useful when deciding when to introduce Lean in your company.

1. How would you define lean development?

Lean Software Development is a process control toolkit. Each company must find the right way to use the toolkit.

2. What percentage of developers do you think are using Lean Development approach?
There are currently 2 danish software companies using Lean and talking about it - one is Rehsco of course. There are some more companies is Germany, but these are often companies where production and software processes are both part of the resulting product.

3. How has the usage increased from previous years?
Software developers who deliver software to production companies will first adopt Lean. When you see it work you want to copy the process and use it in your company.

4. Why do you think the usage has increased?
It is easier to use a toolkit than using a theoretical description and change your company accordingly.

5. How do you expect the usage to be in the next five years?
There will certainly be an increase in the number of people using it. In the short run only companies in specific fields will take Lean in.

6. Have you found resistance or pessimistic thinking towards Lean usage?
A LOT. When people are used to work alone on projects or the company does not encourage the forming of teams, then you end up with people you think their method is the only one which works. This method is often the so-called "code and fix" method.

7. What kind of unintended results have you seen by using Lean?
Many companies make the mistake of rushing the process when introducing agile methodologies. It takes time to change.

8. What suggestions do you have for a shop considering Lean?
Look out for a similar company who uses Lean. By similar I mean size and culture - not necessarily a rival. Try to find a way to improve each others processes.

9. Have you seen situations were if a company could do it over, will they deploy lean differently?
No, none.

10. Can Lean development be applied to non-Agile (i.e. waterfall) methodologies?
You can and must adapt Lean to suit your companies needs. In the beginning non-agile methodologies will coexist with the new way of "doing things". After some time companies will either drop the agile approach or drop the non-agile one.

11. How difficult is it for a team to become Agile and Lean after being non-Agile?
As mentioned earlier it is often a long way for people who had no need to adapt to new situations. These people are often the biggest obstacles in introducing agile methodologies.

12. What is the unsuccessful rate of turning a development team into Lean?
None of the companies we know have dropped Lean once they changed to it.

13. What are the key indicators to tell if a team will succeed in becoming Lean?
Developers who are
- Team players
- Open minded
- Used to rapidly changing environments and demands
tend to be the ones who can embrace Lean first and fastest.

14. Is it better to be Lean and then Agile or Agile and then Lean?
Lean is a specialization in the Agile field. Hence it is better to learn the Agile way of thinking first and then find the right specialization.

15. What did I forget to ask you about lean? Is there something about lean that you consider very important that we did not discuss?
Where must the focus be when introducing Lean - In the beginning people focus too much on the toolkit - not on the project, which has to be delivered using Lean. Take a step back once in a while and ask yourself: Is my current work in favor for the project or in favor for the process?

In co-operation with Antonio Sanchez, Information Technology, California State University of Fullerton