What is Scrum?

Scrum helps people and teams deliver value incrementally in a collaborative manner. If you are just getting started, think of it as a way to get work done as a team in small pieces at a time, with experimentation and feedback loops along the way. (from Scrum.org )

Many people consider Scrum and Agile to be almost the same thing. When a company wants to do Agile software development, they often start with the Scrum framework. With four decades of development experience, I will confess to some bias against Scrum. Scrum will probably help most teams that are intentionally following the waterfall method but want to improve. The best teams I have been a part of were not Scrum teams. Those teams may have used some of the practices Scrum recommends, but ignored others that would otherwise introduce wasted time. The best teams know they exist to deliver value, they don’t exist to dogmatically follow a set of rules. Scrum is a good way to start being Agile, but teams can discover what works best for themselves as they mature which may include eliminating all of the Scrum rituals.

Like the concept of Agile in general, Scrum advocates delivering software in small increments, measuring what works, adjusting your process based on what you have learned, and continually trying to improve your process of delivery.

Why adopt Scrum?

Teams usually adopt Scrum from a desire to methodically improve their development process. One goal is often a more predictable and reliable cadence of software delivery.

Why not adopt Scrum?

When development processes are flowing smoothly and the team prefers the process already in place.

As you read through the considerations below, keep in mind that your aspects of your context that although some elements in your context may make the adoption of Scrum more difficult, this does not mean you shouldn’t adopt Scrum. It may mean that you just need to change your context to help make the Scrum adoption more successful.

How does your context affect the probability that Scrum will add value to your process?

*1. How does the Organizational Structure in your context impact the probability that Scrum will add value to your process?

Many teams struggle to adopt Scrum because it impacts the way the organization used to work in a waterfall development environment. In waterfall, developers often gathered a lot of requirements from product owners at the start of the project, provided an estimate of the cost to deliver, and then were not heard from by the product owners for many months. Agile and Scrum processes require more frequent input from product owners. A solid cost estimate is rarely provided up front, and the gathering of requirements is done all during the course of development. Product owners therefore need to be a lot more involved making daily decisions about how the software will work, along with prioritizing what they feel is most important. In short, the development team can’t adopt Scrum very well if the product owners don’t also adjust their way of working.

*2. How does the Development Team Culture in your context impact the probability that Scrum will add value to your process?

Again, going from waterfall to Scrum is a significant change, especially for development teams. If team members are “set in their ways”, you can expect that resistance to change to make Scrum adoption very difficult. If the team feels they are tasked with similar process changes every few years which always fail, then you can also expect resistance. If it is the team members advocating for Scrum, then you can certainly expect a greater chance of success, providing the impact on the rest of the organization can be handled. Like many changes you might try to introduce, a poor team culture and disgruntled team members will make the change more difficult and you should probably consider how to improve team morale first.

3. How does the Hiring Process in your context impact the probability that Scrum will add value to your process?

The hiring process of your organization may have some impact on the value Scrum may bring to your team. Scrum is more team-focused development than waterfall and demands more interactions between individuals, therefore you want to hire individuals that can interact with others well; and it is probably beneficial to have the potential team members interview the person that is to become part of their team.

*4. How does the Team Composition in your context impact the probability that Scrum will add value to your process?

Scrum is often an excellent framework for teams comprised of less experienced developers because it gives them good guidance and boundaries in which to get started. There is so much for new developers to learn. They need to learn programming languages, tools, frameworks, business domain knowledge, source code management, deployment tools, how to work on a team, project management and more. Scrum provides good answers to a lot of questions and helps them focus on fewer things as they get started. Scrum can also be helpful when there are several new team members because daily standups help team members know one another and learn about processes; retrospectives help new team members understand why processes are they way they are, and a regular cadence including discussions of priorities and focusing on limited work per sprint help new team members integrate more quickly.
Scrum may be less valuable for mature teams and teams of experienced developers. When the process is working well frequent retrospectives become less valuable. Daily standups may be unnecessary. A time-boxed sprint every two weeks may feel artificial and cause more problems than it is worth, especially for teams that adopt a kanban flow to managing work to be done.
Scrum, and most all processes, often struggle with deciding what people are part of the team. Are the team members those at every daily standup, or those at the retrospectives? Are product owners team members? What about quality assurance personnel, or auditors, or DBAs, security team personnel?

5. How does the Training Provided on Code in your context impact the probability that Scrum will add value to your process?

The training your company provides on code has no impact on the value Scrum may bring to your team.

6. How does the Training Provided on ‘Our Ways of Doing Things’ in your context impact the probability that Scrum will add value to your process?

The training your company provides on your way of doing things has little impact on the value Scrum may bring to your team. Mostly you probably want to provide some training of your Scrum process to new team members as they join.

7. How does the Environment in your context impact the probability that Scrum will add value to your process?

Your environment may have some impact on the value Scrum may bring to your team. Teams need to meet to communicate, so rooms without distractions, or technologies such as Zoom that everyone can use well are important. Visible boards to see the status of items, the backlogs, and understand what everyone is working on are very beneficial.

8. How does the Project Selection in your context impact the probability that Scrum will add value to your process?

How projects are selected probably has little impact on the value Scrum may bring to your team, provided that the product owners are equally committed to utilizing the Scrum process for delivery of the software. When transitioning from waterfall to Scrum, teams should prioritize projects with willing product owners. Perhaps also look for projects that can deployed incrementally to provide value to end users.

*9. How does the Solution Purpose in your context impact the probability that Scrum will add value to your process?

The solution purpose should significantly impact the utilization of Scrum for your team. This is not to imply that Scrum is good for some solution purposes such as “core ERP Business solutions” and bad for others such as “an internal web site for our pickleball league”. Rather it is to say that the Scrum processes can, and probably should, be different for these different types of solutions. They could have different sprint lengths, different frequency of standups or retrospectives, different types of team members, different backlog and project management tools, deployment frequency, and more. Scrum should be used to evolve the process on each team/project toward what works best for that team and project. Therefore we should expect Scrum to look different at one organization from another, as well as from one team to another within an organization.
Scrum can be helpful for solutions of most any purpose, but has much less value when projects have just a single developer; or the project is going to produce a result, such as a report or dataset, then never be worked on again, because it may be a waste of time to attempt to improve the process on small projects that you know will be obsolete soon.

*10. How do the Application Architecture Priorities in your context impact the probability that Scrum will add value to your process?

Compared to other Agile approaches, Scrum offers no improvement to your chance of success based on your application’s architectural priorities. But compared to waterfall it probably offers significant improvements if you priorities are to deliver some working software more quickly. Some people believe that waterfall is best when your application requires outstanding quality and perfection, perhaps because your team is at NASA and your are writing software that will land a rover on Mars. Certainly, you will only deliver to “production” once, but agile processes like Scrum can still be used to develop all of the software into the testing environments, before it is finally all deployed in a single delivery to “production” at launch.

11. How do the Security Demands in your context impact the probability that Scrum will add value to your process?

The security demands of your solution have little impact on the value Scrum may bring to your team.

*12. How do the Requirements, Features, and Priorities in your context impact the probability that Scrum will add value to your process?

As mentioned previously, Scrum and most agile processes expect a lot of product owner collaboration to work well. That collaboration is used to gather requirements as needed, select features to work on each sprint, and set priorities based on the ROI they can provide. Perhaps it can be done well without the product owner by someone else that has a good idea of what the product owner wants, but lack of such input will likely cause a return toward waterfall methods.

13. How do the Regulations in your context impact the probability that Scrum will add value to your process?

Your regulations and auditing requirements probably have no impact on the value Scrum may bring to your team. However, as your team adopts Scrum you may need to work with some auditors to develop new auditing policies for your Scrum development processes.

*14. How does Who Decides What To Do in your context impact the probability that Scrum will add value to your process?

The people that make the daily decisions about what a team and team members should do is greatly affected by Scrum, or any agile process, when compared to waterfall. Decisions need to be made more frequently and by those that know the work best to avoid time being wasted. Producing a software feature, at the same time as developing a software product, at the same time as making improvements to development processes, at the same time as trying to improve DevOps, requires the ability to consider dozens of factors about the most valuable use of time of team members. That decision should not fall to a product owner, or a project manager, or a Scrum master, or individual developer. Ideally stakeholders can work together to guide decisions, otherwise a team can become unbalanced. For example, they may focus on just delivering features as fast as they can, when they could eventually deliver them faster if they took time for automating builds, taking a few days for training, or fixing some bugs that consistently consume time. Conversely, a development team may seek to build the optimal framework and devops automation prior to delivering many features and may waste a lot of valuable time building robustness that is vastly under-utilized.

*15. How does Project Management in your context impact the probability that Scrum will add value to your process?

Project management tools and processes can make a significant impact on your success with Scrum. Good backlog management tools and task boards easily accessible by all stakeholders greatly facilitate communication in timely manner so that good decisions can be made quickly when needed.

*16. How do the Quality Processes in your context impact the probability that Scrum will add value to your process?

The quality processes you have in place may be impacted by the adoption of Scrum or any agile process if you currently follow a waterfall process. Most waterfall processes include little quality assurance other than reviews, but use extensive testing after the majority of the code is written. Agile approaches like Scrum expect testing to occur right away as code becomes testable early in the project. Many agile practices support quality processes such as writing tests and testable requirements before writing code, or having quality assurance team members sit with developers as they code. Of course unit tests, integration tests, static code analysis, and automated deploys to quality assurance environments are often employed. In short, adopting agile processes facilitates the adoption of many new quality processes.

*17. How does the Architecture Forecasting in your context impact the probability that Scrum will add value to your process?

The way a team plans and implements architectural changes, such as rewriting a web application to use REST on the backend, probably changes significantly with a transition from waterfall to Scrum or any agile process. In waterfall, an architecture team may mandate the architecture to be used on a project, or may create a project the singular goal of changing the architecture. Agile teams usually gradually migrate from one architecture to another across the deployment of many features and projects. So the impact of this element goes both ways. How your organization currently evolves the architecture is probably going to impact your ability to use Scrum or agile, but also the implementation of Scrum or agile is going to affect how your teams evolve architectures.

*18. How do your DevOps in your context impact the probability that Scrum will add value to your process?

Like architectural forecasting, your current DevOps processes are likely to impact or hinder your ability to do Scrum, and your implementation of Scrum is likely to cause significant changes to your DevOps processes if it is to be successful. Delivering working software frequently is a key part of the definition of Agile. Software doesn’t necessarily need to be delivered to production for a team to be agile. The software could be delivered to a test environment where product owners can do enough evaluation to make a really good assessment about it meeting their production needs. If changes can’t be delivered until they have gone through months of testing environments and integrations, the value gained from an agile process is greatly curtailed, especially in the initial transition to Scrum. Therefore, the adoption of Scrum will most likely include the demand to improve DevOps so that deployments can be made swiftly and often.
As with any consideration though, many teams use agile processes yet deliver working solutions to customers only once or twice per year. They can do this by delivering more frequently to an internal quality assurance team or product owner liaison who can evaluate and approve the changes more frequently. All those changes over the months usually accumulate, having passed all testing, and are bundled together in a product released annually.

19. How does the Architecture in your context impact the probability that Scrum will add value to your process?

The architecture of your solution has little impact on the value Scrum may bring to your team.

20. How does the Code in your context impact the probability that Scrum will add value to your process?

The coding languages and tools in your solution has little impact on the value Scrum may bring to your team.

21. How does the Code Quality in your context impact the probability that Scrum will add value to your process?

The quality of the code in your solution has little impact on the value Scrum may bring to your team. However, Scrum and many of the agile practices can help your team improve the code quality, especially with more frequent deployments which provides quicker feedback about problems.

22. How does the Application Quality in your context impact the probability that Scrum will add value to your process?

The current quality of your application has little impact on the value Scrum may bring to your team.

23. How does the Deployment Environment in your context impact the probability that Scrum will add value to your process?

The deployment environment of your solution has little impact on the value Scrum may bring to your team. It may impact how frequently you can deploy to “production”, but most Scrum and Agile teams will have a test environment they can deploy to more frequently for testing before delivering the accumulated changes in a single package to production. It is generally easier to deploy frequently to production when production is a web site. Deployments to phone App Stores can be a little more difficult, as can deployments of desktop applications. Deployments to some environments, such as code embedded into hardware happens once. Some software is purchased and downloaded by customers so deployments, aka, new versions of the software, are only made available periodically.

24. How does the Product Training in your context impact the probability that Scrum will add value to your process?

The product training your organization provides for your product has little impact on the value Scrum may bring to your team. But if frequent product updates are deployed as part of your Scrum process, you may need to re-evaluate how training is provided as features change more frequently.

25. How does the Support in your context impact the probability that Scrum will add value to your process?

The support your organization provides for your product has little impact on the value Scrum may bring to your team. But if frequent product updates are deployed as part of your Scrum process, you may need to re-evaluate how support is provided as features change more frequently.

What does ChatGPT think?

(May 2023)Hey ChatGPT: What are good contexts and bad contexts using SCRUM for software development?

Scrum is a popular Agile framework for software development that emphasizes iterative, incremental delivery of working software. While Scrum can be effective in many contexts, there are certain situations where it may not be the best choice. Here are some examples:

Good contexts for using Scrum:

1. Complex projects: Scrum can be particularly effective for complex software projects with many moving parts, as it provides a framework for breaking the work into manageable chunks and delivering working software at regular intervals.
2. Cross-functional teams: Scrum is designed to work well with cross-functional teams, where team members have different areas of expertise. This can help ensure that all aspects of the project are covered and that everyone is working together towards a common goal.
3. Dynamic environments: Scrum is well-suited to environments where requirements are likely to change frequently or where there is a high degree of uncertainty. Its iterative approach allows teams to adapt to changing circumstances and make course corrections as needed.

Bad contexts for using Scrum:

1. Small projects: Scrum may not be necessary for very small software projects, where the requirements are clear and straightforward. In these cases, simpler development frameworks may be more appropriate.
2. Strict, inflexible deadlines: Scrum relies on iterative development and continuous improvement, which may not be feasible in situations where there is a strict, inflexible deadline. In these cases, other project management methodologies may be more appropriate.
3. Lack of team buy-in: Scrum requires a high degree of collaboration and team buy-in to be effective. If team members are not committed to the process or are resistant to change, it may be difficult to implement Scrum effectively.

Overall, Scrum can be an effective framework for software development in many contexts, but it’s important to consider the specific circumstances of each project before deciding to use it. Teams should be willing to embrace the iterative, collaborative approach that Scrum requires in order to get the most out of it.