AGILE is Mythology, not Manifesto

Agile. Prince 2. Waterfall. Scrum. Sprint. KPIs. PRLs. FRDs. POCs. Huddles….. Dear God. Sometimes I hanker for the old days, when managing (and participating) in various work related projects was largely a matter of common sense and hard work, and not remembering a dictionary-full of buzzwords and acronyms and holding daily meetings to discuss identical things.

Back then, in the days of my youth – the 80s and 90s mainly – , when I got involved in a project at work it was because my partners or managers wanted me to do something very specific. They gave me a clear set of instructions, told me by when they needed to be completed and why and made it clear that my career may be damaged if I didn’t do it successfully, then showed me their office door and told me to get on with it. So I did. I don’t remember any failures on my part, and generally speaking the piece of work I guess formed a small component of a much bigger project of which I was (usually) blissfully unaware. It was never anything special, merely another bit of work to do in a typically already full day. But I got on with it in the hope (sometimes unfulfilled) that come review time I would be looked after financially and perhaps even get a little leg up the career ladder. I usually learned something new too, and still call on a lot of that knowledge now, thirty and forty years later in my daily travails. I’ve probably forgotten a lot of stuff too, but that’s life and ageing, I guess.

By the mid-90s, I had attained a level where I was more involved in project work and less in the day-to-day nuts and bolts of my particular banking segment. I had people reporting to me who did that, and I approved, kicked out, praised or chastised them as needed, while thinking more about how my bank’s business was growing, what new activities were being considered and how we could support them. I wasn’t a decision maker, not by any stretch of the imagination, but at least I found myself consulted by those who were. I would always discuss these questions with my more senior people, and report back up the ladder and wait for the fallout. Often nothing happened, but then sometimes changes would filter back down and I would have to pass them along to sometimes reluctant staff. But that is management, right? And still the “big picture” often eluded me, and still my reward (or lack thereof) depended on my annual review and a whole raft of other factors. I, like my team, just got on with it.

Then my bank decided that its existing IT infrastructure was hopelessly outdated and not capable of supporting efficiently its existing business, never mind the ambitious plans to expand that were being hatched by the board in Frankfurt. So a big project to replace everything kicked off, with an ambitious 18 month completion target. For the first time I was a Decision Maker, charged with choosing which system I wanted to support my segment and then installing it. There was a group of us doing the same thing – the idea of getting one piece of kit to support the lot was the ideal but despite reviewing a vast list of potential systems there wasn’t one, at least at that time, that could tick all the boxes – ably assisted by a team of young and enthusiastic Andersen Consulting analysts drawn from all across Europe, flown in and housed in central London at no doubt extortionate cost (payable by the bank, of course).

They took care of all the planning while we focused on our choices and, once made, plugging the system in. They also worked with our (small) in-house IT team and the vendors to build all the interfaces that were needed, both between systems and with the outside world, and assisted us users in our conversations with the vendors and in resolving the raft of problems that invariably cropped up. We meanwhile got in at 7:30 or 8 in the morning, did our normal day’s work until maybe 5:30 or 6, then did another three or 4 hours project work. It was bloody hard work, but given the size of the bank there was no other way to do it – we couldn’t spare the people to form a dedicated project team, and the budget wasn’t big enough to bring in a bunch of temporary workers either to do the day job or work on the system implementation. The specialist IT contractor market in those days was still quite young and mainly technical-oriented, so didn’t provide a viable solution.We didn’t have time for daily meetings (we barely managed to fit in a weekly round-table progress discussion) and relied on the Andersen guys to keep us all focused and on-track, our own stamina and common sense to keep it that way, and the support and efforts of the various vendors to do the development work.And we succeeded. On time (but probably over-budget), after a go live weekend where I got to the office at 7:00 on the Friday morning and left at 8 Sunday evening and about 3 hours sleep. I got home, drank a couple of cans of beer and ate a sandwich then fell asleep in the armchair for a few hours, before heading back into work at 8 the next morning, fingers crossed that everything was still working ok. It was – and in fact worked so well that we dropped the parallel run and de-commissioned the legacy system after 2 weeks rather than the scheduled month. In that time there had been three problems and they were all down to human error not system malfunction. Then we all went to a pub in Liverpool Street and got completely hammered. It was my first project of any significant size, and despite the grind over a period of months, it was a roaring success. And there was not a scrum or a sprint in sight.

Come the Millennium, I waved goodbye to banking per sé, and crossed into the IT landscape, working for a vendor who now offered the kind of all-in system that we had desperately tried to find in my German project. I needed a change: after 30-odd years arguing with know-all traders and rich-kid salesmen for a relative pittance, suffering redundancies and unfair dismissals along the way, I was tired of it all and wanted out. I wasn’t sure what I really wanted to do but knew I had to put my accumulated business knowledge to use, and initially stumbled into a start-up company trying to do something different and exciting. It was one big project really, working with a selection of well-known vendors, service suppliers and software houses and involved a lot of creative thinking and travel. Alas, the venture failed on the very brink of success and potential Wealth Beyond My Wildest Dreams (and my dreams can be pretty wild….), but not before I came to love the type of work involved.

From there, I managed to quite quickly find the job with my vendor, and began working my way around the world and through my passport (I’m on my third since then). It’s all been project work – each bank is a different challenge, even if the questions and problems are frequently the same – and I’ve found over the years that my banking experience and admittedly previously light project experience has been a big help.

In most places, the projects had been fairly tight and structured, so that we had set goals (both financial and deliverable) to meet, and by the time I had wandered into the building in some far flung location all the planning and governance had been put in place. To that extent, it was very much like my bank projects, in that I would be given a specific task to perform, a time to do it in, and a list of people I would need to meet to complete. Then typically, the project manager would let me get on with it, with minimum interference.Now it may well be that the project manager was indeed following Prince 2 or whatever, but to those of us at the sharp end, doing the work, collecting requirements, solving the problems and educating the end-users, that was often completely unclear. Sure, we would usually get to see the overall MS Project Plan (or at least the bits relevant to our specific tasks), and have a weekly meeting just to keep track of where we all were in relation to it, and of course we always had the option of asking for additional time if needed, but it was still relatively free. At least, that’s how that particular vendor operates (still) and it seems to work – it has been a market leader by various measures throughout the years of our association and shows little appetite to change and little sign of slowing down.

It was also noticeable that the more structure was imposed, and the higher the involvement of outside partners (like our friends at Andersen) to “manage” some aspects of the project, the harder it was to succeed, the longer the project took, and the less enjoyable it was. It was also the bigger projects that suffered in this way.Big projects have a tendency to over-plan. A perfect example was one I worked on maybe 15 years ago in Geneva. It was a big German bank, a flagship project for both the bank and ourselves, with a huge budget and matching expectations across the board. The bank created a dedicated project team from internal resources numbering maybe 150 people, and there was also a small army of consultants from a major international business consultancy firm who were responsible for planning (of course) and facilitating workshops. We were expected to match the bank project team man for man, which created an immediate problem as we had nowhere near 150 bodies available. But we got around that somehow by doubling or tripling up on the number of bank people we supported. At one point we fell a little behind The Planned Timeline, and the bank immediately shipped in another 80 bodies and expected us to do likewise (I think we found three new heads).

But the Project Plan! I have never seen anything like it. The partner consultancy created it using (of course) MS Project, and it ran to something in excess of 40,000 lines (no, that isn’t a typo). There was a detailed plan for each team member, and tasks were scheduled down to the minute. This led to the following exchange:

Planner: This task at line 2,383 should have taken you 40 minutes, but I see you took 50. Why was that? Me: Well, I had to take a dump – dodgy curry last night. And by the way, I’m working now on line 3,862 which is supposed to take 15 minutes and you have just completely wasted 2 of them. Now bugger off.

I left the project about three weeks later, and it limped on for another three or four years, before collapsing in a welter of accusations and counter-accusations. I could mention similar cases, and also highlight others where a small team of perhaps 10 individuals from vendor and bank (and no partner organizations) were able to complete early and within budget – without a monstrous project plan at all. Anyway, I remained blissfully unaware of Agile and Scrum and all this other stuff, because to the best of my knowledge not a single project out of the 50 or so I worked on over the years used any of it (apart from probably my over-planned Swiss-Germans). And I had more successful go-lives than failures.

Then I moved on again in 2013. I started my own company (just me as a sole trader) but seeking to work on the same kinds of projects supporting the same vendor, plus anything else I could manage to pick up elsewhere along the way. As a result I had some discussions with a guy in the UAE, about a short term analysis in the region, that he advised me would “follow BABoK and Agile – are you ok with that?” Of course, says I, trying to keep the ignorance from my tone. We agreed my terms and he went off to pitch to the potential client while I attacked Wikipedia. In the event, the project never materialised on cost grounds, but I spent an entertaining week or so downloading and reading all I could find on the two mysterious methodologies (that’s when the material didn’t send me to sleep).

By and by I got some project work, at small banks through an old contact of mine, working with the same old vendor in the same old way, and both BABoK and Agile (to mention nothing of Scrums, Sprints and Huddles) receded from my consciousness. At least, from its forefront.

By 2015, I moved to a long termer, at a bank that swore Agile was the best thing since sliced bread, and ran all its projects, big and small, using the methodology, but I was still not sure how Agile is supposed to work, and as far as I knew had not used it at work. As far as I could make out, it involved working in small teams that comprise the BAs, the techies, the vendors (maybe) and the users, and it parceled out the work to be done in bite-sized chunks. In this way there is supposed to be a constant stream of small incremental code changes delivered that ultimately comprised the deliverable (i.e. the new system). There needed to be regular meetings (Scrums?) to plan the work, daily meetings (Huddles??) to discuss progress: what was done yesterday, what is being done today and what will be done tomorrow to meet the deliverable. These appeared to be planned and controlled by someone called a Scrum Master, who was not so much a project manager as a meeting facilitator come secretary (but I may have been wrong on that count – it was mostly guesswork). If there were delays then the team would embark on a shortened delivery cycle (a Sprint???) to make up for lost time and get back on track.

This sounded all well and good, and I was sure it worked because it seemed to be an increasingly popular way of running IT projects these days. But it seemed to me that for the methodology to work properly, the team needs to be small, located in close proximity (preferably the same room or at least location (floor) in the building), and be 100% assigned to the project. So how does it work on a big project, where the client BAs are in one room, the vendor BAs in another building, the end users assigned only for part of the time and scattered across locations throughout the city, country, continent or world, and the vendor’s coders located in a faceless building half a world away and locked into their company’s own delivery priorities (that cover many other clients), I wondered? I couldn’t see any way an effective Scrum or (in particular) Sprint could be carried out under those circumstances – even with today’s multi-media technology, video conferencing, webex’s and so forth.

So the first year or so I beavered away doing bits of work as assigned, and trying to figure out these concerns myself. I asked a few bank old timers, without trying to sound like a complete moron, but no-one was able answer the questions. I came to the conclusion most of them were in the same boat and the project was in danger of sinking with all hands. Then we were all scheduled to an “Introduction to Agile training course” – it lasted one day and was delivered by a young lady, a rising star in the bank, who was a Scrum Master. We were all asked at the outset what we wanted to achieve over the day, and I raised my specific concerns about fragmented teams on a big project (since they matched exactly what was happening on our major multi-national project) and said that I wanted them answered for me to consider the course valuable. She smiled and assured me they would be. But they weren’t. I was no more knowledgeable about Agile at the end of the day than I had been at the beginning, beyond seeing that my basic ideas about the terminology had at least been reasonably accurate. But as to the specific questions? Not a word.

Nothing in the Agile methodology, it seems to me, can properly replace a good and experienced project manager. All the buzzwords and acronyms in the world will never replace the guy who can organise and plan a work schedule properly, assign it to the correct resources, and then trust and motivate them to do the job to the best of their abilities, come hell or high water.

Maybe I really am getting old, certainly I am old fashioned, but all these meetings – whether you call them Sprints or Scrums or Huddles or something different altogether – are more likely to get in the way of doing the job rather than enhancing your chances of finishing it. I had weeks where I endured (that is the right word) three and four meetings a day, usually with the same group of people, to talk about the same thing and arrive at the same (lack of a) conclusion. When you spend an hour and a half with six individuals planning a meeting you are going to have with them TOMORROW on the same topic there is something very wrong, surely?

But it seems this is increasingly the way of the world now. More and more companies are “going Agile” and of course I needed to do likewise – not easy at my age, with dodgy hips and failing eyesight. I tried, really, but it made less sense when I left that gig than when I had started. I moved elsewhere to another project that was allegedly Agile, and it made even less sense – perhaps “Agile Methodology” means something completely different in the Eastern Mediterranean, I don’t know. But it was nothing like the Agile methodology the other project had employed. Either way, it seems to me that knowledge of the business, adequate time management, a degree of common sense and an ability to communicate effectively both verbally and in writing (all key skills in my humble opinion) are no longer enough for modern IT project work. Which is a shame.

I have contacts in the recruitment world who are no longer called Job Advisors, or Career Counselors or, worse, Head Hunters. They are now Agile Evangelists. Well, sorry, but until I work on a big project that religiously follows the Agile Manifesto and manages to succeed within time and budget, Scrums, Sprints and all, I will remain unconvinced. An Agile Agnostic? Yes, that sounds about right. But it’s not going to happen now, as I’ve moved on in my life and left the business. And to be honest I’m happy about that. Agile continues to drive IT projects all over the world. And no doubt it will continue to do so and continue to line the pockets of the two (inevitably) Americans who devised it – at least until someone comes up with an alternative.

But it's NOT a methodology. Methodologies don't normally give you simply an idea what to do, just provide suggestions, they tell you exactly what to do, in a complete range of circumstances. As far as the Agile Methodology is concerned, both from personal experience and hours reading through various tomes on the subject, it simply does not do that. It's a nicely concocted set of acronyms, buzzwords and brain-farts that add up in practice to little more than a money maker for its creators. As an IT project guide or methodology it has more holes than Swiss cheese.