Why SCRUM is not just for software development

The Agile Software Development movement has really taken off in the last few years with more and more tech companies building up talent and capabilities in this area.  For those who are unfamiliar with Agile, it is a set of methodologies, frameworks, policies and tools that was developed to accelerate the traditional software development cycle.  The traditional software development cycle typically adopts what we call a "waterfall" model, with the entire development process broken up into logical, distinct and sequential stages - starting from the collection of business requirements and moving on to design, development, testing and deployment.  As a result, teams are also organized in the same manner, with different specialists focusing on each stage of the development process.  The outcome of the traditional software development cycle is that more often than not, requirements collected at the start of the cycle become obsolete by the time the software is deployed, and the process is generally long and cumbersome, with everyone in the team working in their own little silos.  Agile, and specifically one implementation of agile - Scrum, is a method of project management that aims to break down these silos and increase both the speed and quality of execution.  While Scrum was conceived as a software development methodology, it actually contains many elements which could help build a high-performance team in any organization.  Below I will outline some key Scrum principles which you can apply in your team today.

1.  Separate the roles of the business and process owners

In Scrum, the roles of business and process owners are split - the Product Manager is the person ultimately responsible for specifying and prioritizing the business requirements and the Scrum Master is responsible for ensuring that the team applies the Scrum process in delivering the work.  This addresses a fundamental issue that many teams struggle with.  In a typical team, the Manager is responsible for setting the goal and specifying the tasks that needs to be done.  However, most managers tend to be so pre-occupied with achieving the goal that they neglect to ensure that the team follows the right process.  We are all familiar with the basic principles behind a high-performing team - ensuring that everyone has an equal voice, frequent and effective communication, personal ownership of work and outcome, continuous learning, fair allocation of work and recognition.  However, not many teams actually ensure that these principles are followed because the team leader - the manager in this case, is usually too pre-occupied with simply getting work done.  Assigning someone else in the team to take on the role of  "process facilitator" to ensure that basic principles behind good teamwork is adhered to, can make all the difference between a good team and a great team.  Furthermore, the "process facilitator" is a role that can be rotated among team members, which further builds up the culture of not only doing the right things, but doing things right.   

2.  There is no such thing as "everything is equally important"

As most high-achievers will tell you, a key ingredient for their success is focus. There is an old saying that goes, "if you chase two rabbits, both will escape".  It is true for hunting, and it is true for work.  I have lost count of the number of times I have seen managers overload their teams with work, and when asked what to prioritize, reply - "everything".  It may be true that "everything" is important, but some tasks are still more important than others.  Scrum forces Product Managers to articulate what are the most important priorities in the Product Backlog, and the team collectively decides how many of those items can be tackled within a given time period.  The key here is that priorities are organized in a list starting from the most important to the least, and there are no two items that can be the same importance.  In the same way, it is essential that Managers learn to work with their teams in prioritizing work and ensuring that the team stays focused on the tasks that are truly the "most important".     

3.  Time-box everything and clearly define "done"

Another term that you will hear frequently in Scrum meetings is "time-boxing".  The idea of time-boxing is not simply setting deadlines for work.  When you create a time-box, you are establishing a regular cadence for how you plan, execute and review work.  If everyone knows there are only 2 hours for the planning meeting and this will be strictly adhered to - people will be more focused and stay on topic.  In fact, the "daily scrum meeting" is typically only 15 minutes long.  You talk about what you are working on, clarify interdependencies and flag out potential roadblocks that the Scrum Master or Product Owner must resolve.  Similarly, if everyone knows there is a work review meeting at the end of every week, they will organize their tasks and deliverables so that they can execute them by the end of the week.  Long range plans (analogous to "Epics" in Scrum) should then be broken down into "bite-sizes" which can be completed within a specified work cycle (weekly or biweekly).  

The other important principle for Scrum is to always have a clear definition for what is "done".  Many managers get caught up in the rush of assigning work that they rarely clearly communicate (much less actually write down), what they would define as "work done".  Have you ever been in a situation where you thought you knew what the boss wanted, only to find out only much later that you were totally off the mark?  It happens all the time in organizations because managers do not spend the time they should to clearly define "doneness".  In fact, part of the problem is that managers sometimes do not even know how to define "done" when they first assigned the work.  It is therefore even more crucial that managers figure that out before sending the team on a wild goose chase that ends in massive rework.  

Conclusion

The principles behind Scrum should not be new to any team leader.  Scrum merely provides a structured framework in which to execute these principles. Software development teams follow the Scrum methodology because their work is highly complex, interdependent and fast-paced.  If it works for such teams, it can certainly work for yours.  If you are a team leader managing complex projects, take some time to learn about Scrum and think about how you can apply it to your organization.  It will certainly be well worth the time.