We normally do not associate companies in the private sector with bureaucracy and reserve that criticism mostly for governments and public sector organizations. But how many times have we waited for a response from a department which never came? How many times have we felt things have taken twice as long as they should have? How many times have we faced conflict situations because of poor or inadequate communication? These issues are not specific to a governmental organization but can happen, and do happen, even in the most modern, multinational companies.
Traditional reactions to such issues involve establishing lengthy processes, assigning responsibilities or scheduling ‘regular’ meetings. But many a times, what happens is that the extra processes and responsibilities just add to the confusion and the ‘regular’ meetings are rarely focused and stop happening after a few weeks.
Scrum, as a methodology, focuses on regular communication, singular accountability, flat hierarchy and dedicated team members working to a mutually agreed schedule. In its most simple form, a Scrum team is formed of members who will actually be working on a project, selected and led by the Scrum Master, working on mutually agreed tasks and timelines, meeting on a daily basis to complete deliverables piece by piece.
However, trying to implement Scrum in its most basic form to complex projects or large organizations where tasks are often complicated, rarely works. Numerous examples abound of large teams adopting Scrum only to discard it after a few weeks. The reason is that a methodology needs to provide the tools to everyone in the team to perform their tasks and not just stop at a 10,000 feet level.
This is where the Scrum methodology, as defined in the Guide to the Scrum Body of Knowledge (SBOK ™ Guide), comes to the rescue. It fleshes out the basic Scrum framework by suggesting practical techniques and processes by which the Scrum team can complete its tasks. Large and complex organizations can benefit from it because it uses familiar techniques but puts them in a highly Agile framework. Thus, a Scrum project initiated to reduce documentation (and consequently red tape), doesn’t just get team members from different parts of the organizations to attend daily meetings, but it empowers them to fulfill their roles by providing them practical methods and techniques. The SBOK™ Guide lays out ways to build the right environment and a key element of that is the buy in of the whole team towards the project vision. Thus, the project team becomes a self-motivated unit and is not just driven by the Scrum Master.
This buy-in supplemented with empowered Scrum team members is what, in the end, removes communication hurdles and makes organizations far more efficient than they would under traditional project management approaches.
Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM)
