Misconception about Complete Product

One of the most common misconception for people who have spent too many years in the traditional project environment is, they believe they must have a complete product to Go-Live at the end of the project. This belief has been a big major stumbling block in practicing the "Customer Collaboration over Contract Negotiation" value in Manifesto for Agile Software Development.

Instead of discovering and deciding on minimum viable product, so they could release it early and receive early feedback from user, they are aiming on a big bang approach to have the "complete product" before they are willing to launch it.

I have spent countless hours trying to educate some people on the perception of complete product, a complete product, just like best practices, will require no more enhancement. Over the years, I have been fortunate enough to come across some of the complete products as below:

Yes. The above list are some products that are complete. i.e. There will no more enhancement whatsoever add to them anymore!

You get what I mean, as long as a product are still in use, there will be modification or enhancement make to them. Hence those products can never be regarded as completed. The only products that can be considered completed are those obsolete products. So, are you still looking to have a complete product before you are willing to release them?

PRINCE II Agile??

Just finish watching this interesting video about PRINCE II Agile

It is interesting to see how people react to the rising of Agile Software Development methodology. In this video, it explain why PRINCE II by itself is complied to Agile Manifesto, though it conveniently forget to mention the 12 principles. The host also try to justify (by cherry picking some example from Scrum process framework and etc) on why PRINCE II has been Agile all the while.

What they are missing is, Agile is not about the process, it is about the mindset. You can definitely be Agile while using PRINCE II process framework, it is just that some process framework are more efficient and some introduce more waste. To be Agile, we would like to be more efficient by eliminating the waste.

The host pointed out the difference between Agile planning and PRINCE II planning, i.e. empirical planning in Agile and rational planning in PRINCE II. The host missed the point that the reason why Agile using empirical planning, is because they embrace the fact that changes is the only constant in life. Hence, investing heavily on detail planning upfront is very likely going to introduce a lot of waste.

The host also making commend such as the time-box duration can be longer, he was quoting example of 1 year duration. Here he missed out the point of the reason why shorter length time-box is being encouraged, it is to have early feedback. This is aim to eliminate the waste by having early confirmation on what is developed.

As a conclusion, I still think that PMI's approach to the "Agile Problem" is better. They had went through the stage of introducing iterative project management approach, to finally realize the incompatibility and introduce PMI-ACP.

How to be Agile?

I have came across a very interesting question lately, i.e. how to be Agile?

Well, if you are just looking at the surface meaning of Agile, it just means being flexible. Business would enjoy great benefit if they could have an IT team that allow them to respond to change.

However, if you look deeper into the Agile manifesto and principles, you will notice that it is very much related to Lean Principles. Which, the primary of Lean Principle is eliminating waste.

So, my typical answer to those question is, if you truly wanted to be Agile, you have to practice Zen thinking as individual and adopt Zen culture in your corporation. But why do I say so?

Practicing Zen allow you to grasp a better understanding of what is "Value", and value is at the center of the entire Agile spirit and methodology.

Let's look at the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

If you notice, being Agile means we really need to concentrate on the things that really matter. Not the noise which commonly overwhelm the attention.

Abby has some more points in his post regarding this thought which is similar in line.

http://hackerchick.com/agile-vs-lean-yeah-yeah-whats-the-difference/