Agile meets large

Over the last year I have been fortunate and have had the possibility of running a large infrastructure IT project. Once the project was approved and funded, the project owner (CIO) and the top guy (CEO) insisted this be run in an agile style. If not for other reasons, then for the experiment and learning. 

In my company we have run several smaller projects, typically less than 10 weeks/5FTE, and often with end-user/customer centric solutions, as agile. These have shown that the agile approach works. We are also in the making of setting up tribes, squads, etc. for fixed capacity system development, but for the large projects (+1 year/+20M$) the approach has traditionally been traditional. 

So, this is how Agile came to meet Large. 

A little spoiler at the beginning. It worked! Running a project with over 30 project members with a long duration, agile style, worked. Actually, the timeline was shaved off 20% (and typically our large projects on the contrary, add time). The cost was not changed, as it was the capacity utilization that increased, not the scope that was reduced.

In short there are 3 main reasons to run a project agile

• It has high uncertainty
• It needs to be delivered fast
• It spans many disciplines 

The principles we followed were:

• Visual planning and document “as-built”. We had everything on the wall, and everyone participated in the planning of all phases. Anything of value had to be put on the wall (all major design, principles, workflows, relationship networks, influencer map, objectives, plans, cost, vendors, solutions, ideas, etc.) for all to see and discuss.
• Co-location and complete teams. The project had a physical location. Most of the external consultants were 100% allocated to the project, and most of the employees were allocated 40%. The 40% was at fixed times, with mandatory presence in the project area. So, two days a week everyone needed was physically at the same place, at the same time. The 100% resources planned the workshops and sessions, ran them, and would be in charge of any follow-up. The employees (40%) showed up and got tapped their knowledge. 
• Value creation through dialog. All value creation took place through planned workshops on the project days, where all needed resources would participate. No computers, no projectors, and no files. Only paper on the walls, either as part of preparation or as part of a creative activity planned as part of the workshop. We also ran this process with the vendors, and their feedback was that it was a very good way of running an RFI process as it focused on our need. Our own experience is that this process revealed issues with solutions much better and much earlier than a classic presentation as we simply asked them to design a solution for us, on the wall, using post-it notes.
• Fixed project rhythm. In addition to the classic daily standup and retrospect, we had the fixed project days where everyone was present at the same time at the same place. At the end of each of these fixed project days we had a “Gallery walk.” We spent a full hour going through in detail what all the other track/teams had done. So, after all fixed days you would be fully up to speed on all project activities in all tracks.

Thanks to the experimental mind of the top management I got to run a big project agile. This gave a lot of learning, and below I share some highlights. 

Who is the customer, with a problem worth solving? Finding the customer was not as easy as it sounds, as infrastructure projects typically do not have a true end-user as the customer. But without a customer, there could be no problem. We found both the internal service producer and the internal service consumer as our main customers, and through that we were able to pin down the problem that we solved (a modern, automated and self-serviced IT-Infrastructure).

Planning on the wall. But what? We realized early that an overall plan is always needed. We never committed to an end date or cost, but we always offered management a reasonable time frame and a reasonable cost. We also had a running business case and a complete TCO calculation. But we only committed to the next toll gate. 

So, we followed the rule saying “plan, but just enough”. For us, this meant overall project plan, delivery plan for next phase, activity plan for next week, and detailed run books for each workshop and each project day. Seen from a time perspective, we had only rudimentary long-term plans, but minute to minute plans for our project workshops.

Cupcake. A core part of design thinking is to work through smaller versions of the final product. This can fall under the term minimal viable product (MVP) or proof of concept (PoC), or as we have chosen, the cupcake approach. The analogy pointing to how to make a wedding cake by making first a cupcake, then a single layer, and finally the full multi layered wedding cake, giving the bride and groom ample opportunity to adjust both colors and taste.

As we had no end user to sit down with, and a project with usable deliveries more than a year into the future, translating the concept of MVP or Cupcake was difficult in the beginning. What we ended up doing was cutting out some cardboard and wrote “server” “FW” and “Switch” on them. Then we invited the vendors to come and play with the cardboard with us. Once the cardboard design made sense we moved over to some real servers we had bought, and installed the same there (one carboard card represented a real physical entity), and verified that the concept still worked. We saved a lot of time and effort doing the trial and error on cardboard, and not through installations on real servers. And only after the cardboard “install” and the reduced environment install did we start scaling up.

So, MVP, PoC and CupCake can be difficult. Look for something like this:

• One of many (from a list)
• A representative (something that is similar to several others)
• A part of a whole
• A concept that proves something (PoC)
• Something that only works if you want it to (MVP)

Rhythm, fixed and absolute. Agile is no silver bullet, it offers a different, efficient way of working, but not a lazy one. In order to plan in short increments, you have to be certain that the needed resources are available. This can be done by planning an activity to a time where the resources have shared availability, or all the resources can be “forced” to have availability at the same time. With a fixed rhythm where all resources have set aside timeslots in the foreseeable future, the actual planning of what the timeslots can be used fore can be postponed to a “plan next week” session. This gives the opportunity to prioritize the resources based on the project’s actual needs, and it forces a progress with a set interval.

The reality is that this is an extremely efficient way of working. There is no waiting for shared timeslots of critical resources, and the progress is steady, based on the heartbeat of the fixed timeslots. 

Especially internal resources with specialized domain knowledge, either company specific or technology specific are scarce, and difficult to allocate to projects in sufficient quantities. Booking these resources at fixed timeslots maximized the utilization of them. Prior to shared time, other resources planned each session in detail, and after a session they did post analysis, documentation, and if needed prepared for follow up sessions. In this way the time-limited resources only contributed with their knowledge. 

A clear lesion learned is that if you have all the right resources together, and a structured guide/approach to a discussion, more is done in 45 minutes, than in 4 weeks with emails. Sometimes this is called “Fat&Short”. The Fat part referring to all resources needed, and the Short to a shortened timespan they are needed. The theory being that you need a full team to get needed progress, but since you get progress fast the resources can be released to other projects or activities.

Having such a rhythm or heartbeat in the project gives continual progress, but it also makes the project spin around these fixed timeslots. Before a session it is all about planning it, collecting data, setting up the techniques to be used, and after it is all about taking the gained knowledge, document it and applying it, making it ready for next session. Compared with a traditional project model, it differs as the plan is not focused on work packages or deliveries, but on utilizing timeslots. 

Governance, how to-do when the documents are not made. Governance is about control and not templates, but is often (at least in Enterprises) manifested through set templates. And often the control is also about if the template is filled out, not if the content has value. Risk assessments being a good example. It is mandatory for a project to have one, and there are several governance bodies controlling that it exists, but seldom do these governance bodies help with identifying risks.

An agile approach can help increasing the quality of governance as it requests a deeper participation from the control owners, over a simple recipient role. Based on the experience from this project refusing to comply with templates, but inviting control owners to participate in fixed-time sessions over the topic, being architectural principles, risk, GDPR, privacy or other topics they all concluded that they knew more about this project than any other, that the topic they were tasked to assess had better quality, and that they spent less time. In short; they got more for less. 

Agile says “Document what is needed”, so we did just that. All sessions run were documented in form of pictures (of the wall) afterwards, trackable to session, time and participants. Also a few data points are used enterprise wide, instead of making the harvest of these difficult, we filled out the template they needed.  

Why is it ok for management to have no control? It all boils down to some fundamental questions. Number one being “did you really have control?" Classic control through task burn rate, Milestones, handover requirements etc are illusory, and C-Level knows it, but in the absence of something better it is what have been focused. The main drawback of this approach is what makes it illusory, it does not encompass uncertainty and change (of scope) is costly, and discouraged. In modern IT projects defining the scope is part of the project, the need is analyzed as part of the project, not as a separate activity beforehand. It has a lot of uncertainty, and no set scope. The final size of the project is a function of how much more value it bring to the business (through the customer), not a set cost prior to starting it.

Agile offers a way to control this, not at a detailed level, but at set tollgates, milestones and releases. The project is sliced in smaller parts, of which all give value. The part with the highest value will be prioritized first. Also parts needing less investment can be delivered earlier than those that require large HW investments. 

It gives management a real possibility to stop the project, as there are several smaller deliveries not just one large, and it gives the possibility of postponing the large investments until the product has proven useful. Agile also invite management to partake more intimately in the project, thereby giving a hands-on feel for the progress in the project. 

And last but not least, it gives management a way to test multiple ideas, and funnel the good ones into actual deliveries, and the not so good ones to the permanent waiting list. 

So Agile changes the way management exercises control. They have less control between milestones/tollgates, but more actual control at the tollgates as there are tangibles to assess, not just plans.

To summarize, the agile approach works just fine on large projects also, the effect perhaps being even more significant than in smaller projects. It is fun, not just from a project management perspective, but for everyone involved. Everyone is just that, involved. The creation is teamwork, and the joy is shared. 

Agile forever!

Other articles

Agile meets Reality – How to bridge the Great Divide, https://www.dhirubhai.net/pulse/agile-meets-reality-how-bridge-great-divide-arnstein-schei/

Steps to Automate release, https://www.dhirubhai.net/pulse/steps-automate-release-build-functioning-pipeline-continuous-schei/

Uncertainty in Agile projects, https://www.dhirubhai.net/pulse/uncertainty-agile-projects-arnstein-schei/