How can a business go about adopting Scrum throughout the company? For those of you who are unfamiliar with Scrum, we are not talking rugby. The term however is borrowed from the Game. Scrum is a Framework utilized in Agile Development. It is something your IT Business system “does”. That is unless they are utilizing Traditional Project Management for their Projects.

In February 2017, Gallup published the third edition of their report on “The State of the American Workplace”. In this report Chairman and CEO Jim Clifton states that “The Very Practice Of Management No Longer Works“. He continued by stating that only one-third of the Workforce is engaged. While this research is based on the US Workforce, the problem is not unique to the United States. Gallup offer a solution to this. Hierarchical Organisational structures do not Work in today’s world. Companies must reorganise themselves into Teams that are Cross-Functional and Collaborative. Such Teams are engaged and extremely Productive.

Adopting Scrum: Why is Scrum Essential for your Business?

Companies that have embraced Scrum shake their heads at the strange Team structures and the way things are Done. However they agree on one thing: Work gets Done and delivered very quickly and according to specifications. What’s more, this is not a fad. Scrum was very first described in the Harvard Business Review in 1986. This was within a short article by Hirotaka Takeuchi and Ikujiro Nonaka called “The New Product Development Game”.

It was not until the 1990s that others started putting it into practice. Meanwhile Agile Development was also taking shape. It was an evolution of earlier IT practices such as RAD (Rapid Application Development) and XP (Extreme Programming). Today there are many frameworks of iterative Development that fall under the Agile umbrella. These frameworks all adhere to the Values and Principles of the Agile Manifesto of 2001. Three of the supporters of Scrum were also signatories to the Manifesto. These were Mike Cohn, Ken Schwaber and Jeff Sutherland. They are all still luminaries in the field.

This brief history is to encourage you to consider Scrum as a feasible alternative for the entire Company. The migration will not happen overnight but when you have actually Done, you will have a Company of Self-Organising Teams. Remember that Scrum was not created for IT. IT teams simply took the ball and ran with it. Agile and Scrum can be utilized in most Enterprises and scenarios.

Adopting Scrum: Where to Start?

There are three responses to this question:-.

• If your IT shop have not yet adopted the Agile principle, they should start now. What this means is that they will not be able to help you to implement Scrum at an Enterprise level. You will require some expert assistance.
• Use your IT resources that know and understand Scrum and Agile to assist in a Scrum Project. The Goal is to migrate the Company, one Business unit at a time.
• If your IT is outsourced and your service provider is skilled in Scrum, get them to assist.

You will need to strategise and Plan this major overhaul of the Business. It would be a good decision to start with one Business unit as a pilot.

Adopting Scrum: The Roleplayers.

There are only 3 Scrum Roles. These roles are not hierarchical roles. These roles are discussed below:

Development Team.

The Scrum Development Team has five to nine members. They collaborate to run and Manage the Sprint. Strictly speaking this is not a Role, as each Developer presumes any of a number of Roles throughout the Project. The term “Developer” can be confusing. Although the individual Team member is involved in the Product Development, they add to the skills needed to complete the Product. For instance, in an IT Team, there could be a Business analyst. There could also be an Enterprise architect and a database Manager. All of these skills would be considered to be in the Development Team role.

We found these books great for finding out more information on Agile Scrum:

The Product Owner.

The Scrum Product Owner is somebody who understands what the Product should be. They play a major Role in the delivery of the Product. The ideal person will have a long and Valuable track Record with the Company. They will have an intimate understanding of how things Worked.

The Product Owner owns an Artefact called the Product Backlog. The Product Backlog includes all the information about the Product Requirements in order of priority. That priority is decided by the Product Owner and is reviewed on a continuous basis. The temptation for an Enterprise is to make a HOD (Head Of Department) the Product Owner. However this strengthens the old Organisational structure, which may be counter Productive. The perfect candidate needs to be a Manager from that Business system who presently reports to the HOD. It is crucial for the Product Owner to have authority over the Product. They should not just take instructions from the HOD.

The Scrum Master.

This is the most confusing Role for newcomers to Scrum. The assumption is that this is the new name for a Project Manager. However this is not true. The Scrum Master is both a Coach and a “Servant-Leader”. They Facilitate the Project and smooth the way for the Team by removing any obstacles. They also facilitate the Scrum Meetings, which are known as “Ceremonies”.

The Agile Scrum Master is the steward of the Scrum Values and Principles. They ensure that the Team follows these principles. As the keeper of Scrum knowledge they educate and advise everybody external to the Project on what the Team are doing and why.

The selection of a suitable Scrum Master for your Enterprise may need to be contracted to an external resource. The Scrum Master should have Scrum experience.

Adopting Scrum: Understanding the Sprint.

The Sprint is a short burst of energy, typically varying from 2 to 4 weeks. During this period the Team Designs, Builds, Tests and Delivers a working Product. This is a bare-bones, MVP (Minimum Viable Product). A quick, short Sprint brings satisfaction both to the Stakeholders and the Team. The Team will revel in the fact that they have delivered a working product. They will look to improve this product in the next Sprint.

The Work to be Done in the Sprint is chosen by the Development Team. This is done in consultation with the Product Owner and is based on what the team think they can achieve. They might under or over Estimate their abilities in the first Sprints. As they gain experience, they will improve their estimation accuracy for the next Sprint. The Sprint Backlog includes the Work to be Done and is drawn from the Product Backlog.

There are some cardinal rules to be observed during a Sprint:

• There is no outdoors disturbance (the Scrum Master ensures this).
• No Changes can be applied until the next Sprint. This is why Sprints are kept short. While Changes are invited, they ought to not impact the current Sprint.
• The Team is Self-Organising and decides how they will address the Work. Each Team member picks which Work they will do.

We found these books great for finding out more information on Agile Scrum:

Adopting Scrum: The Ceremonies

Scrum has clearly specified Meetings with time limits and required outputs. They are Facilitated by the Scrum Master, who is also the timekeeper. They ensure that the outcomes are accomplished in the minimum time and according to Scrum practice.

The Sprint Planning Meeting.

In the Sprint Planning Meeting, the Sprint Team meet the Product Owner. Based on the prioritised Product Backlog, the team choose which Work will be put into the Sprint Backlog. They also Estimate the time they will take for each item using an Estimation technique based on each Team member’s view of the complexity of the Work item. This Meeting can take up to a maximum of 8 hours. It can typically take much less time for a small Enterprise.

The Daily Scrum or Stand-Up Meeting.

The Daily Stand-Up Meeting is a lean version of Ricardo Semmler’s (of “Maverick” popularity) Stand-Up Meetings. The Scrum Master makes sure that it takes no more than 15 minute. They ensure that the meeting is held daily and at the same time and place. Each Team member advises what they completed in the last 24 hours, what they Plan to do today and what obstacles they came across (which the Scrum Master will try to remove). The Product Owner might be present as an observer and the Scrum Master exists as an active listener. They make sure that the Meeting does not overrun, while keeping in mind any challenges to be eliminated.

The Sprint Review.

The Sprint Review is a “Show and Tell” Meeting available to all. The Development Team explains what they accomplished during the Sprint and what the finished Product does. The completed Product is assessed according to Acceptance Criteria determined when the Work (or “User Story”) was initially Documented.

The Sprint Retrospective.

This is a “Lessons Learnt” Meeting, held at the end of the Sprint, which can take up to 4 hours. In this Meeting, Team members discuss what worked well, what might be improved and what practices they must improve or adopt for the next Sprint. This Meeting is invaluable to the Scrum Master, as the keeper of the processes and practices of Scrum.

We found these books great for finding out more information on Agile Scrum:

In Conclusion.

While we have not described everything about the content and Artefacts of Scrum, we have focused on the key Roles and activities. A Change to Scrum is not easy; it requires a considerable mental shift to adapt to the new way of Working. Adoption of Scrum in the Enterprise creates tensions and conflicts, but it does make everyone question why the Company exists and what contribution they must make if the Company is to survive. Any complacency should be replaced with enthusiasm and urgency, while barriers and silos will fall. The successful result will be a flat structure with high-performing empowered and engaged Workers, just what Jim Clifton said the Workplace of today needs.