The Agile Mindset Explorer

What is “Scrum Solo”? It is the situation in which people think that simply requiring their teams to follow the guidelines of the Scrum Guide is enough to achieve customer delight, engineering excellence, and sustainable continuous improvement.

Scrum is an attractive framework for organising work in situations in which there is sufficient inventory of work items to establish a steady cadence of planning and development. It gives the Product Owner the ability to direct the efforts of the Development Team in order to create product increments assembling the most valuable items from the Product Backlog first.

Scrum provides an effective way of harnessing the energy of self-organising Development Teams, keeping everyone in sync through Daily Scrums, and continuously improving through effective Sprint Retrospectives. TheScrum Master is of service to the Development Team (as chief obstacle remover), the Product Owner (as a coach and facilitator), and the Organisation in which the Team operates (as a leader and ambassador).

Scrum is designed to be lightweight and simple to understand. As a positive consequence, Scrum is directly applicable and has also proven effective in fields other than software-intensive systems development as well.

However, Scrum is difficult to master, and by itself (solo), is not quite sufficient for long-term economic success and effective technical and organisational improvement in a software development context. Other influences must be blended in to complement it.

For example, Scrum is completely silent on the many engineering aspects that provide the foundation for virtually all effective agile software development teams. Without engineering excellence, Teams can get rapidly mired in technical debt, and customer delight turns into disappointment, leading various people to mistakenly attribute failure to Scrum and by extension agile methods in general.

The Scrum Guide is mute on topics like Continuous Integration, Pair Work, Test-Driven-Development, and so on. As a result, most of the best Scrum teams also draw inspiration from and practice many of the techniques of Extreme Programming.

Scrum also says nothing about how work might flow through the Team during the bounds of a Sprint. It is assumed that Development Teams will just figure out an effective Sprint plan. Depending on the level of professional maturity and work habits of the Team members arriving consistently at effective plans is not always a foregone conclusion. To fill this gap, and develop a steady habit of improving the work process, most of the best Scrum teams draw inspiration from Kanban, visualising the flow of work, limiting the batch size of the Team’s efforts, and creating a smooth flow.

As yet another example, as currently defined, Scrum focuses on a single Development Team, with one Product Owner and a Scrum Master. Due to its need for simplicity, Scrum does not tackle the concerns of scaling the use of agile methods to multiple teams or across portfolios, programs or product lines and many product releases. To address such needs, a range of frameworks have emerged, such as SAFe (Scaled Agile Framework), LeSS (Large Scale Scrum) and DAD (Disciplined Agile Delivery).

The bad news is that in this Universe there can be no “perfect” agile team, with a “perfect” composition and work process, so even a Scrum+X+Y+Z work process cannot be expected to be the “perfect” answer. The good news is that life is full of change, and there is always room for improvement. Perfecting agility is a journey of continuous improvement, rather than a destination.

Notice how Scrum Solo cannot address the full range of concerns involved in effective software-intensive systems development. If you are passionate about creating organisations that delight their customers and at the same time make work joyful for the professionals engaged in them, you cannot be content with just Scrum solo. When pursued exclusively, and especially in Teams and organisations with many inexperienced practitioners, Scrum is harmful, because it leaves too much open to mistakes, false starts and failure.

As an effective countermeasure, consider broadening your learning and practice horizon, embracing and experimenting with ideas, techniques and habits from some of the other sources mentioned above. Strive to develop a habit of identifying promising learning opportunities, run improvement experiments, measure the results, then reflect, adapt accordingly and repeat.

There is no universal “best practice” learning path. There is no single, comprehensive “recipe” for developing high-performance Teams and organisations. What works well for one Team may not be equally suitable for another. People have different attitudes, skill-sets and levels of expertise. 

By all means, do your best to master the elements of Scrum, strive to create elegant and simple Scrum Artefacts, and learn to enjoy executing the Scrum Events smoothly. Then, make sure to keep learning and improving, expanding your Teams’ and organisation’s range of capabilities, skills and habits beyond the natural limits of the Scrum framework.

People that have not attended the PMI Leadership Institute Meeting last week in Phoenix, Arizona, may not be aware that the Sheraton Downtown hotel closed for a week after an electrical fire last Saturday morning.

The Sheraton Downtown is located only a block away from the Convention Centre where the LIM and Congress were hosted, and therefore it was a popular place to stay at for both PMI members and staff.

The commotion began around 11am, with fire crews and police dispatched to the hotel to get the source of the smoke under control - the cause of the electrical fire has apparently not been fully identified yet.

A decision got made to evacuate the hotel, and about 800 guests had to be guided in near pitch-darkness up and down dozens of flights of stairs by firemen armed with little more than glow sticks to provide some form of illumination. Due to the nature of the incident, all power got cut off, and since the emergency lights did not have a battery backup, all stairwells and internal corridors plunged into total darkness.

The PMI staff and volunteer organizers pulled off a near-magical location rearrangement for the Awards Ceremony from the third floor Phoenix Ballroom in the Sheraton (now off-limits due to the evacuation) to the Convention Centre, such that by 7pm (with barely an hour's delay) you wouldn't have believed that it wasn't intended to be held at the Convention Centre all along. I suspect we shouldn't have expected any less from such a seasoned group of Project Management professionals.

However, I know from first-hand experience that the Phoenix Fire Department people impressed all of us "refugees" from the Sheraton even more. Here are some of the lessons in Agile Leadership that I saw the Fire Department people demonstrate through example:

1. Everyone was treated with utmost respect at all times. There was no rushing, no shouting, no agitation. Everyone kept a sustainable pace. The firemen also inspired deep respect through their calm, collected, professional attitude.
2. No-one was overburdened. The firemen always worked with relatively small, manageable groups of people. They organized clear access paths to promote a smooth flow of traffic and avoid congestion. They regularly kept in touch with one another by radio, asked for and gave help as-needed, with clear, precise instructions, self-organizing to maintain a smooth flow of people through the building.
3. Safety was paramount. There were always firemen with flashlights in sight of the people climbing up and down the stairs or walking through the dark corridors. The firemen distributed glow sticks to everyone and only escorted people up the stairs once some glow sticks were dispersed on the stairs every few steps for a bare minimum of visibility.
4. Careful attention was paid to mistake-proofing. Before admitting people into the building, one fireman invited a small group of people in the gap between entrance doors. He would explain what happened, and that people were asked to prepare themselves to go up to their rooms, pack everything, and get back down. He would then check that people felt they were fit enough and prepared to make the trek up the stairs and confirmed that they had their room key with them (the room locks were battery activated, so everyone still needed a room key to get into their own room). In this way, they sought to avoid the unpleasant situation of climbing 20+ floors only to discover that the key is missing and another trip down and up would be required. Fortunately, as a matter of defense-in-depth, some firemen in the building also carried master keys, so when one PMI staffer found to her dismay that her key doesn't work anymore, she was spared having to make another trip down and back up for a working key.
5. Regular Training: Firemen are constantly training to climb 30+ flights of stairs every other day, so they could keep helping to carry bags for some of the hotel guests, saving them from having to make repeated trips to complete the evacuation of their rooms. With no elevators, all bags had to be carried by hand down the stairwells, for up to 30 floors.

In this way, in just a few short hours over 800 people were evacuated safely from the hotel, with no further mishap or injury. The hotel staff also worked their magic in rapidly finding alternate accomodation, communicating directions clearly, and organizing free transportation to it. The Professional Awards gala then proceeded smoothly, and what could have become a very disappointing disaster turned into an exhilarating adventure.

What else have you learned from the people of the Phoenix Fire Department? How do you think we may apply some of their lessons in some of our own project emergencies?