Scrum down for software excellence

To fully appreciate this article, the reader must have some understanding of rugby.

I recently attended the Scrum Master Certification course offered by ScrumSense. The popularity of scrum is evident as this course was booked out well in advance. The course was presented by Boris Gloger, a world-renowned scrum trainer. Gloger has been training Scrum Masters since 2004.

Though the course itself was enjoyable and imparted many new ideas and concepts, I still question the certification aspect, and not just this particular one, but all certifications that can be obtained in a few days.

As with any certification course, the real value lies in applying what was learned, and gaining subsequent experience. One of the lessons in the book: "Lessons Learned in Software Testing", sums it up perfectly: if you can get a black belt in only two weeks, avoid fights. For newcomers to scrum, coaching is essential.

One important fact Gloger highlighted is that Scrum concepts are fairly simple, but the implementation is not. Let us focus on the roles in agile scrum. Roles are well defined for the:

* Scrum master
* Product owner
* The team
* Customer
* User

A vital role is that of the team. The team is responsible for delivering the software and hardware. Let's compare the scrum team composition, with the actual composition of a scrum in rugby. That is where this framework derived its name, so it is more than appropriate.

In the 15-man version of rugby, the scrum is made up of eight players:

* Tighthead prop
* Hooker
* Loosehead prop
* Two locks
* Open-side flanker
* Blindside flanker
* 8th man

We need to bring one more player into the picture, and that is the scrumhalf. While not involved in the scrum itself, he can be seen as the main link to and from the scrum. The scrumhalf feeds the ball into the scrum, and then collects the ball from the back of the scrum after it has been hooked.

Each player in the rugby scrum can be linked to the members in the agile scrum. Agile scrum can be seen in the context of a team of IT professionals using the scrum framework to deliver software.

The scrumhalf position can be linked to that of the product owner. The product owner must write the user stories, provide the vision of the product and work very closely with the team to define requirements and strategy. The same applies to rugby: the scrumhalf is the strategist, links the team to the backline, and feeds the ball into the scrum. The scrumhalf also collects the ball at the back of the scrum (yes, the 8th man can also do that, but in general the scrumhalf will do it more often).

The product owner takes ownership of what the agile scrum team delivers.

Now, let's move on to the big guns: the front row. In rugby, the loosehead and tighthead props are not just front-rowers any more, they are distinct disciplines and not any player can assume that role.

It is seldom that a good loosehead prop will make a good tighthead prop and vice versa. The loosehead prop is management and the tighthead prop is the development lead on the agile scrum team. The props, in combination with the hooker, are the heavyweights, the foundation, the tough guys.

In agile scrum, the role of management is sometimes overlooked. Without management's full support, the implementation of scrum will fail. If management decides that scrum is the way to go, they must see the decision through by committing to training, funding for coaching, and supporting the Scrum master in their efforts.

The tighthead prop, or in the case of agile scrum, the lead developer, is another team member that must be a pillar of support. The lead developer must set a strong foundation and be well experienced in agile scrum and trust the framework. Without his support, implementation will be extremely difficult. The rest of the scrum team will look to him for guidance, and should he not be committed to the framework, then commitment from the rest of the team will be questionable.

The Scrum master equates to the hooker. According to the scrum framework, the Scrum master is not part of the delivery team, so the Scrum master does not actively participate in building the software. Let us apply this to the whole front row. The front row in rugby sets the foundation for engagement, but is not the true engine room: the players behind them are. But without a strong, heavyweight and experienced front row, the team will not survive. The same applies to the agile scrum team: management, the Scrum master and the lead developer are three areas of scrum that form the foundation.

The Scrum master, or hooker, is the leader in an agile scrum team, and mostly the leader in a rugby scrum. They might not always be the captain of the team (but again, it is one of the positions ideal for captaincy or vice-captaincy), but they are clearly leadership positions.

Players such as Sean Fitzpatrick, Uli Schmidt, John Smit and Keith Wood come to mind. These players were tough, they could throw a punch, and also take one on the chin. They led their teams from the front, physically and mentally. In agile scrum, the Scrum master protects his team, and leads them to successful product delivery. The Scrum master must ensure that the team sticks to scrum fundamentals, and assist them with removing impediments. Having both a Scrum master and project manager on the same team is not advised. The Scrum master fulfils the role of project manager.

The rest of the rugby scrum team is the engine room. This is where most of the work is done. In agile scrum, this is the development team (system analysts, business analysts, UI specialist, test analysts, developers). Gloger recommends a team size of five. A team of five promotes communication in the team, which is vital.

For the sake of brevity, we will not discuss the roles in the engine room in detail. This does not mean that these roles are not important, as they are as crucial as the front row. Together they form the scrum team, so they cannot be viewed as separate entities, and several implementations of scrum will fail for this reason. Scrum is not just about the team, but also the foundation that supports the team.

We have often seen the failure of scrum in practice specifically for this reason. The team did not have the full support of management to implement scrum and the lead developer did not support the scrum framework 100%. The lead developer kept wanting to adjust the framework to suit his style of work.

In general, some view the purist implementation of scrum as a hindrance. In my opinion, the purist way is the only way to implementation, and not for just agile scrum, but also rugby scrum. You cannot scrum against the All Blacks without a committed scrum team, and scrumming in a purist fashion. With agile, the purist way is the basic way. To be successful in scrum, you must do the basics right. Too many teams want to ignore the basics from day one because in their opinion scrum allows you to do just that. That is one of the biggest mistakes a team can make.

Agile scrum is not rocket science. Stick to the basics, and only apply changes when the basics have been mastered. Some advocate three sprints to master the basics: you will need more sprints if you do not have the luxury of a scrum coach. Without a scrum coach, it will be difficult to implement scrum; not impossible, but just difficult if you are new to the concept.

In closing, a word of advice to CEOs and CIOs. Do not send the Junior Springboks to take on the senior All Black team. They will fail, not because of lack of commitment, but purely because they lack the strength and experience. So pick your pack of forwards wisely before your next game.

Go, Bokke!