RE:Lean software development using Kanban

Nice post. Before I write anything critical about it, I want to make clear that I think the Kanban approach is very interesting.

I have a few thoughts though, as I always do when considering agile versus "heavy" processes for software development.

First, there seems to be a bit of confusion regarding "heavy processes" and "waterfall models". Heavy processes do not necessarily imply a waterfall approach to development. I was working 20 years ago on heavy (really heavy mil-spec projects) which were employing iterative, incremental development models with frequent releases and continuous integration, nightly builds and test-driven-development, before so-called agile approaches became popular.

My second thought is around development speed and quality. The post makes a significant claim regarding the performance improvement achievable without sacrificing quality. I would love to see real stats on this across a broad spectrum of projects. It also depends upon how you define "quality", and what level of quality is acceptable. Most applications developed today for the public (especially mobile apps and web content) have very low quality requirements, as the implications of a "glitch" are not that severe. On the other hand, banking and online payment software have significantly higher quality needs. Moving on to military, medical device, and other software upon which lives depend, definable, demonstrable quality objectives are required.

Over the years (over 25 years now – man I feel old suddenly) I have led or been involved with software projects following a large number of different processes, from no identifiable process at all, to heavy mil-spec processes, to modern agile processes.

Each approach had its own value, even the "no process" model, and each had its weaknesses. The challenge I have with many proponents of agile processes is that they promote agile as inherently superior to heavy processes (of course, heavy-process oriented folks do much the same towards agile folks).

In my experience, no model works for all situations. Much like selecting a technology or a programming language, it is important to select the right approach for the right job, without being too enamoured with any one approach. While a mil-spec approach is not appropriate for a small team in a start-up, an agile methodology is equally inappropriate for a 10 year, multi-billion dollar, life-critical military project employing hundreds to thousands of developers.

Recently (well, in the last 10 years), I have become a big fan of what I term "just enough process" (which I talked about in a previous post). Always use the right tools and processes for the right job.

Must you be either 100% Microsoft or 100% NOT Microsoft?

I was reading this interesting post Coté’s Excellent Description of the Microsoft Web Rift « SmoothSpan Blog, as well as the post to which it refers. It is an interesting discussion of the fears many have with respect to choosing to work with Microsoft technologies versus non-Microsoft. The chain is worth a read, whether you agree with the ideas or not.

One statement I found particularly interesting was

This thing he calles “lock-in fear” and the extreme polarization (encouraged by Microsoft’s rhetoric, tactics, and track record) that you’re either all-Microsoft or no-Microsoft is my “web rift”.

While I would not disagree that Microsoft strongly encourages the use of its tools and technologies (after all, that is what most companies do, isn’t it?), I see far more rhetoric and tactical positioning on the part of non-Microsoft, anti-Microsoft, and Open Source communities insisting that one must be 100% non-Microsoft (and preferably not even play nice with anything Microsoft), or you are obviously a Microsoft fan boy.

I guess that the point that I am making is that a large part of the “lock-in fear” is created not by Microsoft’s behaviour, but by the behaviours of the anti-Microsoft crowd.

Fred’s Law #2: Requirements, we need lots of them!

As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.

Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:

  • You can create the illusion that you really know what you are doing
  • You look like you are being extremely diligent
  • You always look like you are extremely busy
  • You create huge amounts of documentation to support the illusion that you have been both busy and diligent

Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.

On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.

So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.

 

Share this post :

 

Fred’s Laws #1: Requirements, who needs ’em?

Well, I guess it is fitting to start out Fred’s Laws at the beginning of the process – with requirements.

If you really want to start of on the right foot, and get your project well on its way to a spectacular flame out, this is a fantastic place to start. Remember, the best way to figure out what your software needs to do, how it should do it, and what it should look like, is to get your coders right in there coding. After all, who knows what the user wants better than coders?

This is especially true if you are building something new and innovative, or if you are short on resources or time. Just think of all the time you will save by not having to talk to users up front. And, all those resources you would have wasted talking to users can be redirected to more important things like coding (whether they know how to code or not). Just imagine how far ahead of schedule you will be right from the beginning!

Now, estimation and scheduling may be a challenge without some definition of what you are building, but you probably will not be doing any real estimation or scheduling anyway (see later laws). If you need to have estimates and schedules to show to management, you can always make something up out of thin air (but make sure not to talk to your developers about it!).

(and just think how much time you will save talking to users later on, since you won’t have any!)

To be really specific, make sure you avoid any of the following activities, which are known risk factors which could lead to success:

  • Set up a system for capturing requirements, using Access, Excel, file cards, or any other tools
  • Establish a process to review and prioritize requirements, and assess their value versus cost
  • Define a process for managing changes to requirements
  • Involve users or user representatives in the creation and/or review of requirements

All in all, avoiding requirements definition should save a great deal of time up front, and allow you to focus on the important work of trying salvage your failing project.

Share this post :

 

Fred’s Laws (again)

Some time back (late September) I promised a series of posts on what I term “Fred’s Laws”, a set of rules you can follow if you are determined to have your software development project fail miserably.

Back in September, I promised I was going to post a law per day until I ran out of things to say. That lasted, well, zero days :-). For various reasons I felt it prudent to delay posting these for a couple of months.

The laws I am going to post are in no particular order in terms their impact. I am not sure how many of these laws there will be, and I am not even sure that they will not end up being self-contradictory.

(hey, I am doing this like a typical software project!)

I think the laws will fall into a few main categories:

  • Requirements
  • Project planning and tracking
  • Process, methodology, blah, blah, blah
  • Working with management
  • Working with marketing
  • Quality, testing, etc.
  • Technology and tools

Something to keep in mind here is that I am a big fan of process in software development. Not of big, heavy processes, but of some process. If you are going to go from A to B, you have to follow some process to get there. There is value in having some level of predictability and repeatability in that path. You may vary the path with the circumstances, but you should at least know what path you are improvising around.

Also, I do not believe that there are any rules which you can follow which will guarantee perfection in you software development efforts (at least not if you are building anything interesting). All of the rules, and process, and other magic spells can do is to improve your probability of success, and allow you to see when you are heading down the path of failure, allowing you to make some intelligent decisions along the way.

On the other hands, the are a few rules you can follow which can almost guarantee that your project will fail. Combine a few of them together, and you can make your failure truly spectacular. Stay tuned…

Five easy ways to fail?

Ok, so I just read Five easy ways to fail, which itself is just a quote from his article on Inc. Magazine. While I usually find Joel’s stuff intelligent, even when I do not agree with it, and I actually agree with much of the article, the piece quoted on his blog is one of the most mind-numbingly stupid statements I have ever heard outside of a political speech.

“Even though a bad team of developers tends to be the No. 1 cause of software project failures…”

I have never seen any statistics which support this statement. In 20+ years, I have never been part of a project (either as a member or as an observer) which would support this statement. I have been involved in projects where stellar teams overcame bad management, bad scheduling and many other common obstacles, but never have I seen a well-managed, well-thought-out project fail because the programmers just were not smart enough. I would challenge Joel to provide any evidence to support this.

Then again, I have never seen anyone stupid enough to have hired an entire team of stupid people, and then been stupid enough to keep them. If this is the case, you have a much more serious problem than dumb programmers.

Also, while it would be nice to have the luxury of hiring only exactly the developers who fit your profile, that is a luxury most of us do not have (see my previous post on hiring). The reality is that you are almost always going to have a distribution of talents on your team – you are going to have stars, you are going to have duds, and you are going to have everything in between. I am always guided by an article I read in Harvard Business Review many years ago, where the late Bill Walsh talked about building great teams. The basic idea was that in any team of ten people, you are typically going have 2 people who are so good, they are going to over-achieve no matter what you do. You will also likely have 2 people who will under-achieve no matter what. The six in the middle may under-achieve or over-achieve, depending upon how they are led. And the deciding factor as to whether you have a stellar team, or a failing team, depends upon how those six in the middle are guided/managed/coached/led.

To say that most projects fail because the team is not competent is not statistically supported, is overly general in the extreme, and smacks of the kind of statement bad managers make to cover the fact that they are bad managers.