Skip to content

Category: principlesSyndicate content

Open Space, an agile way of meeting

June 9, 2009 by Mendelt Siebenga

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.

Seven Principles of Lean Software Development

January 20, 2009 by Przemysław Bielicki

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:

Seven Principles of Lean Software Development - Eliminate Waste

January 9, 2009 by Przemysław Bielicki


Picture courtesy of Phil Romans@flickr

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.

Seven Principles of Lean Software Development - Create Knowledge

December 11, 2008 by Przemysław Bielicki


Picture courtesy of J.C.Rojas@flickr

"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.

Seven Principles of Lean Software Development - Build Quality In

December 4, 2008 by Przemysław Bielicki


Picture courtesy of WayTru@flickr

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.

Seven Principles of Lean Software Development - Defer Commitment

November 6, 2008 by Przemysław Bielicki


Picture courtesy of _fabrizio_@flickr

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.

Seven Principles of Lean Software Development - Optimize the Whole

October 2, 2008 by Przemysław Bielicki


Picture courtesy of aussiegall@flickr

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.

Seven Principles of Lean Software Development - Deliver Fast

September 11, 2008 by Przemysław Bielicki


Picture courtesy of johnthescone@flickr

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.

Seven Principles of Lean Software Development - Respect People

September 4, 2008 by Przemysław Bielicki


Picture courtesy of Elvire.R.@flickr

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.

10 Key Principles of Agile Software Development

April 18, 2008 by Kelly Waters

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

Best of AgileSoftwareDevelopment.com