Scrum is the most popular Agile approach and is being used in software companies worldwide. It is a simple but very effective management process for software development. Scrum can help project team to manage changes in scope of the project. Scrum iterations help the team to develop products in several incremental steps called Sprint (1 to 4 weeks) where the team can get feedback from users quickly. Scrum process is simple, clear and easy to learn, its “Daily Standup” meetings allow the team to share information effectively; the “Burndown chart” helps team members to check status easily.
The most common issue of project that uses Scrum is they do not follow the process but often skip some steps as they see fit. For example, team members may say to each other: “We already know what to do, why bother to update the sprint backlog? It is a waste of time.” Every process is defined for a purpose, if you do not follow it than you do not use Scrum accordingly. In that case, you may have problems but it is not because of Scrum.
Scrum is designed as a “lightweight development process” for small project with small teams (3 to 8 people) who work together in the same place. It is NOT design for larger project with large distributed team where members are located in several geographical areas and in different time zones. If your project is large or your team consists of a lot of people and many are not located in the same place, I suggest that you DO NOT use Scrum. Even it is possible to “scale up” as some consultants have suggested but I would not recommend it. Please remember that Scrum is not a “one size fits all” and scale up requires a lot of efforts, coordinations and unless you are experienced, do not use Scrum for something it is not designed for.
Scrum is excellent for Web project, for project that need fast update but NOT for critical systems such as medical devices, aviation and weapon, or defense systems. These projects require a lot of care because of high risks. They need to meet safety expectations such as requirements analysis, quality assurance, and design for reliability, qualification testing, project documentation, configuration management and traceability. These projects are better suited for traditional software lifecycle practices rather than Scrum.
Software company should have several development methodologies not just one. Project managers should select appropriate methods for each project accordingly. Scrum might not be correct method so company must chose wisely.
Scrum team
A person wrote to me: “I have been working as software developer for three years and just got promoted to project manager. Recently my company is adopting agile development (Scrum method). There is a rumor that they do not need project manager anymore and I could be laid-off. What can I do to maintain my position? Please advice.
Answer: The transition from traditional development to agile approach takes time and trainings to do it right. Everybody must understand their roles, responsibilities and be accounted for their works. This will require changes in the way the company operates from top to bottom where managers must understand which the “ideal situation” is and which is not. It is easy to say something like we do not need project manager anymore but in practice it does not happen that easily. Do not expect the transition from traditional development to agile approach to happen within few weeks or few months, there are many things your company must learn from this transition, and it will require a lot of efforts to do thing correctly. Personally, I think Scrum is a very good approach to software development. It differs from the traditional waterfall approach which requirements must be clear and understood. Scrum accepts that requirements may not be well defined up-front so they may change and the goal is to respond in a good manner to these changes by produce a working software incrementally to customers.
Basically, there are three roles in Scrum: Scrum Master, Product Owner, and Self-organized Team. Although there is no “Official” project manager position in Scrum, it does not mean you do not have a job. You could still learn to work as a Scrum Master to ensure that everyone follows the scrum rules; facilitate the meeting between the team and the product owner; and remove obstacles from the project so the team can focus to work on the product without disruption. The skills that you have learned as project manager is still applicable in Scrum method. For example, you can participate and facilitate the development of a Product Backlog of prioritized work to be done. The backlog is similar to the requirements specification of the traditional projects that you are familiar with. In Scrum, the Product Backlog is often jointly developed by the Product Owner and the Development Team but during the transition, they still need someone to manage it.
The project needs to have a Release Plan to deliver product across multiple Sprints with the highest priority first. The Release Plan is also similar to the traditional Project Schedule. It identifies product features and the corresponding time in which certain features will be delivered to customers. In Scrum, the Release Plan is jointly developed by the Product Owner and the Development Team but during the transition, they still need someone to facilitate and manage it.
Although, the Product Owners and the Development Team decide which features and related tasks to be done within each Sprint, somebody with more experience must come up with estimates as part of Sprint planning. Certain risks and issues must also be discussed during the Sprint Planning Meeting where the development, testing and release are determined and this is where your experience is needed.
When tasks are identified in the Sprint Planning Meeting, they are documented into the Sprint Backlog. The Sprint Backlog is similar to the Project Scope in the traditional development because it covers all activities that need to be completed within the Sprint.
The Sprint Backlog is updated at the Sprint Meeting where customers and users are invited to participate and it may need someone like you who can facilitate and manage the meeting.
In Scrum approach, there is a daily meeting where team members share their concerns and activities among the team, sometime they need someone to manage it until the team is really self-organized and be effective.
At the end of each Sprint, the team gets together and discusses what works and what did not work, this Retrospective meeting is similar to the traditional “lessons learned” or “Post mortem” review in traditional projects. Unless the team is experienced and effective, it may need someone to facilitate the retrospective meeting to make sure things work well.
If you compare the roles of traditional Project Manager with Scrum Master, you could see that there are certain tasks missing in Scrum Master because in an ideal situation, everything can be done by the Self-organized Team, assume that the team consists of experienced and well trained members. However in practice, it may not happen that way. The role of the Scrum Master could be expanding to cover some of these weaknesses. In Scrum approach, the process is facilitated by a Scrum Master whose primary responsibility is to guide and remove issues that prevent the team from meeting the goal. Although the Scrum Master is not the manager of the team (The team is self-organizing and self-managed) but in reality and during the transition, the Scrum Master could acts as a facilitator for issues resolution and communication and sometime must play a more active role in making sure that the team follows the Scrum process, facilitates collaboration, and acts as a “mentor” for the team.
Of course in Scrum, you do not act as a Project Manager, direct everything, manage everything and be responsible for everything. In Scrum everybody shares responsibility for the project’s success. However, in practice somebody must be concerned with the schedule, the cost and budget and I think as project manager, people would expect you to fulfill that role. My advice is to learn as much as possible about Scrum because with your experience, your company will need someone like you.