By Paul Jackson
Scrum (and agile for that matter) is a common sense approach to project management that we have all probably used, maybe without calling it Scrum, to manage a project at some point in our careers. Case in point: a few years ago I joined a Royal Navy Warship as the Logistics Officer. I had been a software development project manager for a few years, but this was an operational posting, which is inherently different. I joined the ship in Portsmouth after she had returned from a lengthy deployment. We were scheduled to spend several weeks in recovery and maintenance before returning to sea. It should have been a quiet time to take over the department. It turned out to be quite the opposite.
Four days after joining the ship, the commanding officer called his senior management team to a meeting. He informed us that we had been tasked to protect the merchant fleet sailing to support Gulf War 2. Our mission: to protect the fleet as they transited the Straits of Gibraltar. Over 100 ships were expected to pass through the Straits over eight weeks. We also had a confirmed terrorist threat, so we had a real job on our hands. The CO told us we had five days to prepare the ship to deploy. As you might imagine, the Logistics Department had a massive role to play in readying the ship for deployment. We needed enough provisions to feed the ship’s company for ninety days, the right spares onboard, and sufficient sterling and foreign currency to see us through.
At this point in my career, I knew nothing about Scrum. I did, however, have a good idea of what it would take to ensure that we would be ready to deploy. In my short time onboard I had already identified the “movers and shakers” within my management team. I called them to my cabin and briefed them on our new assignment. I told them to develop their deployment requirements and work out their daily priorities for the five days remaining until deployment. I gave them our goal and sent them off to prepare their teams. They were to report back to me at a daily meeting, which we would hold every day at 0830 in the stores office. At that meeting, each manager would have two minutes to update us on progress and issues. At the end of the meeting, I would summarize with a redefined goal for the next twenty-four hours.
After our initial meeting, we met each day at 0830. As planned, each manager briefed on what they had done since we last met, what would be achieved in the next twenty-four hours, and what impediments stood in their way. I undertook to move their obstacles and briefed the CO on progress at our daily Command Briefings. We sailed five days later, fully prepared and ready to meet our mission.
Without knowing Scrum at all, I had set a sprint goal (“We have to be shippable, quite literally, in five days.”), developed the product & sprint backlogs (our deployment requirements and daily priorities), and established a daily scrum. I knew intuitively at the time that we had to come together at least daily to monitor progress and that any issues affecting the sprint goal had to be resolved by me, so that the team could be left to deliver. Now I understand that what I was doing was setting up daily scrums and acting as ScrumMaster for the team.
What seemed like common sense to me when I employed it on the ship turned out to be a methodology that is being put to work in more and more software development organizations each year. Whatever you call it, Scrum delivers.
