Category Archives: Agile

Would you build a house using agile methods?

Well would you? I don’t think most people would, and it would be really interesting to see how the agile houses would look. We’d work in iterations, so I’ll probably start with the smallest deliverable object, a tarpaulin across some trees and build from there. Need another bathroom? Just add a few more walls, knock a hole in the wall and raise four walls and put the tub down. Feeling cramped? Tack on another floor. After each week the builders could sit down and talk about how to alter the building standards based on the mistakes of last week and provide a new set of building standards.

Does this sound ludicrous to you? Of course it does. But why?

Because houses aren’t software. And the environment they work in is not agile, and it never will be. You submit your plan and get planning permission, which can’t be changed without considerable effort and cost. You can’t change the standards on how to build exterior walls halfway through a project, or decide that you’d like more rooms after the foundation is done. It won’t fly. Pictured is the bent pyramid of Dahshur, in which the builders realized that the angle of the pyramid wouldn’t work halfway up the top. So they, predating the agile movement by some 4600 years, changed the design and rolled with the punches. I bet the pharaoh wasn’t too pleased about the end result though.

A hegemony of scrum

About two years ago I was at Öredev , which is the largest developer-centric conference in my region. Someone had the brilliant idea of putting a large note on the door to the mens bathrooms proudly proclaiming them to be site of the “waterfall classes”. Such is the state of the software industry in here that the venerable old waterfall model is more ridiculed than respected as a real technique. And yet if you were building a house, I’d wager you would use the waterfall model to build it, and you’d use the agile methods to build anything made out of software.

But really, are all software software? Are, in fact, some software more like houses? And are we really doing ourselves a favour by applying an agile method to something that isn’t suited for agile development.

Consider writing a software application for a washing machine. Is it more like a fast moving web development scenario, or is it more like building a house. You’ll never be able to change the software after your product has shipped. If you have bugs in your software the costs could be astronomical (think water leaks, electrical fires whatnot).

I’m not saying that there aren’t things in agile that our prospective washing-machine-software developer can take home with him, but I’d wager that even if he chooses an agile method for the daily tasks, it will be strengthened with the inclusion of a waterfall-like model on top. And that’s not a bad thing.

How much of a house is your software

I believe that this has to do with the cost of change after shipment, and the agile adoption of the rest of organization. If the cost of change is very high, or the cost of running your agile process within an organization that simply refuses to conform to an agile model then you’re probably better off doing a different kind of software development methodology. Preferably one of your own design.

Scrum is a very strange beast, since it is one teams evolved plan that worked for them that has been codified and subsequently adopted by people across the software development world. Sometimes it works, often it doesn’t – or at least it doesn’t get fully adopted. If you’re in any way think that the software you’re building or the organization you’re building it in has some characteristics of a housing business scrum as it stands probably will never work out the way the evangelists say it will.

Roll your own

I’ve a feeling that when the case for scrum isn’t clear cut, we often go about process change the wrong way. And by wrong way, I mean by bringing in agile consultants that are supposed to implement a codified scrum. They constantly tell us that we are supposed to modify things as we go along while at the same time telling us how it really should be done. Why not just evolve things on your own?

The only thing you really need is the current baseline, i.e. what you have going right now – even if that is nothing at all, and a whiteboard. Take one thing from scrum, the retrospective and sit down. Rank all the crappy things in your working environment and address the worst one. Don’t even bother with anything else. It’ll take a while, but you’d find the best way of doing things given your situation and your software.

How are your thoughts on this, are you also experiencing a move towards just taking a boxed implementation of what has worked for someone else instead of actually doing the pretty easy task of finding out what would be the actual best method for your organization?

Implementing scrum and missing the mark

I have been working with different varieties of scrum for about 6 years now, and I’m not sure that we are focusing on the right things. What are we trying to solve, and who are we trying to preach this new agile gospel to?

A hierarchy of (developer) needs

Like the famous Maslow’s hierarchy of needs, I think that we are looking at much the same thing when it comes to making a working environment for a development team. I believe that this goes pretty much like this:

  1. What am I supposed to be doing?
  2. How am I supposed to do it?
  3. What’s everyone else doing?
  4. How can we get better at doing it?

First and foremost, you want to know what you’re supposed to be doing. As a developer you’ll need some sort of plan, or at least a clear idea of what is the end result.

Secondly, once you actually know what is to be done, you’ll need to know how you are supposed to do it. What are the requirements of the task?

Once you know those things, you can work reasonably efficient, which would give you enough time to help your co-workers out and begin to act as a team, which forms the need to know what they are doing.

Which leads to the final step of wanting to get better at the actual process of doing things.

How scrum is typically implemented

When trying to implement scrum in an organization it’s almost always implemented in the completely opposite direction.

First to be implemented is the daily scrum, because it is easy. Not because people really need it, but because it’s an easy thing to do and programmers need to stand up more in the morning. Secondly, you get to the retrospective. Most teams never get further than this due to organizational intertia or lack of interest.

In my opinion, this is doing it all wrong.

The product owner is the key

The product owner is the key to the entire idea of scrum. Without a proper product owner, you are never going to get things working properly. Look, daily standups and fuzzy retrospectives are nice and all but if the backlog isn’t prioritized you’re going to end up with headless chickens in the development team who does not know what they are going to do next week.

A product owner is not a project manager. And he is absolutely not a developer. And, no, he can’t double as the scrum master. Seriously. And he has about one thing to do, and that is to make sure that there are issues to do each iteration and that they are planned way ahead.

A strong product owner is the buffer between the scrum bubble and the rest of the organization, much like the scrum master is the buffer between the individual developer and the product owner. And yet people keep completely missing the point of the role.

I’m thinking that this is because it’s the most innovative concept that scrum introduces. Most people can imagine the scrum developer with the daily standups and once-per-iteration retrospectives. But the product owner is a new entity, an administrative one that usually doesn’t exist within an organization. So they usually skip it altogether, or completely misrepresents the role by thinking about it as pretty much a renamed project manager.

Barking up the wrong tree

So, why is it that we have Agile conferences filled with people whose primary job is to write code? Why is it that we see the daily standup as the prime vehicle of scrum, where in fact it is a luxury item that only comes into play once you actually know what you are supposed to be doing the next few weeks?

The most common complaint I hear is this:

We the developers try to do scrum, we have our iterations but we still have old-school project managers that doesn’t jive with the methodology. So we only do standups and retrospectives.

Then why bother? If the organization can’t embrace scrum by including one of it’s holy trinity, the scrum master and development team being the other two, why are you trying to fit square pegs in round holes?

If there is one thing I’d like to force into people’s mind it’s this:

You cannot do scrum without a prioritized backlog and a product owner. Everything else does not really matter if you do not have this.

How are your ideas regarding this symbiosis? Do you feel you can really do scrum half-ass and be happy with it? If the rest of the organization is that unwilling to the concept that you can only do it inside of your own little development team with your programming buddies, perhaps it’s time to evolve another system of your own that can actually fit within your organization instead of trying to do everything the opposite way while still maintaining an interface outwards that an old-school organization. I’d love to hear your thoughts.

Tagged , ,