This week’s post is a short one, since I’ve sadly not had the time to finish the next part of the firmware platform series in time.
People who know me also know that I’m a fan of agile development in general, but SCRUM and Kanban in particular. My “fandom” – if you wish – stems from the fact that I’ve seen both practices work, and work well. However, in my current position I’ve seen quite a lot of customers that think they’re doing agile, when all they are doing is waterfall with added “agile” overhead. In the end the developers are usually frustrated and think agile doesn’t work, management is frustrated and thinks agile doesn’t work. Which is true for their implementation.
The thing is: Getting agile right is terrifically hard. SCRUM needs a lot of buy in from management (on all levels), as they have to give up control. It also needs a robust set of supporting processes. Most agile proponents will know this, but it is really hard to get an organisation to adopt the practices required for any agile process to really work as lots of companies are deeply rooted in a strong hierarchical past that is hard to get rid of. I’d argue that – for these companies – switching to an agile process might often cause more harm than good. However, let’s take a step back an – just for a moment – forget the buzzwords, and think about a couple of practices, that make good project management in R&D contexts, where our knowdlegde of the problem domain might be incomplete:
- As stated we’ll usually not have enough knowledge to to completely plan our project. We will know some rough cornerstones at the beginning.
- As soon as we start chipping away at these cornerstones, we’ll start to build up knowledge and be able to make better estimates about our remaining work, i.e.: What needs to be done? How could things work? This knowledge boils down to new tasks for our project team.
- Newfound knowledge might also invalidate previous knowledge, thus requiring rework of certain aspects of our project.
- When we finish certain tasks we will usually sit down and think about, which tasks make sense to tackle next. We’ll usually also have a look at what we actually did and try to evaluate wether or not it is what we originally set out to do.
The agile fans among the crowd will proably have noticed, that the above list sounds suspicously agile, except that I tried to avoid any buzzword that is usually associated with agile. Why is that? Well, I’ve had the pleasure to work with a very experienced project manager a couple of years ago who told me a thing or two about project management, among other wisdom: What is nowadays dubbed as agile is actually not much more than common sense in project management and he had been applying these ideas since the late eighties (although he did note, that they did not have the fancy names back then), and the guy did work as high ranking project manager for a couple of big companies (Siemens among others).
Now, what am I actually trying to say?
Agile practices are not as newish as a lot of people seem to think, nor are they really special. They are a result of acknowledging the nature of projects as something that is rarely completely plannable. Also: The basic techniques used in agile development have been around for quite a while.
In the coming weeks I’ll publish a couple more non-technical articles, that will focus on Scrum and Kanban. These things have been discussed to death on the ‘net, but I do have the impression, that a lot of the people discussing about agile practices either have never worked in an environment with a good implementation of agile or suffer from the “In my days our wellies were made of wood” syndrome. The fact that we see relatively few working implementations of agile leads me to believe that a lot of people “don’t get it”, and seem to think that they can modify e.g. Scrum as they see fit. This is bound to fail – agile imposes few things mandatory, but the things it does impose are there for good reasons, and each of the instruments is necessary for the process to have a chance of succeeding.