Agile in a non-agile environment
A couple of weeks ago, a friend of mine asked me to talk to his sister. This sister has her own company teaching Project Management (sorry, gross generalisation but bear with me). She mostly specialises in non-IT projects using information from Prince2, Lean and other platforms.
A lot of the time, though, there are IT components in the projects and programs running in the companies she works for. And lately that means she meets Agile practices on her way. She wanted to know more about Agile in general and so we sat down for a talk.
As some of you may know, my main life goal is Agile World Domination. Any time I can talk to any professional about Agile and what it can do for them, I take that opportunity to further my ominous life goal. The original intent was to see what we can do for each other. We talked about my work, her work, where those two touch and what we can add to each others understanding of the world. At one point she said “The biggest issue I face is with companies that use classic Portfolio Management. How does Agile fit there?”
My first answer was; It doesn’t. In the Agile world we recognize that forecasting is waste and so we only make low-level roadmaps. We don’t have project budgets, we simply state: Trust that the money spent will be spent on those things that have the highest value. At any point you can say “That’s all the money we have” and trim the tail. Or you can say “Any further investment will not have a high enough ROI so let’s change the focus”. Well; reality is that some companies are simply not ready for that way of thinking yet. And yet, as a Project Manager, you’ll still want to be able to use Agile in those companies as well. But the Portfolio Manager won’t let you do your project unless you give a detailed forecast and budget. So how to we handle that?
As Scrum consists of, so called, Organizational Patterns to govern the details of the way of working, so does ANY organisation consist of Organisational Patterns. Implementing those patterns piecemeal is still possible. Even more important; implementing the right patterns at the right moment means gaining the advantage of the pattern without going too strongly against the rules and processes in place in the company.
Of course you shouldn’t believe me on my word (or on my blue eyes, as we say in the Netherlands). Let me tell you a story of one such experience I’ve had.
One of the projects I’ve worked on in the past was for a strongly hierarchical and political company. I was hired by a holding company that was part of a larger organisation and had a number of subsidiary companies. The result was that the larger organisation demanded detailed book keeping whilst the subsidiaries (the only ones actually having money; the holding was financed from the subsidiaries) had a strong political influence (“If you don’t do as we say, we’ll cut your budget” type). They asked me to set up a systems communication platform to enable the central applications to communicate to the local applications in a canonical data format (let’s call it an Enterprise Service Bus or ESB).
So, as one does when project managing, I had an analyst draw up a set of requirements. But instead of having the analyst make an hour estimate and putting that into a project plan, I then set up a development team and had a preliminary meeting to do the estimates on a very high level. What we did is simply take the list of requirements, and ask them: If we need to divide this into blocks of equal size, what blocks would we then see? The end result was 4 blocks (platform, preliminary data model setup, POC1 and POC2). Then we asked; how much time would you all need for each block? The team said: 2 weeks per block for the entire team. And the last question: What’s your certainty level? Basically, they said, the maximum is another block of 2 weeks or 4 blocks but drop POC2.
I used this information to set up a document for The Powers That Be. Please give me enough money to have this team work either for 10 weeks with the certainty of the entire list or for 8 weeks with a variable scope on the second proof of concept. Added the time necessary to set up the contracts and hand over to the support team and presented that to the steering committee.
At first they said “Impossible. We need a commitment on everything for 8 weeks.” To which I replied “Nope, not gonna happen. This is the commitment the team can give. You must choose.” The problem with this part is that we all keep telling ourselves that we did well in the past. And so our view on past experiences is skewed. We will always say “We did this in the past and it always worked!” even though it failed more often than not. And so when they said “We did it in the past! We can do it now!” I only asked them to show me the original plans of projects that actually finished in time, in scope and on budget. They couldn’t. And so they agreed to do the 8 weeks with possibly dropping POC2 (I always recommend this since you can always extend time if necessary. Reducing scope afterwards to finish faster is slightly harder).
In the end we finished everything in 8 weeks time and due to a holiday still had some budget left. (Which, in an organisation like this, generally isn’t a good thing. There’s political consequences to having budget left but that’s a topic for a different time. Heck; a different person).
This project benefitted from an Agile approach to software development without being hindered (too much) by the “old world” Portfolio Management involved. We were able to deliver all the paperwork the Portfolio Management organisation demanded without influencing the Agile development approach too much. Yes, there was “waste” in the analysis part of the project but if such is necessary to be able to do the project at all, can you really call it waste? I guess the definition of waste is situational ;)