Category: principles
Last year I went to the European Agile Open conference, two intense days of meeting interesting and interested people and talking about all aspects of agile. I don't think I ever learned as much in two days. The conference was held entirely in the open space format and one impression I left with was that lots of the ideas we talked about there were also applied in the organization of the conference.
This week I had the pleasure of helping to organize my own open space event. The Open Space Code day in the Netherlands. We copied this idea from Alan Dean who has been organizing events like this for some time in the UK. I got the same impression, the dynamics are different, the goal is different but the event certainly feels like an agile project. I want to have a look at the similarities and see what we can learn from it.
Bookmark/Search this post with:
Lean Software Development has its roots in Toyota Production System and it helps software organizations optimize their processes and production methods in order to deliver their products to the market much faster and with better quality. Lean movement can be considered as a new development method that tries to identify and eradicate all problems and "disabilities" of old methodologies like Waterfall. Lean puts main focus on people and communication - if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied.
Lean Software Development subsequently gave birth to Agile Software Development methods and its main branches like Scrum or Crystal Clear. For many people who know the subject Agile is just another word for Lean or Lightweight.
In one of the most popular books on Lean subject, namely "Implementing Lean Software Development - from Concept to Cash", Mary and Tom Poppendieck explain how to implement Lean by following seven principles - principles that are some kind of Lean commandments:
Bookmark/Search this post with:
Peter Stevens in his newest post advices how to deal with current crisis using Lean methodologies. One of his advice is to eliminate wastes, not costs. I totally agree with it, more so it is one of the most important (at least for me) principles of Lean Software Development.
Software development organizations should always strive to produce the best products and to deliver only features that are of paramount importance to their customers. They should always try to develop those 20% of functionalities that represent 80% of the value. This need is more vivid and desired during such global business conditions. This could apply to all types of enterprises - you should eliminate all unnecessary steps and waiting periods; you should strive to get the value as soon as possible and to get only pure value without any waste.
In this post I will try to explain "Eliminate Waste" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
"There is no fool like an old fool" says popular international proverb. One of the meanings of this proverb is that people can make mistakes but they should learn from them. You are not a fool if you make mistake but you become one if you make the same mistake again. It simply means that you're not learning.
The same rules apply to the software development teams - it's much easier to work in an environment that encourages you to learn and to create knowledge. Why should you create knowledge? Well, the best way to learn something is to make mistakes by yourself but it wouldn't be wise to let all the engineers invent the wheel all over again. It's much better to teach them about what we already know, what works and what doesn't. It's much better and safer (yet a bit less effective) to learn from someone else's mistakes.
In this post I will try to explain "Create Knowledge" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
I was doing a quick research for this article using Google trying to find arguments standing for the claim that "quality is expensive". I was trying to find some resources saying that care for quality in the early stages of the software projects doesn't make sense and doesn't pay - I find it very difficult and I cannot share with you any reasonable links (maybe except for this one which refers to another post saying that "Quality Sucks").
What does it mean? It means that software people know that quality is very important. Why then quality of software products sucks in more cases than it rocks?
In many big corporations following waterfall model there is a special team named QA (Quality Assurance). This team's responsibility is (not surprisingly) to assure appropriate level of quality in the software product. This is fine, this is perfectly OK, except that QA is considered as a separate activity. This is the "Verification" or "Testing" box in the waterfall model diagram.
The biggest problem with this attitude is that QA team gets the product after it has been implemented and this is the root cause of all evil. QA is considered as something separate - we first do the product and then we care about the quality. This way of thinking is wrong. You should care about quality from the day one, before you write a single line of code.
Software teams should "build quality in" their products and QA should not be considered as a separate activity. Quality Assurance should be constant process of improving the product - QA activities and people should be involved in the development of the product during the development, not after when the developers are moved to another projects or even teams.
In this post I will try to explain "Build Quality In" principle from "Implementing Lean Software Development - from Concept to Cash" book. I will present few practices that will help your team build software with quality built in.
Bookmark/Search this post with:
No matter who you are, where you live and what your job is you have to make decisions. Some decisions are easier, some more difficult (e.g. which way do you want to go on the crossroad with traffic lights from the picture?). But why making decisions is hard? When you make a decision, how do you know it is the right one? What information (if any) you have to posses to make the right decision?
This problem can be referred as "Defer Commitment" principle. Very briefly it tells you to make the decision in the last possible moment when you have enough information to be sure you are going in the right direction. It doesn't tell to you to procrastinate - NOT AT ALL! It's a wrong thinking. It only tells you that you have to wait and collect the data and as soon as you have enough information, make the decision.
In this post I will try to explain "Defer Commitment" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Lance Armstrong won seven consecutive Tour de France races between years 1999 and 2005. Every year there were 21 individual stages and Lance Armstrong won "only" 4 individual stages in 1999, 1 stage in 2000, 4 stages in 2001, 4 stages in 2002, 2 stages in 2003, 6 stages in 2004 and 2 stages in 2005.
As you can see Lance Armstrong was not focused on winning each stage (quite the opposite). He was focused on winning the whole Tour de France - yet he had to keep close to the head of the race. And when you take a look at time differences between him and the second cyclist in the final classification you will be amazed - they were close to couple of minutes (out of 90 hours of total time!) It means that he was focused on winning the whole race - not to be the best and outstanding cyclist (he was not - I know because I watched many of the stages these years).
Speaking with the lean language Lance Armstrong was Optimizing the Whole - and he succeeded seven times winning the most difficult and exhausting cycling race in the World.
In this post I will try to explain "Optimize the Whole" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
Work in small batches
I've always thought that delivering small pieces of software is easier than delivering the BIG BANG product at once. Small software package is easier to manage than the big one, you can expect smaller amount of defects there, it is much easier to integrate it with existing software. Isn't that obvious?
On the other hand working on the new version for, let's say, six months without regular integration in the production environment (if integrated at all) will bring you much more problems. Defects will accumulate and just before the release someone will discover them. No surprisingly developers would have to work overtime to fix them.
Bookmark/Search this post with:
Software organizations have surprisingly more problems managing people than managing soulless machines. People are also surprised when they ask me what my job is all about and I tell them that I work with people most of the time. "But you are a software engineer - isn't your job about working with computers?". "You're partially right because I work in a team and program a computer using programming language to do what you want to do is much easier than >>program<< my colleagues to work with me to reach our team's goals" - I tell them.
Working in a team means not only solving technical problems, designing stuff and make decisions together. One of the most important factor that makes teams successful is Respect.
In this post I will try to explain "Respect People" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Bookmark/Search this post with:
10 Key Principles of Agile Software Development, and how Agile Development fundamentally differs from a more traditional Waterfall approach to software development, are as follows:
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle