Iterative thinking

768px-Screwtop_spiralTHE “WATERFALL” VS “AGILE” BATTLE SEEMS TO BE OVER BY NOW AND AGILE HAS EMERGED AS THE WINNER.  Still the current software development landscape is far from the order. It is filled with many tools, processes, frameworks, methods, methodologies, best practices, procedures (Be my guest …)

This drives many software development teams in to confusion. Outcome of this confusion is that teams have been following processes, methods, etc. just as a recipe. It can be scrum, XP, Lean Start up or even SAFe but you will see many teams use them without understanding the underlying thinking. Probably this is one reason why the (almost) movement “Be agile” had to be born.

It is obvious that teams should not use “Agile recipes“. There is no better reason than the first value of Agile manifesto to show why any team should not use a recipe . The first value states ” INDIVIDUALS & INTERACTIONS over processes and tools”. What has most value is the team itself and the interactions around it, not the use to tools. Teams should understand the basic underlying thinking of these Agile methods in order to be successful.

So the first question is what is the underlying thinking and the second question is whether is there any similarity of this underlying thinking? There is very simple answer to both the questions. All these Agile methods are based on a simple concept of  “Iterative thinking” (at least what it should be). Applying any Agile method just as a tool will not guarantee the success of the project but if one can find the success if he/she understands and applies iterative thinking. In my view, there is no need to use ANY tool or method if one can master and use iterative thinking in a project.

So the big question is what is “Iterative thinking”?

Iterative delivery


Iterative thinking is connected to all the areas of software development. Iterative planning, Iterative design, Iterative development, etc. are examples. Iterative thinking can be simplified in to “it is all about slicing the customer need and deliver the solution in a progressive piece meal manner“. One important factor here is that each delivery should ensure that it is build on top of previous delivery and the future deliveries can be build on top of it.

The outcome of the “Iterative thinking” is the “Iterative delivery” and it is an extremely important concept when it comes to complex domains, scopes, etc for the success. When it comes simple software problems, the iterative thinking becomes less visible and just using a recipe can lead to success.

The “Iterative thinking” can be illustrated in an example. Let’s take typical user management feature:


  • The first iterative delivery can be a simple screen where users can be added to the system and the added users are listed in a crud list. There are no validations for the user creation form. Not much thought given for the design of the user management feature. The main objective is to get the initial thinking in sync between the development team and the problem owners. This delivery can be called as “User management Spike”.
  • The next delivery can be “Basic user management” where more features are beefed up on top the the user management spike. It can be that user creation form has more fields and validations are added, passwords are encrypted, etc. Also the basic design of the the user management has emerged.
  • This can be extended to further iterations till the problem owner is satisfied with the given solution.

(This should not be confused with incremental delivery. See this


When it comes to complex software problems (such as automated vehicle guidance systems, etc.) there will be many more iterations than a simple user management feature.

  • The first iterations can be that nobody touches the code and it is all about presenting (by PPT) team’s understanding on the requirements.
  • The next iterations can be further strengthen on design aspects of the system (if team feels a certain up-front design is required).
  • These iterations can be further worked on through providing basic integration tests.
  • This can continue from the first delivery to final user acceptance.

The magic behind the “Iterative thinking/delivery is rapid & constructive feedback. When a team follows the iterative delivery, the feedback would be specific (such as saying “I don’t need the “middle name” field here, add a new field called “Date of birth”, move the “address” to the bottom, show the last login date/time, etc.) This specific feedback would speed up the team thus resulting rapid value delivery which fits to the purpose.

So in conclusion what can be noted is that the important fact in Agile software development is not to use the tools, processes, frameworks, methods, methodologies, best practices, procedures, etc. as recipes but to understand the concept of Iterative thinking. The simple use of Iterative thinking can lead the successful project delivery even ignoring all the norms and prescribed methodologies such as Scrum.



Today’s problem and Tomorrow’s problem
Photo credit:

I am a great follower of Jim Highsmith and I am still fascinated by his concept “Today’s quality and tomorrow’s quality”. Reference

I read this long time ago and had a post regarding this as well. But what I realized recently is that the concept of today’s … and tomorrow’s … is more universal than it seems from the outside. It is applicable for many things beyond just quality in the software engineering.

One contrary application of this concept can be found in problem solving.There is a general struggle when it comes to how one approach problem. Going with Jim Highsmith’s concept, there are today’s problems and tomorrow’s problems. We waste lot of our resources (let it be money, time, etc.) finding solutions for tomorrow’s problem.

For example if you are planing a software system to be used by 5 million users (like Trello) without even writing a single piece of line, then it is a waste. In a realistic example, many software designers are being pushed on concepts of “re-usability”, etc. before even a single piece of line is written. [I think the term “Use before Reuse” was coined due to this :)] Finding solutions for those are simple waste of resources.

We struggle in classifying a certain problem to be today’s problems or tomorrow’s problems. As humans we always like to think big and therefore pretty much liking to find solutions to tomorrow’s problems. So it is not easy to identify and categorize whether it is today or tomorrow in the outset.  As I mentioned people waste lot of their resources on solutions for tomorrow’s problem. Let’s see how.

The resources are wasted due to the timing of the solution. In simple terms, if the problem is today, then solution would be for tomorrow. If you implement a solution for a today’s problem, it will give results tomorrow, not today. You have the pain of the problem today anyway no matter what the solution is. If you are sick, then the medicine will make you better tomorrow, not today. If you have a “quality” problem in your piece of software, whatever solution to that would result in improving quality tomorrow, not today.

If the problem belongs to tomorrow’s then where the solution belongs to? It simply belongs to waste basket.


Note: Jim Highsmith’s concept of today’s quality and tomorrow’s quality is not about finding solutions for tomorrow’s problem. It is about keep an eye about tomorrow’s problem, which is always a good thing. Avoiding tomorrow’s problems and finding solutions for tomorrow’s problems are two different things.

For example if you exercise thinking that you will become obesity in 10 years time, that is good. All lies in analyzing the problem not finding the solution like in Lateral thinking


Ken Schwaber's Blog: Telling It Like It Is

I am returning from the Agile Alliance conference. I thought I would share the answer to several questions that I was asked in my session:

1. What is “Agile”
Any software activity that conforms or attempts to conform to the values and principles of the Agile Manifesto for Software Development.

2. If you could add another value to the Agile Manifesto, could you state it?

We value practices, tools, consulting, coaching, and software organizational work that continuously improve their adherence to the Agile Manifesto
Tools, products, methodologies, processes, practices that only use the word Agile to market themselves to make money and whose correlation to the Agile Manifesto is coincidental.

View original post

What is waterfall?


Recently I have been involved in a discussion what is waterfall (of course in software development perspective).

The very first thing comes to the mind is that waterfall software development is a phased approach (over iterative Agile). You have got defined phases and boundaries to cross like “Requirement phase, Design phase, etc.”

If you stop for a moment and look in detail, you will realize that this is more of a description of the “Execution model”. Or how the Waterfall model is executed. But there is much more deeper conceptual definition if you look at from a business perspective.

When you look at software engineering from the problem vs solution concept, you can see it. Software is a solution for a business problem. And software engineering is all about articulating the solution.


So this is how the Waterfall approaches;

  • You have the “Business problem” and
  • You have a layer to “Specify the problem” (requirement),
  • Another layer to “Specify the solution” (architecture and design),
  • Another layer to “Develop the solution” (development),
  • Another layer to “Confirm the solution” (testing)
  • Final layer to “Apply the solution” to the problem (Deployment).

Through this you can transform the horizontal phases of waterfall to vertical layers and by doing so you can see how the waterfall development is really structured.

I don’t need to mention the waste and the confusion this causes when you have so many layers between the Problem and the Solution.

But Agile software development provides a much more compact approach which is more effective than Waterfall. In Agile, you just have two layers representing the Problem and the Solution. Problem is represented by Product owners (if you consider Scrum) and Solution is represented by Development team. By reducing the unwanted layers in the middle, Agile has reduced the waste and the confusion.

But as a note this doesn’t mean that you can avoid the needed steps like design, testing, deployment, etc. It is just that all are done within one layer


Relative estimates and bubble sort algorithm

While reading Mike Cohn’s article, I came across this comment What a cool idea when it comes to relative estimation techniques.

If you are to get the benefits of relative estimates, you need to get the relative sizing right (which is a challenge itself). But most of the teams struggle on this. Let me give you an example to illustrate this.

To illustrate this difficulty;

  • Team has 20 stories to estimate
  • They go through the backlog and establish the base story and mark that as 2 story points
  • Then they start from the beginning of the backlog and start estimating the relative size
  • 1st story is easy and you compare effort for that against the base story and mark it as 5 story points.
  • When it comes to 2nd story, you now needs to compare it with 2 other stories (base story and 1st story)
  • This adds on when you go further down the backlog
  • What happens is that you loose the sense of stories in the top of the backlog when you come towards the bottom of the backlog. Instead of having one common base story you tend to have localized bases since as humans we don’t have much RAM

There are options to avoid this (such as Triangulation, etc.) but what bubble sort algorithm offers is simple and effective than those.

How you can use is to first go through the backlog and give it a bubble sort. You don’t need to worry about what is the relative size of the story but just compare whether the current story is bigger or smaller compared to next story in the list.

See further

If you do this as the start, it will not have the problem which I mentioned above example. Further this will act as a good ice breaker for the estimation session.

Images are taken from and

Unknown unknown


Question 1: Do you know the problem? Yes. Do you know the solution? Yes. Then go and use waterfall.
Question 2: Do you know the problem? Yes. Do you know the solution? No. Then use Agile.


Question 3: Do you know the problem? No. Do you know the solution? No. Then use Learn startup.


Reference: David J Bland “Lean startups is not only 4 for start ups

Photo credit: