Scrum is a software product development strategy that can be used for project management as well. It organizes people as a team to reach a common goal — creating a ready-for-market product. It is a widely used subset of Agile software development.
Scrum software development starts with a wish list of features — a.k.a. a product backlog. The team meets to discuss:
- The backlog.
- What still needs to be completed.
- How long it will take.
Scrum relies on an Agile software development concept called Sprints:
- Sprints are periods of time when software development is actually done.
- A Sprint usually lasts from one week to one month to complete an item from the backlog.
- The goal of each Sprint is to create a sellable product.
- Each Sprint ends with a Sprint review.
- Then the team chooses another piece of backlog to develop — which starts a new Sprint.
- Sprints continue until the project deadline or the project budget is spent.
In daily Scrums, teams meet to discuss their progress since the previous meeting and make plans for that day.
- The meetings should be brief — no longer than 15 minutes.
- Each team member needs to be present and prepared.
- The Scrum Master keeps the team focused on the goal.
It’s well known that creative people lose their creativity if asked to explain themselves while they are working. It’s the same with software. Programmers often have to work in an environment of one-sided transparency. These Agile systems, so often misapplied, demand that they provide humiliating visibility into their time and work, despite a lack of reciprocity. SCRUM can often feel make a talented developer feel like a beginner due to the unneeded pressure it often puts on developers. This is not limited only to developers but applies to IT Engineering equally.
Now, what is the solution?
SCRUM can be applied productively by approaching it differently. I like the approach of “SCRUMBAN”. This is a combination of SCRUM and KANBAN, using the principle of “bite” sized tasks which can be completed in a reasonable amount of time. This alone will not ease the anxiety of the SCRUM team.
The mindset behind SCRUM needs to be changed. The team has to buy into SCRUM as a collaborative tool to be used to highlight any potential snags and to allow your developers or engineers to pick tasks that are suited to their strengths. Take the focus away from the “story” and allow everyone to work together to achieve the goal. If someone is having trouble completing a task, it should never be a source of shame, but rather an opportunity to be mentored or to expand your knowledge. Truly great projects are never predictable and even though the business may like a tidy package, this is not always possible. Accept that some great ideas will come, but allow the freedom to find them.
Use SCRUM as a “fuzzy” indication of progress and as a guidance and aid tool. It can help more than it can hinder if done correctly. Used correctly, SCRUM can give business valuable insight into work progress and help answer the question “What did you do today?”.