August 20, 2012 Focus area: Scaling Agile

Agile for Business Owners

IT is underperforming. It is not living up to the promise. Regardless of who's fault it was, or who wants to blame who, the ultimate end result: IT needs to be faster, simpler, better, more responsive, fit for use. Nothing new there, right?

And now instead of just fixing that problem, IT comes up with yet another fashion. Agile. Bweeeeegh. Boring. As a business, you see, you are not interested in Agile, IT, and all these supporting things. You want products sold. For that you need them to do a job. Right? Right.

So let's not talk about Agile. Lets just stick with some facts and your needs. For a product to be sold, you more often than not, require some IT. Sometimes a lot, sometimes a little. This IT is something you don't want to know too much about, it is all technical expertise, and like if you had a construction company build you a house, you shouldn't have to know how to do the construction work.

The question of course is, how to best organize this in a way that does not ask too much of you, and retain the desired flexibility you need during the construction. In construction, whether it is software or a house, decisions are made based on the architecture, design principles and your desires and wishes. The problem in IT projects, as opposed to House construction, is that a lot of what you need will only become clearer later in the project..

This means that on the one hand you want to 'just'; say: "this is what I need, just build the freakin' system', and on the other hand you want to influence during the building process with things like: 'yes I know I said I wanted it like that, but you understood me wrong, and something changed', without having a fearsome change management procedure in your way to prevent you from changing to something better fitting your need.

Although this sounds like an impossible puzzle, The funny thing is, the answer is actually quite straightforward. First of all, you need to not clarify WHAT you need, that's way too much work. You definitely do not want to explain HOW you want it, that'll be even worse. What you want to explain very well is WHY you need it. As soon as any delivery team, no matter if it is a IT related team or production or whatever, knows WHY you have asked them to do something, something funny happens. They will take more decisions themselves, and commit stronger to doing the right thing to fulfill your WHY.

Now, of course, they might go wrong. It is like we should trust a team to just build for half a year, and then we see what they created, that would be very risky. For control reasons, it makes sense to have te team show their actual work done (an incremental product version) so that you can bash or compliment them on their work and understanding. Doing that often will lead to better understanding and less risk of the whole thing going astray.

Further down the line, there will be unexpected things happening in there. That's why it was defined as a project in the first place. So when things turn out to be slower, harder, etc, it would be very convenient if we at least all the time have access to the most important parts of what we need, defined by the incremental value of the fulfillment of the WHY.

So a final step for any business that wants to be Agile, is to take ownership of the priorities. Prioritize the small steps teams are taking, just ahead of every iteration they are going to do. That way, you spend minimum time on just enough prioritization for maximum value output.

In short, as business, if doing anything with IT, you should do a very shortcycled control cycle, so that the risks are managed neatly, and make sure you prioritize these cycles so that you'll get maximum value no matter how good or bad the team performs. And yes, one could use Scrum to do this. It is simple enough to implement this cycle.

As business, don't let IT fool you. Scrum and Agile are sometimes perceived as a way for teams not to commit to anything, or so that they can have flexible scope. If you don't take your role, they might even get away with that. Scrum and Agile thinking is a business thing, invented by business. IT just stole it and gave it a name.