Archive for February, 2011

Where Does Experience Come From?

Comments Off on Where Does Experience Come From?

People need to make their own mistakes in order to acquire experience. It feels strange that the same mistake needs to be made so there is a tendency for people to preach on how things should be done, “I tried that and that didn’t work!

Yet, this time it might work.  For people to grow, they sometimes need to commit their own mistakes. It reminds me of the saying “Good judgment comes with experience, but experience comes from bad judgement.” This means we should learn from our mistakes, even if sometimes people think old ideas will work when conditions change.

The Speed of Trust

Comments Off on The Speed of Trust

Images source: Pierre Beteilles photostream

The single most important factor of speed is trust. If there’s one thing you should focus on as a manager, it should be trust. By winning the trust of others and having trust in others, you can get things done. If you don’t have trust, everything slows down – decisions, procedures and processes. When things go slower costs increase and productivity decreases.

In knowledge-based work, you like to make decisions on getting the work done. If people have to report to their immediate boss and that boss in turn reports to a higher boss, this situation slows down things. Managers shall of course be informed but decisions need to be taken by the ones who actually do the work.

In Stephen R. Covey’s book “The Speed of Trust” a very simple and ingenious formula is used to visualize this. Trust affects two outcomes:  the first is speed and the second is cost. When trust goes down, speed also goes down and costs go up.

When trust goes up, speed will also go up and costs go down.

The Agile manifest acknowledges this with “… we have come to value: … Customer collaboration over contract negotiation”. Focusing more on the contract than on customer collaboration shows that trust is low. One of the parties involved doesn’t trust the other; there is the fear that the relationship will be affected if there is no proper contract.

When taking on an endeavor, team members are anxious. When you take on a project and you’re not sure if you can pull it off, it’s natural to hesitate and be and anxious.. The more that’s at stake, the more energy is lost by the anxiety. However, it is also true that people tend to focus better on what’s important if there are more things at stake.

The Knowledge Cake

Comments Off on The Knowledge Cake

A project is a temporary organization created to help the line organization. This means that the knowledge for a specific project comes from the line organization. When a project starts, the knowledge of what will be accomplished often looks like this. If you doesn’t have access to a line organization that have any previous knowledge about the domain it’s becomes much harder. Then interviewing future end users becomes the only way to secure that you are on the right way.

The Knowledge Cake

When the project ends, we have identified many of the things we didn’t know before the start of the project. At the end of a project, it is important to transfer the acquired knowledge back to the line organization or the one that will work with the system. The big challenge is spread the knowledge about why things become in a specific way, often a lot of considerable has been taken into different solutions and when a specific solution is chosen the team often know why it couldn’t be done in 9 out of 10 other probable solutions. Often only How and What are documented and why is forgotten and never documented, and it’s often the question of “why” you comes back for when rebuilding part of the system in future development. The question of how and what are quite easily documented in software development. You can look on the database or the source code. It is therefore a great idea to sum up how you got to the specific solutions after design workshop so the question of why also can be traceable.

The Competence Learning Model

Comments Off on The Competence Learning Model

Competence consists of two components – knowledge and ability. This model describes the development of skills – the theory of competence staircase.

The Competence Learning Model

Level 1: Unconscious Incompetence Level 1 – the person is not aware of the existence of the skill.  He might have a naïve opinion about the skill or is not aware that it exists. Transition from Level 1 to Level 2 To get from unconscious incompetence to conscious incompetence the person has an idea of the skill and has to be inspired. You can’t dream of something you haven’t heard of.

Level 2: Conscious Incompetence When the person becomes aware of the existence and relevance of the skill, he reaches conscious incompetence. When people know they are incompetent, the start to wonder if it is something they want to be competent in or not. If people think the skill is not relevant, all efforts will be in vain.  Before continuing, they need to be motivated about learning the skill.

Transition from Level 2 to Level 3 To be competent, a person needs information and practice. The person has to learn and practice the new skill and explore the new skill. Developing a skill means using it in new situations and leaving one’s comfort zone, creating a sense of risk and anxiety, giving the feeling that there is a loss of control over the outcome. If you a never are willing to fail you will never leave you comfort zone, and therefor never evolve.

Level 3: Conscious Competence Once a skill is learned, concentration in performing the skill is the next phase. People rely on theories they remember – fragments of a text in a book or a similar situation. They should be able to demonstrate the skill to others, but they are unlikely to teach the skill effectively.

Transition from Level 3 to Level 4: This transition involves continuous practice of the new skill. It involves leaving one’s comfort zone frequently.  Demonstrate how this skill helps you and what can be done to improve the result, Ask, have I learned other skills that I think will generate benefits when I master them?

Level 4: Unconscious Competence Practice makes perfect as the saying goes.  Constant practice of a skill eventually puts it skill in  the unconscious part of the brain, becoming second nature. A common example is driving.  You hop into your car, turn on the ignition and go without thinking twice.  It’s a skill you practice every day, or several times a day. How would a professional rally driver perform if he had to think about his next maneuver and the speed he has to reach to get to the finish line?

Beyond Level 4:  Reflective Conscious Competence This model has been establish for many years, but also criticized for some of its flaws. I’m prepared to support the argument that there is a fifth level – reflective conscious competence. I am in favor of this fifth level because I think the best teachers are those who can demonstrate skills and also teach these skills effectively to others. It’s in fact one of the most important reasons why I wrote this book, as it allows me to reflect on my profession. Over the years I have had mentors who helped me reflect on aspects of my life and work.  An important task is for you to help others reflect on their work.  Sit down with your team regularly and review their work.

Summary of the Competence Learning Model An excellent lesson that I learned from the competence learning model is to rally people to your side (customers, stakeholders, team members, wives). First, you inspire them to get them up to the conscious incompetent level. Teachers and trainers commonly assume trainees to be at level 2, and focus their efforts toward achieving level 3. You can’t dream of anything you can’t imagine, and you can’t imagine something you don’t know anything about. People grow from training only when they are aware of their own need for it and know what  personal benefits they derive from achieving it.

See the invisible

Value of Knowledge

Comments Off on Value of Knowledge

The development of the Internet has changed the value of Know-What because when information is nearly free, the value of knowing it decreases. For example, hypochondriacs can now do a self-diagnosis after reading about their symptoms from medical forums on the Internet. Or look at the Encyclopedia Britannica. It was outmanoeuvred by Wikipedia in a matter of mere months. Decades of total market dominance had swung the other way against them.
When information is nearly free, what now becomes more valuable is Know-How. If you look at efficiency in knowledge-based work, there is easily a 10 difference factor on productivity between people. And that’s not because people work 10 times as hard, it’s because they work 10 times smarter. That comes from Know-How and knowing the right persons.
When you master one technology, technologies related to it are also easily mastered because you understand the foundation and principles upon which that technology depends upon. If you know much about a specific domain, you can easily be more efficient. In the knowledge-based economy, people like to collaborate with people who share common interests and values. People get together in small communities and forums and discuss what interests them. If someone joins but does not contribute to the sub-cultures’ common interests, they don’t have any status. Status in the knowledge-based economy comes from your contributions.

Know-How is Valuable in the Knowledge Economy
The power and ability to influence in the knowledge-based economy first comes from how you know and how much attention you put on value. The person with the most influence on communities and sub-cultures are those who contribute regularly. The ones that contribute to a network are valued and respected; the ones who only consume other people’s contributions are seen as leeches. That decreases the value of the network.
In forums, people who contribute too many answers to problems are considered gurus and people who only ask questions are considered newbies or freeloaders. If a network or community is too general and there are too many freeloaders, the circle of contributors to the network becomes narrower and closed. The more contributors there are and the more friends you have, the higher up in the hierarchy you get.
If you’re not gaining knowledge and experience, you’re losing competence. You either grow or shrink. To develop a team, a culture that calls for both personal and team development is necessary. To develop more knowledge, you also need to develop the right attitude towards knowledge and teamwork.
Development is mentally difficult because that’s what we need to reconsider ourselves. Many of us have learned through years of socialization and school systems that being right is good. If you are right, you are rewarded, and if you are wrong, you are punished.
As a result, many people become obsessed with being “right”. But what does this lead to? It convinces us that one way is more “right” than others and that which is different is wrong. To develop, you have to realize that the way things were done before was not necessarily optimal for its outcome, and therefore you were wrong. If prestige was involved in the “right” way, it is difficult to re-evaluate the situation and develop. So the feeling of being right can be dangerous because it doesn’t help us develop.

Aristotle’s three types of knowledge

1 Comment »

Aristotle was a Greek philosopher (384 BC – 322 BC) and is one of the most important founding figures in western philosophy. He systemized a lot things and created comprehensive system of the western philosophy within the field of moral, logic, science and politics. He classified knowledge in three different types Episteme (scientific), Techne (Skill and crafts) and Phronesis (Wisdom).


  • Episteme (Scientific knowledge) Episteme means “to know” in Greek. This is the kind of knowledge you get from for example books it tells you about the world and how it works, this is the theory of something.  This is explicit knowledge that is easy to store and transmit to others. Good example of explicit knowledge (Episteme) is Wikipedia or encyclopedias.
  • Techne (Skill and craft knowledge) The greek work Techne translates to craftsmanship, craft, or art. People are not often aware of the knowledge they possess or how it can be valuable to others. This kind of knowledge is not easy to share; you have to learn it yourself by practice. A common example is the ability to ride a bicycle if you have an easy written instruction set on how to ride a bicycle please send me a email so can I forward it to my four year old son. This type of knowledge is of very common in software development and comes with experience.
  • Phronesis (Practical wisdom) Phronesis means practical wisdom in Greek, Aristotle distinguishes between sophia and phronesis. Sophia (translated to wisdom) is the ability to think well about the nature of the world, discovering systems why the world is the way it is. Sophia is the ability to find universal truths and theories. Phroneses is the ability to realize how a specific goals or value is reached. Phroneses includes aspects of a situation, critical analytical reflection and for scrutinizing knowledge systems, practices and impacts of goals which easily are take for granted.  When having the needed “Episteme” and “Techne” of a specific domain you can develop the capability to find the “right answer” in a particular situation, which is what phronesis is about.

One of the interesting observation is that there is some knowledge that are easy to learn throw studies some that you have to practice yourself and some kind of knowledge are developed through reflection of the scientific knowledge and your craft knowledge of a specific domain which leads to a practical wisdom within that domain.


Other post on knowledge:

How the Understanding of Why Raises Productivity!

Comments Off on How the Understanding of Why Raises Productivity!

One of my favorite authors Dan Pink, wrote this great article Think Tank: Have you ever asked yourself why you’re in business?

Knowledge or Almost Knowledge

Comments Off on Knowledge or Almost Knowledge

Many people confuse know-what with know-how.  If I asked you if you know what a buffalo looks like, you would probably say yes. But if I asked you to draw one, you wonder whether buffalos have long hair, how many horns they have, if they have long legs, and how tall they are.

In today’s society, people tend to know about many things but their knowledge is quite shallow. This is because people are different:  some are extroverts, some are introverts. You tend to think extroverts know more because they show it more easily.

Just because one person knows all the new features in the latest framework, it doesn’t mean he knows anything of value when it comes to realization. When we interview people for new positions, they tend to know everything that’s new, but when we ask them how they work with technology and how that technology differs from earlier technologies, you soon wonder if they really know things or just almost know things. They are either very vague or clear in their answers.

Speed of Knowledge-based Work

Comments Off on Speed of Knowledge-based Work

If productivity is a product of value/cost, the speed of knowledge-based work might also be viewed as the speed of how quickly you create that value/cost. If the product of knowledge-based work is the result of a team’s knowledge and creativity, the speed is how quickly that team can produce it. In order to explain efficiency and effectiveness, I created a simplified formula:
Speed of Knowledge Based Work
This is of course only a simplification, but it does help us to analyze the components that make us succeed in a new era, where teamwork and collaboration are the most important factors in completing a journey towards something that you can’t predict from the start.

The Process of Knowledge-based Work

Comments Off on The Process of Knowledge-based Work

Let’s simplify what knowledge-based companies do, in order to analyze what the process of knowledge based work.
1. First, an idea is born from at least two previously known ideas that are combined in a new way.
2. Second, the idea is “sold” to one or more stakeholders that believe in its future value. Their belief is that the value of the product or service will be larger than the costs to develop it.
3. Third, the idea is transformed – by knowledge and creativity – into a product or service.
4. Fourth, it is “sold” to end-users by the stakeholder on the company’s behalf.

The process

The Project Triangle Turned Upside Down

Comments Off on The Project Triangle Turned Upside Down

The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered. The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.


The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.
Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas. This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”. So wouldn’t it be great if you could avoid building features that will never be used?

Burndown Chart Makes Projects a Sport!

Comments Off on Burndown Chart Makes Projects a Sport!

BowlingWhat makes sports so engaging is that when someone understands the rules they immediately knows how good a specific throw was.  How fun would bowling be if you didn’t have direct feedback on how many pins you have hit? If you instead got a progress report from your project manager once a month, with the conclusions of last month’s game.

But this is quite common in today’s knowledge based work people don’t know if today’s work effort was a complete failure or a success. Three month from know they might get a “bug report” that indicated that something this week wasn’t optimal. How easy is it to get better and realize what lead to success if there is no natural feedback on your work. Feedback is essential for engagement.

This makes the “monitor board”/”agile dashboard” with burndown chart to a great tool. Everyone can see what no one start working with, what someone is working on and how things are going relative to the plan. People tend to understand how things are going and get more engage that people who get reports or review of work they did three month ago.

Agile Dashboard

Used with permission from Henrik Kniberg‘s source “Scrum and XP from the Trenches”.

Through detailed planning in the short term and follow up on a daily basis in a visual way everyone understand how the co-operative game goes. You know when you are in trouble and you know when you’ve made a strike. This creates job satisfaction and commitment.

Everyone are happy when they know they made a strike. You know it’s the best you can do you feel satisfied. It’s the same in work life people feel good about themself if they know they done a good result. As a project manager this is a great tool, because this creates transparency, people know when they need to start focusing on delivery without you being there looking over their shoulder. I use to end my presentations about Scrum with showing the following video, in order to show how powerful visualization and messurement is.

If You Adapt to Change! How Do You Handle the Price?


A couple of days ago I wrote a blog-post “Plan-driven versus Agile = Predictive versus Adaptive”, the first comment I got on the post was a question from Hila Annis about how are these changes are priced. A great question and here is an explanation.

Hila Annis question:

I like your entry but I have a question – how are these changes in what the customer wants priced? I mean, in the end, we’re talking about a business, and if customer signed off on B but wants C, how do you price these changes along the way?

My Answer:

The answer is hopefully nothing! Let me explain a couple of principles and then I will get explain why it shouldn’t cost the customer anything.


First of all agile is not about selling or delivering the (B) + (Something) it’s actually to deliver (B) + (Something) – (Something else). In order to explain how the process works I will explain

  • Statistics about features never used
  • The project Iron-triangle is turned upside-down
  • Time boxing
  • Product backlog

Features Never UsedStandish report on features never used

In a 2002 report from The Standish Group, an investigation was made into failed projects to see how much the built-in features were used. They found that 20% of the features were used either always or often. The interesting part was that 45% of the features were never used. There could be many explanations for why features are never used in a system or product. But if you ask stakeholders to give you all the requirements up front, you end up with a lot of things that will never be used. If you deliver work in small pieces and work first on the first priority and also allow stakeholders to re-prioritize work, this problem can be addressed.

The Project Triangle Turned Upside Down

The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered.  The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.


The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.

Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas.  This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”.  So wouldn’t it be great if you could avoid building features that will never be used?

Time boxing

Time boxing means that you budget the project based on time and not scope. You plan to have a specific crew in a specific time. You work for example for 4 iterations that last 3 weeks with a 4 person crew, it becomes what it becomes during that time. That way you can plan a budget.

Conclusion so far:

If you do big upfront design and requirement you will not capture all requirements and not understand what’s creates 80% of the value for the customer. Let’s look on some tools that help you handle this and how this might work in Scrum.

The Scrum Process

When planning the project you start with some requirements either as a user story, scenario or as a use case. Then you make a rough estimate of what it will cost to deliver that requirement. Then you order them all in a product backlog. All requirement have a unique priority, two requirement can never be prioritized the same, someone is always more important. Then you look on all requirements and their estimate and summarize the cost and then you got a rough budget of what it will cost to implement all requirements. When you start the first iteration (called sprint in Scrum) you look on how many persons you have for example 4 persons working on this project for 40 hours a week and the iteration will last 3 weeks. This means that you take out the top requirement until you reach  360 (4 x 40 x 3) hours of planed work. This requirements cannot be changed from now, but all other requirements in the backlog can be change and re-prioritized or you can remove or add new requirements. At the end of each sprint everything that has implemented is demonstrated or even better delivered for use. When you demonstrate and users use the software new requirements will evolve, they might say “When I see this you will need to do this also, otherwise this has no value!” Now the backlog grows and the value of all implemented requirements and all new are higher then what you budget the project from start. But at the same time the things that goes down in the backlog is the requirement that wasn’t prioritized.

The Product Backlog


The trick is not to sell a project that have a “fixed” scope but a project that have fixed budget, time and quality. The thing that is variable is the scope. This way the customer will not get all requirements that they thought when the project was planned but because the customer can re-prioritize whenever he like he will be able to adapt to new knowledge and therefore get the things he appreciate most at the end and within a fixed budget. If the customers would like to implement the requirements that fell out of the budget you can directly give him a price of what it will take to implement them. But often they will have change their mind and realized that those requirements will not produce any business value.  This way it also gets easy to argue for further development that is outside the original budget. If we added requirements that where estimated to 40 hours and they where prioritized higher than something estimated 40 from start, it’s not strange that the first requirement is not done within the budget. If you get 40 hours on something you have to remove something else worth 40 hours. The requirements that will not fit inside the budget will not be implemented or you have a good foundation for a new “offer”. This way the business value of (C) gets greater than the value of (B). Changing your mind when you have acquired new knowledge is just a benefit, a late change in requirement are a competitive advantage.

So hope this answers your questions Hila Annis!

Introduction to Knowledge

Comments Off on Introduction to Knowledge

In a knowledge-based economy, the core value in creating activity is to use information and to combine it with knowledge produce something more valuable. For example, developing software is justified because the value that comes from the system is more valuable than the cost of producing it. There is no clear definition of what knowledge is or how it’s obtained. Knowledge is a much broader concept than information.  To analyze knowledge, a distinction must be made between different kinds of knowledge.


Know-what is about knowing facts. Example are:  who is the prime minister of India? Which team won the Stanley Cup in 2006? These kinds of knowledge are easy to obtain simply by “googling” the question. This knowledge is easy to obtain from the Internet.  Another example:  you can prepare a presentation on Chinese pottery with pictures in less than an hour. In some complex areas, workers must have a lot of this kind of knowledge in order to do their jobs. Lawyers and physicians need to learn many facts for them to be successful.


Know-why knowledge refers to principles and laws of nature. It is the kind of knowledge that underlies technological development and is sometimes referred to as scientific knowledge.


Know-how knowledge is about skills and the capability to do something. This kind of knowledge has more to do with personal competence; for example, a businessman who judges market prospects for a new product, or a personnel manager who selects and trains new staff. This knowledge takes time to obtain and master.  You need to practice and get coached; you also have to leave your comfort zone to develop your know-how.


Know-who involves information about who knows what and who knows how to do it. It involves the formation of special relationships, making it possible to get access to domain experts. Know-who is often the knowledge of the internal structure of an organization, network, or a specific industrial domain. In the knowledge economy, it is all about your personal network.

Learning these four kinds of knowledge takes place through different channels. The Know-What and Know-Why are obtained through reading, attending lectures, and checking the Internet.  The other two kinds of knowledge are rooted primarily in practical experience.

Peter Drucker’s View of Knowledge-based Work


Peter Drucker is one the most famous management consultants. Business Week even called him “The man who invented management”).  He coined the term “knowledge worker”. During his life he emphasized that economic growth has to come from knowledge-based work rather than from the industrial revolution’s thinking about manufacturing.

What Drucker meant was that the difference between manual work is visible, specialized, and stable; knowledge-based work, on the other hand, is invisible, holistic, and ever-changing. Unlike manual workers, knowledge workers use their situational knowledge to get things done in a dynamic environment. They are almost always formally educated and are called upon to run and change their functions and organizations simultaneously.

Knowledge workers acquire knowledge through a combination of education, experience, and personal interaction, and then use that knowledge to holistically achieve organizational goals in changing environments. This work is generally much more project-oriented than manual work.

To understand Drucker’s view on knowledge-based work, let’s analyze Frederick Taylor’s view of manual work and how it differs from Peter Drucker’s view of Knowledge Work.

Frederick Taylor on Manual Work Peter Drucker on Knowledge Work
Define the task Understand the task
Command and control Give autonomy
Strict standards Continuous innovation
Focus on quantity Focus on quality
Measure performance to strict standards Continuously learn and teach
Minimize cost of workers for a task Treat workers as assets and not as costs

(Source: Reinvent Your Enterprise, by Jack Bergstrand)

One of the most important messages from Drucker is that productivity comes from very different factors rather than from physical or manual work.

Manual Work Productivity Knowledge Work Productivity
Work is visible Work is invisible
Work is specialized Work is holistic
Work is stable Work is changing
Emphasis is on running things Emphasis is on changing things
More structure with fewer decisions Less structure with more decisions
Focus on the right answers Focus on the right questions

(Source: Reinvent Your Enterprise, by Jack Bergstrand)

Another observation that Drucker made was that knowledge-based work is difficult to manage because of its nature:  it expands and takes up all the available time. This is a natural consequence of focusing on quality instead of on quantity. If you combine quality with a non-deterministic process, time estimations will become very difficult unless you have a crystal ball. This is one of the big challenges for managers who administer business value in knowledge-based companies.

Agile Means Focusing on Knowledge Acquisition

Comments Off on Agile Means Focusing on Knowledge Acquisition

When you have delivered a system you know how that project was built. When a project precedes our ability to change, requirements decrease. At the same time, our understanding of what we are doing increases.

If we prioritize things that add knowledge at the beginning of the project and we minimize the cost of changing our minds, we could speed up the pace of understanding the requirements and therefore lower the risks of misunderstanding.

If we run our software project based on the waterfall model, we choose to increase the growth of our knowledge at the point of delivery.  This is the “moment of truth” when we see if everything holds together and we are delivering the expectations of stakeholders. It could go well or it could not, consequently leading to the disappointment of stakeholders. The problem is that the stakeholders acquired new knowledge during the project, and now want the system to do or be something they had not thought of at the beginning.

However, if you frequently deliver software to stakeholders and have the ability to adapt to their feedback, you can speed up your understanding of requirements. When the product becomes visible for the stakeholders, you get acknowledgement on what you have understood. If stakeholders don’t give any feedback and everything seams fine, you have just lowered your risks, as opposed to showing everything at the “moment of truth”.

Another great advantage is that by delivering your work in small parts, stakeholders are not 100% dissatisfied  because you gave them the opportunity to give their feedback on the small parts and you have adapted the requirements based on this feedback.

Plan-driven versus Agile = Predictive versus Adaptive


The inspiration for plan-driven methodologies came from other engineering disciplines such as civil and mechanical engineering. In civil engineering, it is less costly to change requirements during the design stage and it is more expensive to adapt to changes when construction has already started.

Therefore a lot of energy is put into the planning phase. When the drawings are specified and finalized, it is reasonably easy to predict the schedule and budget for the rest of the processes, because both the requirements and the technology are known. Once we have the construction plan, the construction is more predictable. The nature of these projects is to resist changes, because it costs too much to make them after construction has started.

Software development is different.  There is no guarantee that a good design will make construction predictable. In civil engineering, the time spent on construction design is often less than 10% of the project’s total budget.  In software development, it’s more common that over 50% of the total budget is spent on design and understanding requirements. When we adopt the civil engineer’s approach, anything that wasn´t planned causes a problem. We need to reach (B) as planned when the project plan (Time, Money and Scope) was approved.
Predictive vs Adaptive

Construction is less costly in software development.  So why not adapt to change as we learn more during the process? Changes in the requirements during the process of developing a system leads to increased information about the system, and thus enabling better decisions because of this additional information. This is how competitive advantage is gained.

If we could use methodology that allows us to change, we will know more without incurring major costs so it would be a mistake not make the required changes. If our methodology allows this, the output (the system or product) is going to be worth more than the product we would have had have from the original design (C) >= (B).

A Difference View of Success

The plan-driven methodologies defined success as the delivery of agreed functions on time and on budget. But agile methodologies promote the idea that there is something nobler to strive for, because sometimes the customer remains dissatisfied even if he got everything he asked for! This is because he got (B) but at the end of the project, he now wants (C).

Customers also adapt but if they change their mind about what they want and you prefer not to make the requested changes, problems could arise.. Either you or the customer will be disappointed.  Success for Agile methodologies depends on knowing more which makes it better for us to adapt to new goals. This gives the customer what he wants at the end of the project (C).


If customers don’t know what they want when the project ends, how can you design a system in the beginning when you don’t know what the understanding was? If your design isn’t good enough to predict the rest of the work, it won’t be such a good idea to design too much in the beginning of the project.

And if you cannot establish requirements you cannot make a good design and in turn, you cannot get a predictable plan. The Agile approach is to welcome change so if your assumption is proven wrong, you redefine the goal and set new priorities. At the end of the project journey (C) this new goal will be worth more than the first defined goal (B).

Because the customer and stakeholders are allowed to change as they learn more new things, the value of (C) becomes greater than (B). This of course builds on the idea that you manage to deliver (C) according to time and budget restrictions.

The conlusion of 2 be or not 2 be

A Historical View to Organizing Software Development [old obsolete version]

1 Comment »


When Alan Turing wrote his book On Computable Numbers, with an Application to the Entscheidungsproblem in 1936, he laid the grounds for computers science. The first “universal machines” were developed at Bletchley Park to decipher the Germans’ encryptions during the Second World War.

Between the 40’s and the 70’s computer science became more of a scientific instrument than a well established business technology.  It wasn’t until IBM and Apple introduced the PC and Macintosh computers got widely spread outside the scientific institutions and the largest companies. It was now software development really started to take off. A lot of software development companies that are large today where established.

Up until the 70s, programs often were quite simple and were operated only by those how created them. But as systems became larger, it also became more difficult to develop and organize software development.

In 1970, a director at the Lockheed Software Technology Center, Dr. Winton W. Royce, published a paper entitled “Managing the Development of Large Software Systems: Concepts and Techniques“.  Dr.  Royce presented a method of organizing software development in a more structured way. This technique was inspired by the manner in which engineering field a like civil engineering and manufacturing organized their development.

The basic idea is that everything is done in sequential phases. This means that every phase of a project must be completed before the next phase can begin. First, all the requirements are documented, then everything is designed based on the so called “big design up front” and it continued throughout the stages.

Each phase was handled by specialized groups like business analysts (for defining the requirements), system analysts (for designing the programs), programmers (for developing applications), testers (for testing applications) and deployment personnel (for overseeing operations). These groups communicated mostly in writing, and handed over work from group to group.

Managing software development with the waterfall model is to investigate what the system is supposed to do, make plans so that it does what it is supposed to do, and to stick to that plan. This model had its setbacks: first, people learned a lot from the first system requirements until they went into production and were used by users. This made it difficult to take advantage of what was learned in the various processes.

Another setback was it often took a long time between the requirement phase and the user feedback phase. . If you didn’t figure out what the users wanted or the users themselves didn’t know what they wanted, that meant more time and money had to be spent to change or adapt the system to users’ needs.

In defense of Royce, it would be fair to say that he actually did warn that these things could happen and therefore proposed an iterative way of work. But no one adopted this part of his model. That’s how it came to be called the Waterfall.

When the US Department of Defense needed a software development process, they looked at Royce’s paper and they adopted a part of it (unfortunately they adopted the worst part) and named it DOD-STD-2167 (Department of Defense Standard 2167).

When the NATO later needed a model they thought that if it was the best model the US military could find, then it ought to be adopted. And from there, more and more people adopted the theories of the waterfall. Even if the US Department of Defense changed the standard in 1995, it remained the basis of what the academic world is teaching to this day.

During the 90s, new methodologies were developed as a reaction to the plan-driven waterfall model. Plan-driven methodologies reflect either the waterfall model or the iterative model, like the RUP (Rational Unified Process).

These methodologies, however, had something in common: they focus on a construction and planning plan in the beginning phase and stay with that plan. Plan-driven methodologies were considered bureaucratic, slow, demanding, and inconsistent with the way software developers actually perform effective work.

Many people were very frustrated on the demands presented that developers became more agile to business demands, adapting better to knowledge gained during the project.

New methodologies like XP, DSDM and Scrum conquered the world of software development in the 21st century. Many of the agile methodologies were inspired by New Product Development Game, an article written by Hirotaka Takeuchi and Ikujiro Nonaka and published in the Harvard Business Review in 1986. This article is often used as a reference and could be considered the birth of agile methodologies.

To summarize the history of organizing software development, I will use the words of agile guru Martin Fowlers:  “from nothing, to monumental, to agile”.


The Difference Between Incremental and Iterative

Comments Off on The Difference Between Incremental and Iterative

The difference between an incremental approach and an iterative approach is that the incremental approach does not require going back and changing things that are already delivered; the focus is only the requirements that have not yet been implemented. In the incremental plan, you don’t learn by the previous work, and the final product is not based on knowledge acquired during the journey. Here is a visual example of the difference between the incremental and iterative approach:

Incremental vs Iterative