When is agile not Agile? And why Waterfall is not always wrong!

In 2004 (when I started writing this blog), I was working for a company called conchango*. The developers talked a strange language – about Scrum and XP – and it was nothing to do with Rugby Union or Windows but it did have something to do with sprints…

That was my first encounter with Agile software development methodologies. Not being a coder, I haven’t done a huge amount of agile development, with the infrastructure projects I’ve been involved in generally being run using a traditional “waterfall” approach.

These days, things are different. There’s a huge push for Agile projects and the UK Government Digital Service’s Service Manual even says:

“You must use the agile approach to project management to build and run government digital services.

Agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback.”

Agile and government services: an introduction

There’s also a lot of confusion in the marketplace. Colleagues and clients alike are using the word “agile” in different ways. And there’s an undertone that agile is the one true way and waterfall is bad.

No!

Agile/agile/agility

Let’s start off by comparing uses of the word “agile” (in IT) and what they mean:

  1. Agile (big A) often relates to a methodology – for example APMG International’s AgilePM project management methodology or the AgileBA approach to business analysis – but really they have their roots in Agile software development, with the Agile Manifesto, written in 2001.
  2. When we talk about being agile (small a), it’s a mindset: the approach taken. Literally, being able to adapt to change and to move quickly. We might use Agile (big A) approaches to help increase our agility (small a).
  3. Agility is about reaction to change. Many business want to be agile. That doesn’t mean they only run projects with Agile approaches. It means they want the ability to flex and change in line with business requirements.
  4. And then there’s the UK public sector. Specifically Police, who for some reason refer to what the rest of us consider to be remote/mobile working as agile working (as shown in this Agile Working Policy from West Yorkshire Police). That’s just an anomaly.

So that’s Agile/agile/agility sorted then. There are Agile frameworks/methodologies/approaches to delivering outcomes in a more agile manner, to increase organisational agility.

Agile=good, waterfall=bad?

Now waterfall. If Agile, is the one true way, waterfall must be old hat and avoided at all costs, right?

Not at all.

Agile projects work well for quickly creating a minimum viable product (MVP) and iterating development – for example as a series of sprints. They are great when there is a known problem but the requirements are less clear. The solution can evolve in line with the definition of the requirements. The requirements may change as the solution develops: respond to market changes; adapt to new requirements; fail fast.

But some projects are less defined. In a 2018 blog post, Matt Ballantine (@ballantine70) referred to unknown problems with unknown solutions as tinkering. That seems fair – if you don’t know what the issue is, then you can’t have a solution!

Similarly, unknown problems with a known solution. That’s nonsense. Or “WTF?” as Matt so succinctly puts it in his 2×2 diagram:

Matt Ballantine's 2x2 diagram of which path to take, including Agile and Waterfall approaches
Matt Ballantine’s 2×2 for which path to take, including Agile and Waterfall approaches (used with kind permission).

You’ll see though, that there is a place for waterfall project management. Waterfall works when there is a known problem and a known solution. Instead of constantly iterating towards an end, work out the steps to go straight there. It will almost certainly be more efficient. Waterfall projects are based on the golden triangle of time/cost/quality (which together define scope). A known deliverable (scope) bounded by how fast/cheap/good you want it to be – and there’s always a trade-off.

So there we have it. Agile is not a silver bullet and there is still a place for waterfall projects.

What to use, when?

In my line of work, Cloud Transformation might appear to use a combination of Agile and Waterfall approaches. We might create a virtual datacentre in Azure or AWS and take an iterative approach to migrating workloads but that’s still really just Waterfall with incremental delivery – even if a Kanban approach is used to inject some urgency! Similarly migrating batches of mailboxes to the cloud is just iteration, as is a programme that’s adopting Office 365 workloads one by one. An Agile approach comes into its own when we think about Business Transformation, or Digital Transformation, where we can define an MVP and then use sprints to iterate development of a set of new business processes or the digital tools to deliver those processes in a new way.

Further reading

For a clear definition of Cloud, Business and Digital Transformation, see my blog post from last year: “Digital Transformation – it’s not about the Technology“.

* The small c is not a typo – that was the branding!

Why landscaping my garden was just like an IT project

Over the last few weeks, I’ve been redeveloping the garden at home and the whole experience has made me reflect on the way that IT projects are often delivered…

Who’s been developing the garden?

Well, when I say “I’ve”, that may be pushing it slightly… I paid other people to do significant chunks of it but that’s the first similarity. I started work and quickly realised that it would a) take me a long time and b) involve the use of tools and machinery that I don’t have so I needed to engage specialist assistance.

This is just like my customers who have something in mind that aligns with their strategic goals and objectives but they lack the resources or experience and so look externally for assistance.

Getting some quotes

Having decided that I needed help, the next step was to get some idea of what it might cost. After speaking to a selection of potential contractors, I knew that my budget was hopelessly optimistic and I’d either need to scale the plans back or dig deeper into my pockets.

Again, just as in my professional world, everyone has their idea of what something might cost but sometimes that’s just not realistic.

How quickly can we start?

Having agreed on a price and a scope, the next question was how soon? Actually, for me this was pretty good: 2 weeks to start and it should take about 2 weeks. Great. Let’s do this.

In my professional life, I come across procurement periods that can run for months but then the project must happen right now. It’s not realistic to expect a professional services company to have people waiting around for your order (if they do, then maybe ask why). Expect to take a few weeks to engage.

The flurry of activity

The big day came. My drive was filled up with a skip and several tons of aggregate, sand and cement. Materials came and went. People were on site. Earth was moved. Things happened.

It always feels good when something becomes real. Progress on any project is good, especially after waiting a while to get going. But don’t expect a smooth ride the whole way…

The first sprint delivered

Whilst my family took a break, work continued at home. Drainage was installed, wooden sleepers were built up into steps and walls and a stone patio was laid.

That sounds like a successful first sprint. Step one completed, demonstrable progress and a milestone payment due.

Slippage

But hang on, we’re already 9 days into a 2-week project and there are still many items on the backlog. The weather had either been too wet or too hot. And there were delays from the skip hire company that led to inefficiencies in removing materials from the site. We were making progress but the timeline (and so the budget) was starting to slip

Many projects will have unforeseen issues. That’s life. Managing them is what makes the difference. And the key to that is communication between client and supplier.

Scope creep

What about the electrics? I had already spotted that they were missing from the quote but there was armoured cabling to be buried before the garden was completed. And that meant bringing in another contractor. Thankfully, he had worked with the landscaping team before, so he could fit around them without delay (at least for the first fix).

More contractors mean dependencies. Even when teams have worked together previously, there will be some complications to work out. Again, good project management helps.

When will this end? And what about the budget?

Sprint 2 was more of a jog. There was still earth to move, a pergola to be built, a concrete base for my “man cave” to be poured and turf to be laid. Time was ticking – the gap I’d left between the landscaping and the project work packages I was due to deliver myself (log cabin construction, garden furniture arrival) was shrinking – and with work taking place on a time and materials basis the budget was stretched.

Time for a meeting. Let’s agree what’s still left to do and how long it will take, lock down the budget and push towards completion.

I have to admit this was frustrating. But I’ve seen it in my world of IT too. Want a fixed price? Be prepared to pay more as the risk taken on by the organisation delivering the work needs to be factored in. Time and materials can work both ways (finish early, pay less – or to project over-runs) and after a while, patience will wear thin. Again, communication is key. Establish what’s left to do in the agreed scope, nail down the timescales and push for completion.

And as for the other work packages, very few projects exist in isolation. There’s nearly always an entire programme of works to deliver to meet the stated goals/objectives. Some realism is required about how dependencies will align because if you expect the various work packages to run on from each other, you should be prepared for the occasional disappointment.

Phase 1 complete

Three and a bit weeks after work started, phase 1 was complete. And it looked great. All the pain was worthwhile. Just in time to start construction of the log cabin on that base.

phase 1 of the garden completed

60% over time, 7% over budget. Not wonderful stats but also not atypical.

Postscript: Phase 2 delayed

The log cabin arrived on time but was damaged on delivery. And it would take 2 weeks for a replacement roof apex to be manufactured and shipped. With most of the materials on-site though, it needed to be built as far as it could be and then wrapped up to protect it from the elements.

Sometimes, even the best planning can come undone. Supplier contracts might help with speedy resolution of issues but sometimes there’s nothing to be done except to sit and wait…

Using the Microsoft Project calendar to block out time when people are not available


I hate Microsoft Project.

I mean, as a tool it’s OK, but it’s idiosyncratic and time-consuming to use; and even copying/pasting information is not as straightforward as it should be. Besides which, far too many people confuse a Gantt Chart with a project plan… and I blame Microsoft Project for that…

When I was at Fujitsu, I avoided having Project on my PC. If I didn’t have a license, I couldn’t edit plans… I could only view them. Unfortunately I can’t get away with that any more and, tonight, I lost most of the evening to some edits that went wrong with tasks getting split across days (I think I changed the working hours to reflect the hours we really work… but that messed something else up).

Anyway, I digress. Something I did find this evening was a really useful article describing how to change the working days for a Microsoft Project calendar. Using this I could not only add bank holidays that were missing in the standard calendar, but add the days that I’m not available to work on the project – for example because of annual leave, or other client commitments – so that the plan couldn’t allocate tasks to me on days I’m not booked to that customer.  You can also edit dates that people are available to work on a project directly (I don’t like referring to people as “resources”) but that doesn’t take into account odd days here and there of non-available time.

Next time though, I’ll leave editing the plan to the Engagement Managers…

The importance of good communications for project success


Once or twice a month, I travel to Manchester for work.  I usually get around by tram (Metrolink) when I’m there – there’s a stop close to our office and its convenient for travel to/from my hotel and the railway station.

Manchester’s tram system is being upgraded at the moment and, last week, I was amused by posters asking passengers to “bear with us whilst we make Victoria posh”:

As much as my southern sensibilities (actually, I’m from the East Midlands) cringe at the idea of “making something posh”, in fairness to Metrolink, they do have a great series of communications around their project (and whoever is responsible clearly has a sense of humour). One of my favourites is reproduced below:

“Dear [customers]
It can be fast.
It can be slow.
You can measure it in feet, inches, weeks, months and years.
And, occasionally, in leaps and bounds.
It’s going to take a little time.
And a lot of hard work.
But, rest assured, it is moving forwards.
Creating something better for us all.
So thank you for your patience.
And while our network is undergoing this transformation, we’ll keep you up-to-date with information.”

I like that poem, and I started to think about other applications for its use… something to consider for my next IT transformation project, perhaps – because good communications are vital to project success (and so many updates that I see are just dull walls of words).

Fixing the Apple iOS SSL bug on a jailbroken iPhone, without upgrading


My iPhone (4S) is jailbroken.  I won’t go into the details of how I did it as it changes with every release but I currently run iOS 7.0.4 and I used the Evasi0n method. Unfortunately, Apple has a pretty shocking bug in that version of iOS which means SSL transactions are not secure.

I didn’t want to go to the hassle of upgrading the OS, then jailbreaking again and, luckily, there is a workaround for fixing the iOS SSL issue on jailbroken iPhones without updating to iOS 7.0.6 (or 6.1.6) – although by the time I get this post written, 7.1 may well have hit the streets…

  1. Launch Cydia
  2. Switch to the Manage page, then select Sources
  3. Add Ryan Petrich’s repo (URL is http://rpetri.ch/repo)
  4. Go back to Manage and select Sources
  5. Search for SSLPatch and install as usual
  6. Restart SpringBoard when prompted

To test the patch (before and after), use the Goto Fail Apple SSL bug test site.