Author Archives: Michael Badali

About Michael Badali

Creative Commons Attribution-NoDerivs 3.0 Unported License. Michael Badali 2004-2013

Do you have to be Agile?

While it will help you be more profitable and competitive I would argue that you do not have to be Agile. Why would an Agile Advocate say this? I have seen too many pseudo implementations that really do cause a lot of unnecessary pain. I have experienced too many instances of a leader saying they need to be Agile then making it impossible by their own actions. I have seen too much sabotage from people who just don’t want to change and others who see it as a threat.

Really take a look as see if it is something you want to do before you begin changing the way you are used to working.

It’s OK if you don’t adopt Agile thinking. One of your competitors will and you won’t have to worry about it any more…

Try it before you knock it!

At an Agile meetup I was chatting after the talk and someone told me that they had tried Kanban but it didn’t work for them. As a Kanban advocate I find it hard to believe that Kanban did not work. It works with any system you have and work well on its own. I decided to follow up and asked how did they visualize the work flow. They didn’t have a board, they had some software which was not displayed on a large monitor for all to see. I asked how did they limit Work in Progress. I was told they tried it but it didn’t really happen. I asked how they measured and reduced Time to Market. They didn’t… So, we can see they they didn’t do Kanban at all.

It reminds me of some ‘Scrum’ that I have seen where they put some stickies on the wall and have a 10 minute huddle as long as it does not interfere with their status meeting and the stickies on the wall are not complete or updated as they are using a software package to track things handled by the PM.

If you’re not actually doing it, meaning you’re not doing the basics, you are not doing Kanban and should not fool yourself nor claim it does not work. Same for Scrum. If your Sprint is not a fixed time from 1 to 3 weeks you are not doing scrum and putting stickies on the wall will not change that.

Are you really doing it? Try it before you knock it. You might be surprised how well it works.

Waterfall Works

In a discussion about the future of Software development I was saying that Waterfall just doesn’t work quoting statistics from the Standish and Forrester reports. 

From this discussion came one of the best quotes I have heard to date:

 ”Waterfall works, its just slow and expensive”

Companies cannot survive by being slow and expensive. (that is for government ;)

“The measure of intelligence is the ability to change.”
― Albert Einstein

“Those who cannot change their minds cannot change anything.”
― George Bernard Shaw

“It is not the strongest of the species that survives, nor the most intelligent, but rather the one most adaptable to change.”
― Leon C. Megginson

by Michael Badali

Planning Sucks

A friend told me about a company the worked at: Their planning cycle was 2 years long,  meaning that the moment work was started, it was already obsolete…

Here is the reality plain and simple:


A little planning, enough to get you started, has some value. Mapping out the future equals failure.

Having an inspiring vision of the product that leads people to do the right thing, now that is valuable…

by Michael Badali

Metrics are dangerous

I have seen things go terribly wrong from unintended but logical results of KPI, bonus conditions et al.

I recall having a very difficult time with a team lead who fought everything Agile tooth and nail. Finally one day the truth came out: He told me that his annual bonus required him to do the opposite of everything I was suggesting and there was no @#$%^ way he was going to give the money up.

Be careful what you ask for, you might get it!

by Michael Badali

Don’t Try Agile

Don’t Try Agile. Why create a massive disturbance in your organization unless you are going to make a big gain?

Don’t try Agile – if your Leadership does not really understand what is required of them.  - It will become something that technical people do and it will frustrate everybody and will be a miserable failure. Agile is not an SDLC is it a philosophy about how to get the whole company to work well together. Everyone who connects with the teams must embrace it to succeed.

Don’t try Agile – you will be miserable!

Don’t try Agile – if your Product Managers and Architects cannot break things down into logical bite size scalable modular pieces. – things will come to a grinding halt as they try to cram extras into a release and quality will drop as you try to push out as much out as you can amidst the noise and confusion.

Don’t try Agile – you will be miserable!

Don’t try Agile – if teams are not supported, in constant flux, don’t have a complete skill set. - Your work life will become hell, you will get nothing done and everyone will be unhappy including the customer.

Don’t try Agile – you will be miserable!

IF you do have leadership who understands and does what is needed from them to support the new way of doing things and the journey there, if you have excellent product ownership and architecture who focus on what is most valuable now and don’t try to plan the unknown future but create modular scalable requirements and guidelines, and if you have permanent self-managed cross-functional teams and they are the building blocks of the organization, you will find you are productive and happy and the customer is delighted. I have been there and it is awesome!!!

Agile is like pregnancy, you can’t be a little bit pregnant,  you can’t be a little bit Agile. Do Agile and you will have a joyful experience.

Do or do not there is no try - Yoda

by Michael Badali

Measure and Improve Throughput

The best descriptions I have ever heard for throughput or time to market were: “Customer to Cash” and “Concept to Cash”.

Minimizing the time between the customer go ahead and payment is an increase in revenue. Analogy: Right now you get paid a certain amount every 2 weeks let’s say. If you can find a way to get paid that same amount ever 12 days…every 10 days…if you get paid every 7 days you now make twice as much. Same for a company.

Reducing time from “Concept to Cash” gives you a serious competitive edge. The ability to put new products on the market before your competitors, the ability to adapt to changes in the market to keep your product relevant.

TTM is a holistic metric. It includes both the tech and biz parts of your company. It is an opportunity to get them to work together to be more profitable and competitive. This does not mean other metrics are completely useless but all too often companies focus only on the techies and how long it takes them to build when in reality the waste between steps have more impact to the throughput of the whole system.

Have the whole company see its throughput as something everyone is responsible for, have the whole team row in the same direction.

“If you could get all the people in an organization rowing in the same direction, you could dominate any industry in any market, against any competition” – John Kotter, Heart of Change

by Michael Badali

Being a Great Product Owner – Domain Knowledge?

Too often good product ownership is assumed be based on domain knowledge accumulated through many years in the same domain. In reality it is really about listening, observing, asking the right questions and truly understanding what is needed. A great Product Owner is always aware of what is important to the customers RIGHT NOW. Domain knowledge even from 2 years ago is not particularity useful. In markets that shift constantly such as those with 3-6 month product cycles knowing what is needed now is critical and continuous.

Product Ownership is a separate and valuable skill. 

By Michael Badali


Agile vs Lean

Agile and Lean are like Yin and Yang. Consider your left and right hands – Which hand do you want to keep? Both of course. Agile is a minimalist philosophy and Lean is waste reduction practice. They go hand in hand.

Agile and Lean!

by Michael Badali

“The hurrier I go, the behinder I get.” AKA Queue Theory

Early Queue theory? ”The hurrier I go, the behinder I get.” – Lewis Carroll

The 401 highway is my favourite example of the problem with Queues. At 100% of capacity it can take easily 3 hours to travel from Waterloo to Toronto.  At low capacity it can be done in ~1hr15minutes. Same route, same distance ~1/3 the time.

Sometimes to make a drink that is not full of garbage I mix Sunwarrior and Vega and pour it into my water bottle with a funnel. I noticed that if I just dump the powder into the funnel it clogs. If I sprinkle it in being careful to stay below a certain threshold I am done far faster than dump and fix the clog. Many times faster actually.

Based on the mathematical models (my personal experience verifies it) at about  65% of capacity things start to slow down. The more you try to cram work in the longer it takes to get done. It starts doubling quickly to the point that even a tiny addition halves the throughput.

So explain to me then how pushing for more work to get done makes things faster?

by Michael Badali

Limit Work in Progress

Most of us think  that if you answer the phone while typing an email scribble a note and feed the baby you are getting more done. There is lots of data to disprove that but also ask yourself, have you ever been annoyed at someone while they were time slicing you?

In fact task switching and context switching are major forms of waste  AND also sources of error. Getting in the groove is a type of concentration that is invaluable. The opposite of writers block if you will.

Try a simple test: get your team together, each person except one has a piece of paper and the exception has a pen. Each person in turn hands the paper to the ‘scribe’ and the scribe writes the persons name and hands it back, then takes from the next person until complete. How long did that take?

Then try this but instead of writing the person’s name just write the first letter cycling through the group then back to the first person and write the second letter etc…

How long did that take?

In my experience about 3 times as long.

Also, most people tend to work on the easy task and not the one of highest Value.

“We’ve already seen that multitasking on the road is the equivalent of drinking and driving. Other research cited by Medina shows that people who are interrupted – and therefore have to switch their attention back and forth – take 50% longer to accomplish a task, and make up to 50% more errors. -

by Michael Badali

Visualize the Work Flow

Why is this so important?

It serves as an Information Radiator. All you want to know in one place, updated easily, accessible, digestible. No more lengthy status meetings. Status is live and available 24/7. Blocked tasks are plainly visible as well as the duration of the blockage.  Time and energy  can now be spent on solving problems and producing Value.

Now that you can see the Value stream mapping you can look for opportunities to improve the workflow. This involves removing Waste and moving from the current state to a desired future state.

Through Continuous Improvement you will reduce your Time to Market which you will reduce your costs, improve market position and delight your customer.

by Michael Badali



Art theory teaches us that the spaces, the emptiness in what you create is  important.

True in workflow as well. One aspect of Lean is focusing on what not to do.

by Michael Badali

Empty Cup

Before you begin any learning I recommend keeping the following in mind:

A university professor went to visit a famous Zen master. While the master quietly served tea, the professor talked about Zen. The master poured the visitor’s cup to the brim, and then kept pouring. The professor watched the overflowing cup until he could no longer restrain himself. “It’s overfull! No more will go in!” the professor blurted. “You are like this cup,” the master replied, “How can I show you Zen unless you first empty your cup.”

by Michael Badali

Simple is Hard

Simple? Sure! Easy? NO!!!

The first problem you will encounter with Kanban is the lack of proscription. If you or your team are used to being micromanaged you will experience some disorientation. Don’t panic, this is akin to withdrawal symptoms or a cleansing reaction. How to handled it? Every time you are about to do something, consider if there is any real value in it. Is it something you are doing out of habit or ignorance or is it something the customer would be happy to pay for?

If you are a leader and your people are used to being ordered what to do, you will need a coach to help them transition to self management and you will need to give firm clear leadership and truly support them by creating an environment in which it is ok to make mistakes and the value of continuous learning is clearly supported. In the end you are trying to create a continuous improvement culture that minimizes the need for management intervention / optimizes the teams ability to tackle problems and get on with the business of making money by delighting the customer.

Keep in mind that all your problems will become painfully visible and there is no where to hide.  You will need to prepare for this and focus not on blame but on practical solutions.

Kanban gives you visibility into your problems, it is up to you to solve them. 

by Michael Badali

3 Simple Rules

3 simple rules of Kanban
There seems to be infinite documentation on how to manage projects and programs and yet according to the Standish report only 32% of projects are successful. Thus the evolution of the Agile & Lean approach to software development, ITO, DevOps et al. People are looking for a better way to get things done. Extrapolating from intensive micromanagement through lighter and lighter project management approaches one arrives at the minimum viable process set. Sound scary? In a different way than you expect.
3 simple rules are all you need to get started. 3? just 3? Yes!
  1. Visualize the work flow 
  2. Limit work in progress 
  3. Measure and improve throughput 
That’s it? Yes. that is all you need to get started.
Kanban, simple eh? Must be easy…well that is another story…
by Michael Badali