PMI vs. Agile, what is different, and why should we care

The PMI people don't seem to stop trying to "guess" what Agile is. Guessing is the right term, because anyone with more than a few hours experience in Agile software development can see their cluelessness from afar!

Take this article by Lynda Bourne DMP, PMP (no, I'm not making those TLA's up, she uses them). She says that Agile is different from waterfall because:

• The need for robust change management and configuration management to track the evolution of the Agile project
  
• The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Someone that says that in Agile project management you need "robust change management and configuration management" probably does not even understand what those are, let alone Agile. Hear me out: Change Management is not needed in Agile, Agile *IS* change management. Take Scrum for example, the whole idea with Scrum is to provide a framework for accepting and managing changes. Scrum *IS* change management. To say that Agile project management "needs" strong change management is to miss one of the most elementary points of Agile Software Development.

Then comes the killer: we Agile project managers (supposedly) need to focus on "developing the correct strategy and architecture at the beginning of the Agile project", missing this - Lynda writes - will lead to failure. Only one word: WTF? C'mon Lynda, that is probably the largest mis-conception of Agile Project Management that I've seen in my (admittedly) short life!

There are thousands of posts about why Agile people focus on "growing" architectures rather than "getting them right up-front" (aka BDUF). Please read up, just google for Agile Architecture and you will find many articles that explain how in Agile we look at Architecture development (here's an example link).

There seems to be a lot of discussion happening in the PMI circles about Agile, but PMI people need to understand that the practices they've developed for building, acquiring companies, etc. don't all apply to software. PMI people should first learn about software and then Agile. Trying to bypass software and going straight for an Agile take-over will only get us (the software industry) another 10-years back in time and lose so much of the evolution we gained with the Agile movement.

Apple on unfair claims in advertising

Part of being a cool company is that you respect your customers. This is not a show of respect by Apple. Seriously, this is just used car salesman tactics. Apple, shape up!

The cost of un-fixed bugs or Good Code on top of Bad Code

While discussing with a colleague we started talking about the costs related to not fixing a bug immediately (yes, this does mean that you have a way to immediately figure out if you introduced a bug).

The reason for fixing bugs immediately is not only the cost of content switching later on when you have to come back, but it is even more the cumulative cost of fixing all the code you have built on top of the bug you introduced.

Think about it this way. Bug = Bad code. If you have a bug and continue development you are developing working code (good code) on top of that bug (bad code).

When you later on go back to fix the bad code, you will then have to fix all of the good code that is now broken because of the bug fix you introduced.

Software is build in stacks, the lower level affects directly the upper levels (many of them), if you have a bug lower in the stack and then fix it you will have to change all of the upper levels! And that is where the real cost is.

So, if you find a bug, fix it now. If you did not find a bug, think of ways you could find it faster -- before you build good code on top of bad code.

Separation of design and requirements may have destroyed more software projects than waterfall...

The people that convinced us to never mix design with requirements may have wrecked more software projects and destroyed more value in the software industry than anyone else!

Just think what happens when you separate requirements from design:

1. You don't validate assumptions to more than a very superficial level (the "I don't care about the technology, just give me the business needs"-level)
   
2. You never evaluate the system's constraints and how those may make the system possible or not (hardware, technology, etc.)
3. You never think of how testable the system will be (as in "is it possible to ever prove that this requirement is implemented?")
   
4. You don't write down the tests that will prove that the system works (until it is too late and you have to hire a gazillion testers to test the whole system using a script that was developed by people that never really participated in developing/defining the requirements)
   
5. You never visualize how the system will be used by real users
6. You probably - I'm being generous here - did not involve the testers/coders/designers in the requirements definition
7. You spend way too much time disconnected from the reality of your business. Remember that our business is software development (as in coding/testing and getting feedback from real users) not requirements management (even though some tool-vendors will make you believe otherwise).
   

Now, having been in the software industry for more than I care to admit I know why we had requirements documents back in the old days. The short story is: we did not know better, the long story is way too long to tell in one blog post and involves some famous academic people and a junior process guy called Winston Royce.

During those requirement writing sessions we tried our best to stay away from the design discussions because we knew that if we did go into design (which we wanted and felt we should do) the requirements would never be ready. So we decided to do the wrong thing because we knew there was no way we would ever get the requirements written and the Requirements Gate passed if we did not do it.

Now that I look back I find it amazing that we ever got the requirements right! Think about it, if you don't validate the assumptions you make but to a superficial level you are saying to yourself "I know that there's no way I can prove that I'm writing the right requirements for my system to succeed". How's that for a smart way to do software development? But that's how we got taught in University (still are today to a great extent), and that's what our process trainers brainwash us to believe in.

This separation of Requirements and Design is, in my view, the single biggest reason for software projects to fail, and it is still happening today!

Define the most important requirements first, then worry about the rest

This is why it is so important to delay writing the low-priority (as in "the ones you are not sure you need") requirements until the last responsible moment (aka "delay commitment"). You should take an appropriate set of requirements that fit in one iteration (using the highest-risk, highest-value heuristic) and develop those. Get a slice of the system working, don't get caught in the useless (and never ending) discussions that do not relate to the requirements being implemented (note that these requirements can be non-functionals also, e.g. performance or security).

Once you have a set of requirements implemented you have validated (or disproved) the most important assumptions about your system because those are the ones that relate to the highest-risk items of your requirements list.

Since you have avoided to think about all the requirements you have not either lost any time discussing requirements that make no sense to implement and therefore should have little (or no) importance when making the major decisions for the system, like architecture, technology, etc.

Another important thing to consider is that when you think about design, you are in effect creating feedback to the requirements cycle. If you separate requirements from design you are also removing all possibility of having early (and needed) feedback to your requirements writing!

If there are some times when I think I did stupid things in the past this is one. Boy, we were dumb back then! (and may are still today...)

Blogged with the Flock Browser

Adaptive Path discovers Apple's Mojo, but Toyota got there first

In a post called "Apple’s Design Process Through a Keyhole", the blog over at Adaptive Path mentions one technique used at Apple when designing product. The basic idea is that in Apple, designers come up with 10 possible designs for a new feature (and I bet more than 10 for a new product). Then diligently choose the best 3 and then continue to iteratively improve all 3 options they chose for some set period of time. Once they have worked for a while in all 3 options they finally decide on 1 and perfect it.

Even though this seems to be "amazing" and "innovative" for the folk at Adaptive Path (and I bet they are not the only ones thinking that way), this is actually a very old technique called Set-Based Concurrent Engineering (SBCE, also in software).

This technique is similar to techniques used in brainstorming sessions where participants are encouraged to generate many ideas (broaden the horizon), improve on them incrementally by "using" other people's ideas and enhancing them (improve on other's ideas), and finally to select the most appropriate idea for implementation (narrow and select).

Set-Based Concurrent Engineering is also used to ensure quality when a team (or set of teams) must meet a hard-deadline (as in a deadline that cannot be changed) with a solution that is much better than if you would just go with your first impulse/idea and try to improve on that.

One of the key advantages for Apple in using this technique, is that when they get to the 3 mid-step ideas they actually have syntethized all of the best points of all the other 7 ideas into those select 3. And then they still improve on those!

Good to see that Adaptive Path picked up on this technique, I hope that many other UI/UX people start paying attention to this old, but proven technique!

Nokia is missing the bus, why the N96 is not good enough

Disruptive technologies don't always come with revolutionary new technology or feature-packed packages. And this is no different with the iPhone/Nokia debate going on today after Nokia failed to impress with the announcement of the N96 multimedia phone.

The fact is that Nokia is missing the bigger point and the proverbial bus. One year after the launch of the iPhone, Nokia should be following on the heals of Apple and presenting a credible alternative to the second largest selling smartphone in the US market as of Q4/2007. But no, they just packed another set of features (already hard to use or even find in the older models) into another phone that could be said to be "more of the same".

With this play, Nokia is missing the point illustrated by the Hard Drive business in the 1980's. It is not "more of the same" that will change the market and gain market share. It is innovation! Not technological innovation, but useful innovation.

As Christensen put is in "The Innovator's Dilemma":

Generally disruptive innovations were technologically straightforward, consisting of off-the-shelf components put together in a product architecture that was often simpler than prior approaches. They offered less of what customers in established markets wanted and so could rarely be initially employed there. They offered a different package of attributes valued only in emerging markets remote from, and unimportant to, the mainstream.

What's most amazing is that there's already an S60 "touch" which is the operating system that Nokia uses in their smartphones.

Today, if you want a decent Internet phone from Nokia you have little choice: the bulky Communicator/E90, the "Blackberry Killer" E61i/E62 or the ugly E70. None of these phones comes close to the elegance, size efficiency or usability of the iPhone, and none of them competes with the iPhone in the "player" market for iPhones (music/video/etc.).

I wonder when Nokia will wake up... Probably not too soon judging by the time it took them to release their "Blackberry killer": 7 years!!!!!