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:

Scrum Guide 2013

Ken Schwaber's Blog: Telling It Like It Is

Jeff and I have been working on the next revisions to the Scrum Guide. We will be presenting a webinar about it within a month or so.

We first presented and published Scrum in 1995 at an OOPSLA conference in Tampa, Florida. Almost twenty years have passed. Agile and Scrum have succeeded far beyond our expectations. Actually, we never had expectations beyond using Scrum for ourselves, so anything more was easy.

Between 1995 and the publication of the Agile Manifesto in 2001, Mike Beedle, Martine Devos, Mike Cohn, Deborah Stenner, Tonya Horton, Will Smith, and Alan Buffington all moved Scrum forward, using it and helping us refine it.

After 2001, I started holding Scrum training classes, first called Scrum, then Scrum Master, then Certified Scrum Master classes. Some of the people in those classes had epiphanies. They wanted to help spread Scrum through training and consulting. Some of them (and…

View original post 140 more words

Building software vs building bridges and going forward …,_instrument_man,_working_on_new_construction_bridge_at_Norris_Dam.%22_-_NARA_-_532685.jpg#filelinks

I was in NDC 2013 (thanks to Johannes B) and went to a session from “Jez Humble” titled “(Re-)architecting for Continuous Delivery“. There he opened up the old comparison of “building bridges vs building software”.

With that Jez tried to explain there are significant differences in architecting a bridge vs architecting a software. One of his points was that you get an expensive architect to design and cheap construction worker to build a bridge whereas you get both design and building being expensive in software. Of course this point was fun intended.

One thing came to my mind out of this was that the bridge construction is tangible but software is not. (Of course this is obvious :D) And we are at a significant disadvantage as software builders due to this. (This is not news to anybody either :D) What intangibility does is it restricts the all important direct feedback to the builders (of software) at the building phase. What I mean as direct feedback is to get the feedback from war end or from where it is being used.

Compare with bridge building:

When you start constructing a bridge, once the two end points are identified, the builder can measure whether the each brick (or bar of steel) is in alignment throughout.  After every single brick put on, the builders can get the direct feedback since the output is tangible. (Nowadays you don’t do this as there are much better ways of getting feedback but still this is a possibility)

When it comes to building software, the builder cannot obtain such accurate feedback, since the output is not tangible at the source. Of course there are feedback mechanisms available for software builders such as compiler errors, test failures, build breaks, code analysis tools, etc. But these are not effective as bridge building feedback due to feedback being not direct. (meaning you get the feedback from builders computer and not from where is going to be used and those are not accurate either) One reason for this is that nobody knows where the software is going to be used. (If you consider bridge building, it is like bridge is build on a lab and copied all over the world:))

Good news is that we are improving over this:

Consider old days where we did software building in waterfall way. The builder has to wait many months if not years to get the first direct feedback. By the time this arrived, the builder may be working in another project.

Through subsequent iterative development and Agile movement, the software industry focused on making this feedback loop much shorter. Typically within two weeks time, the builder get some level of indirect feedback and within less than 2 months you would get direct feedback (from production). Good improvement but with added complexity in current business environments, this two months waiting period seems too-long now.

Continuous delivery:

This is where Continuous Delivery (CD) would come in to rescue. So what the software world has done is not only to reduce to feedback cycle time but also to get the feedback from to the battle field itself (direct feedback). This would significantly counter the disadvantage of intangibility.

By maintaining a CD pipeline, you can get the feedback very quickly (after some minutes from code check-in) and from where the software is used. To do this, we have made the software delivery (incremental change) ever so lighter, even up to a level where there can be a release to production for adding a shade to “order” button. Isn’t this similar to construction worker getting feedback after every brick he laid on?

In conclusion, the software will never be tangible, but CD has done a significant work of cutting some corners of intangibility.

PS: It seems like bridge as also not safe and reliable as we think.