Agile mindset to problem solving

Learning objectives:
* Iterative and incremental
* Empirical process improvement
* Experimentation
* Short feedback cycles

How can you tell when agile has taken root?

In my time coaching agile teams, there was always the nagging question of how long it took for an agile mindset to take root. If the coaching intervention ended too soon, teams would slowly revert back to old ways of working, hopefully with one or two new ideas having stuck. If you stayed too long, your impact diminished and, as per the wisdom of Nanny McFee, although the team wants you around, they no longer need you.

When I started my career, I was inducted into the large corporate way of building IT projects. I began at a bank on a home loan modernisation programme. By the time I started, there had been a lot of work done to develop a business case with all the necessary scoping and budgets approved to get the green-light. Business analysts had spent many months preparing a comprehensive spec, that ran into hundreds of pages. I was included in many joint application development (JAD) meetings where we unpacked this spec. After six weeks of understanding the requirement, the project team had to put together a comprehensive project plan, based around a lengthy Gantt chart. Resources (a.k.a people) were allocated to the project and everyone had a carefully planned out list of things to do, with rigid due dates.

Development commenced and for the first week, things looked pretty good. We closed out the week about 98% on track. The dependency on the infrastructure team for the code repository hit a little snag, but that would be rectified the next week. Weekly status meetings made their way into our schedules and we began the ritual of packing out a large boardroom to report on progress. Predictably, only about 5 people really spoke in this meeting, but we were all physically present. The project management office had a few people on the team and they busied themselves with endless report writing to feed back information to interested stakeholders. The second week we slipped to about 90% completion… the repo was still not resolved.

Fast forward two years later and the programme was not in good shape. Dependencies had snowballed into many missed deadlines and the Gantt chart was in its 174th revision. Sadly, this project was canned and all the work we did never got into the hands of users.

Years later I was introduced to the ideas of agile. My first foray into agile ways of working was a daily standup. We were so proud of this new way of working… little did we know. I moved to a new client and then experienced scrum done right for the first time. All the agile events were observed and we took time to retrospect every sprint and look for ways to improve. My eyes were opened.

A couple of years into this agile centric team and I had progressed into a scrum master role, followed quite soon by joining the agile coach development programme and trying to pass on this knowledge to others. I was fortunate to have many teams to work with as we were part of a large IT division. To begin with, I was awful. The teams I worked with struggled to grasp the agile mindset and as soon as I moved off, would revert to old habits, with little lasting impact. Over time, however, my skills improved and I realised the importance of agile champions in each team and most especially how critical supportive leadership is.

In 2020, the COVID pandemic gripped the world and panic raced through society as we were all mandated to stay at home. As an active member of my church music ministry, things looked bleak. How were we going to offer spiritual guidance to our parish without gathering in person? One of my friends had been encouraging us to build a digital presence for some time, but leadership was not receptive. The pandemic was the nudge we needed. Embrazend by the need to do something and with a shoestring budget, we quickly broke the problem into a to-do list (backlog) of tasks, prioritised that list in Trello and all took ownership of our respective jobs. We spoke daily to coordinate efforts and worked the Trello board together. The WhatsApp group buzzed with chatter as each item was ticked off the list. Within two weeks we had our first camera live streaming to YouTube.

This was the moment that I had the personal realisation that my go-to problem solving style had shifted to an agile mindset. Where in the past I was all about planning and co-ordination, nowadays I’m about talking to the team, building a backlog, iterating quickly and holding short feedback loops where we inspect and adapt our plans.

We framed live streaming of Mass as an experiment, hoping to get 100 subscribers to the YouTube channel. When that succeeded, we purchased a camera and streaming box for the church and formalised the setup. A little later we appealed for a suitable computer to dedicate to streaming, which a generous parishioner donated. The setup has iterated continuously and live streaming of Mass has been running ever since, with over 3 200 subscribers to the channel.

I knew I had made the shift to an agile mindset when I realised that when I am faced with a largish problem to solve, I start by breaking it into several smaller components, visualise the work and then build it. Building incremental steps and iterating to an acceptable solution gives a much quicker and better quality result. This web site is an example of one such experiment.