“You can’t be Agile with Scrum…”
Are you serious?! — Episode 17 part 2/2.
Before I’ll run through all 12 principles, let’s first rewind all the way back to 2001, at a ski resort in the Wasatch mountains of Utah, where representatives from various development frameworks, including the authors of the Scrum Guide Ken Schwaber and Jeff Sutherland, found common ground. They defined what values and principles they all shared.
“what emerged from this meeting was symbolic — a Manifesto for Agile Software Development” — History: The Agile Manifesto
The Manifesto revolved around “the mushy stuff” of values and principles. It truly is
“ — about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset” — History: The Agile Manifesto
The Manifesto too is much more nuanced than perhaps many Agilists perhaps preach.
“We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. “— History: The Agile Manifesto
This history, back then referring to Scrum as ‘SCRUM’ and it being an Agile Methodology, writes too that
“Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both” — History: The Agile Manifesto
And here I will argue that those saying “You can’t be Agile with Scrum…” are maybe a bit ignorant too… or if that isn’t the case, then perhaps maybe I am. Maybe we are both or neither. I am engaging in this writing exercise to figure this out.
I read up on a quote by Ken Schwaber, that seems fitting.
“People often don’t view Scrum as a tool they can use to become Agile. They view Scrum as another methodology that they have to layer over their real, unchanging work. Getting a release out the door is all that counts. This approach is simple, because no real change is required. Unfortunately, none of the anticipated benefits accrue.” —Methodology Façade Pattern, by Ken Schwaber.
Now, I am not an author of either Scrum or the Agile Manifesto. But still, I will do the best job I can in trying to explain how each principle of the Manifesto is embedded too in Scrum, some perhaps more clearly than others. That said, I do believe that these principles from the Manifesto are paramount for Scrum Teams. By no means do I imply that with Scrum, these aren’t valuable… on the contrary. They are reinforcing. They go hand-in-hand. And here is how:
Principles behind the Agile Manifesto:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Although the Manifesto explicitly mentions the customer, this customer is indeed not once referred to in the Scrum Guide. Thus, one might argue, how can Scrum be about satisfying the customer?! Neither is the term user used in this context. It is important to understand that, with Scrum, they are either embedded in the team or referred to as Stakeholders, who routinely collaborate with the team during Reviews.
This principle states that customer satisfaction is achieved through the continuous delivery of valuable software. Now although Scrum isn’t solely about software, but about developing, delivering, and sustaining complex products in general, this too could apply to the software.
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — The Scrum Guide
Scrum Teams do this early and continuously. Every day they focus on what is most valuable that day. Even after a very first Sprint they deliver a potentially releasable working increment (call it MVP if you will) and continue to do so each Sprint. It too is a common myth that release has to be done at the end of a Sprint. They may deliver, demo or release whenever it makes sense.
“Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.” — The Scrum Guide
So if customers are indeed in play, and they are (as the Manifesto assumes) satisfied through early and continuous delivery of valuable software, then surely this is the case when Scrum is used to develop software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Scrum is all about adaptability. It’s one of the three pillars alongside transparency and inspection. Responding to changing requirements requires flexibility and adaptability from a team.
“The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive.” — The Scrum Guide
and
“The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”— The Scrum Guide
Should this imply a Scrum Team welcomes change… Heck yes! if indeed it is valuable. What is valuable also includes that which benefits a customer’s competitive advantage.
During the Sprint Review, together with Stakeholders, which could include representatives of the customer, they:
“Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next”. — The Scrum Guide
Is this limited to the Review? no. With Scrum, the work that a Development Team does during a Sprint is not fixed upfront. Yes, they do create a Forecast at the start of each Sprint on what they will likely work on next, but this may change as the Sprint progresses.
[During a Sprint] “Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” — The Scrum Guide
and,
“As new work is required, the Development Team adds it to the Sprint Backlog.” — The Scrum Guide
In fact, each day the Development team might adapt:
“The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.” — The Scrum Guide
They do work towards an overarching Sprint Goal as Scrum enables adaptability yet values focus, and even that Goal may be dropped in the rare event the Scrum team needs to adapt to rare events.
Scrum also has a person dedicated to focusing on what would work best to benefit a customer’s advantage, which by Scrum terms is defined as ‘maximizing value’.
“The Product Owner is responsible for maximizing the value.” — The Scrum Guide
So all-in-all with Scrum there surely is continuous focus and adaptation to what works best for a customer’s competitive advantage at any given moment in time during development.
3. Deliver working software frequently, from a a couple of weeks to a couple of months, with a preference to the shorter timescale.
Although the continuous delivery of valuable software is already covered in the first principle, this one emphasizes the preference of delivery in shorter timescales. Scrum teams can demo or deliver as often as they want. They will do so at least once every Sprint. The Sprint’s timebox is capped to one month, though may be shorter. There is no restriction as to how short a Sprint could be.
I will agree that Scrum doesn’t prescribe a preference for shorter timescales. Scrum is all about quality first. Faster is not better, better is better. As teams become more routined, their Definitions of Done will include more stringent criteria. They generally will become better and deliver quality and value faster. Follow me?
Scrum teams do however work towards optimizing their flexibility and productivity for example by “maximizing opportunities for feedback” -SG. More frequent deliveries generally increase opportunities for feedback. One only needs to scan through the Scrum Developer Glossary to explore practices Scrum Developers prefer. This also reveals why many Scrum Teams have a preference for Continuous Integration, Delivery, and Deployment and why those practices are being instructed in Scrum Developer training.
That said, Scrum does indeed not prescribe it as a ‘preference’ in such bold terms. This is, I imagine because experience has revealed we should be conservative about emphasizing faster delivery or increasing velocity for the sake speed itself. It has resulted in numerous bad practices and anti-patterns.
So, in short, everything the team strives towards (optimizing flexibility, productivity, maximizing feedback opportunities) backs up that indeed there is a preference for shorter timescales. This preference can also be observed through the teachings and appliance of related to Scrum Developer practices.
The Scrum Guide tells us that “Scrum has been used extensively, worldwide, to:”
“Release products and enhancements, as frequently as many times per day;” — The Scrum Guide
4. Business people and developers must work together daily throughout the project.
This principle bugs me a little as it makes a clear distinction between ‘Business People’ and ‘Developers’. Who exactly are these ‘Business People’ and why aren’t developers ‘Business People’ too? Surely developers develop business too? What defines a business person if not a person doing business? Their ability to ‘suit up’?
Perhaps that’s a topic for another day.
This principle from Manifesto doesn’t imply that all business people should work together with all developers daily, just that there is a daily collaboration between people from ‘the business’ and software developers.
Well, to start, one must understand that in Scrum ‘Developers’ include anyone contributing to the development of a Product or engaging in complex work. They are not just Software Developers. Development Teams are cross-functional. So with Scrum for Software Development, they will consist of ‘Business People’ and ‘Software Developers’ alike. They are all simply called ‘Developer’. This team indeed collaborates daily.
That said, not all these ‘business people’ might contribute directly to development. They might be involved or invested, but not committed. In this case, Scrum will refer to them as ‘Stakeholders’. Again, Scrum is a bit more reserved when it comes to the involvement of Stakeholders. Stakeholders are involved at least once per Sprint during a Sprint Review, though this doesn’t limit the Scrum Team from engaging with them more often. Scrum doesn’t say they must work together with Stakeholders on a daily basis, only as often as makes sense. These interactions must not impede the team’s ability to focus. At least the Product Owner and Scrum Master will generally engage with them frequently during a Sprint, and they generally do this daily.
“Agile approaches today include various specialized roles, such as “Product Owner” (or the XP “Customer”)” -Ron Jeffries (one of the three founders of XP)
As for working together with the ‘customer’ daily… let’s see where the role of Product Owner emerged from. It’s the on-site customer from XP. So in a way the customer is already on the team.
So in short, business people are embedded in the Scrum Team and they should work together daily. Stakeholders can be involved when and if needed and will be involved at least sprintly.
But really with a true cross-functional Scrum team, we should shrug the myth that ‘developer’ equals Software Developer (as how it is defined back when the Manifesto was written). Scrum has evolved to where the Developer is fully inclusive (including ‘people from the business’), meaning everyone needed to resolve work to develop and deliver products work together in a team daily.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This statement is about enabling and trusting the team.
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — The Scrum Guide
These Scrum Teams are trusted to work out how to not only improve the product or themselves, but also their own work environment. What’s more, the Development Team has complete autonomy over how the work gets done.
“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” — The Scrum Guide
Scrum has a person dedicated to giving them the support they need. The Scrum Master. The Scrum Master is a servant-leader to the team. It’s the team’s facilitator.
“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint” — The Scrum Guide
That said,
“No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;” — The Scrum Guide
Scrum Teams work continuously together to building a safe and trusting environment. It has its own set of values.
“When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” — The Scrum Guide
Another major motivator is that the Development Team itself gets to directly demo and deliver its work at regular intervals. They get to present their work often and naturally celebrate awesome results together.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The Scrum Teams gets together as a team at least during its regular events, to inspect the shared artifacts (be it the product itself, the Increment being worked on, the Product Backlog or Sprint Backlog). There is only one version of each being worked on together.
“Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.” — The Scrum Guide
Scrum is all about creating transparency. I’m aware that this is a bit of a vague term. It’s all about creating a shared and common understanding of what is being seen.
Scrum teams collaborate and interoperate.
“The entire Scrum Team collaborates on understanding the work of the Sprint.” — The Scrum Guide
All the events and artifacts in Scrum are there to promote direct collaboration. The Scrum Master will work to improve these interactions.
“The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” — The Scrum Guide
Scrum doesn’t indeed prescribe face-to-face conversations in such clear terms. I’ll concede to that. Scrum will leave it up to the teams itself to figure out how to best collaborate. Scrum is preferring ‘collaboration’ and ‘working together’ over ‘meeting’ and ‘conversation’. Sure, one might get nit-picky over the distinctions in the terminology used. With Scrum, it might be facetime to facetime too. Scrum doesn’t prescribe how teams should collaborate, only that they should work on improving the way they collaborate. The latter is generally done by continuously enabling/facilitating better ways to work together, which surely includes face-to-face, hands-on collaborative sessions. Oh, the harmony.
7. Working software is the primary measure of progress.
So how is progress measured in Scrum?
“Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide
Here the Scrum Guide explicitly tells us that, although various projective practices and the forecasting of progress have proven useful, the importance of empiricism is valued first and foremost. Again, this term may sound a bit vague. One of its pillars is inspection. Inspection is primarily done on the Increment itself.
“An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint.” — The Scrum Guide
The end of the Sprint starts with the Sprint Review at which occurs “the presentation of the Increment”- SG.
“At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review.” — The Scrum Guide
With Scrum, the best way to inspect progress is through attending the Sprint Review, during which progress on the actual Product (Increment) is made transparent. Scrum makes sure inspection occurs throughout Development.
“If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.” — The Scrum Guide
This doesn’t exclude the use of other projective practices or progress reports, but neither does this principle in the manifesto. Inspecting the Increment in Scrum is the primary measure of progress, its events and artifacts are there to ensure constant inspection and adaptation of that increment and to make sure that the Backlogs reflect that (are made transparent). Scrum Teams also have commonly defined ‘Definitions of Done’, to benefit both transparency and inspection of the Increment.
So are we all on board with this?
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
I am not sure if there is any significance about the terms ‘sponsors’ and ‘users’ being used, rather then the term ‘customer’ as earlier on. Again, Scrum doesn’t make this distinction. Scrum is all about join-team operations where sponsorship and customer representation is embedded. So how is this team able to maintain a constant pace with Scrum? How is development with Scrum sustainable?
Scrum promotes sustainability in various ways. A consistent routine surely contributes (consistency generally promotes sustainability), but that in itself is not guaranteed. This is mainly achieved through the reinforcement of various elements of Scrum.
For starters, it's by enabling the team to self-organize, and for the Development team to have full ownership of how to do their work. The Development team pulls in work and is also involved in the formulation of the Sprint Goal.
Second, it’s by having someone (the Scrum Master) dedicated to making sure the team is properly facilitated and that anything that impedes the teams gets resolved.
Third, it’s through the promotion of empiricism and that only the past performance of the team can be used to make projections.
Fourth, a Scrum team only commits to what it reasonably can. It isn’t held accountable for finishing a fixed amount of scope in a Sprint, not even for achieving a Sprint Goal. The Scrum Team will honor the Sprint cadence regardless of the achievement of a Sprint Goal or the completion of all forecasted work. It is perfectly fine if the Increment at the end of a Sprint only contains a step towards that goal as long as the team remains aligned on what that is.
Fifth, each Sprint the team will work on improving their work environment. It enables regular Retrospectives so the team can discuss anything that might get in the way of sustainable productivity, flexibility, and creativity. During this Retro, they too will work towards making the work more enjoyable. A very important word in the guide that is paramount to enabling sustainability.
And the last element I wish to mention, which is certainly not least, is Scrum’s Values. Values like openness, focus, and respect, but also the commitment to support one another and the courage to speak up when sustainability is at risk.
So sure, the team does work on complex challenges. They have ambitious goals and work on tough tasks. But they do this together. Yes, all these interactions can be intense, but they are also a lifeline.
Scrum promotes a sustainable pace, but teams will struggle with maintaining it, as too will be the case with Agile processes. The dynamic environment Scrum Teams work in, put sustainability at risk by default. So all the aforementioned have to be upheld in Scrum, and that in itself is a challenging and perhaps a daring task. It is easy to understand how many teams that start to Scrum are struggling with this as they are not yet capable of upholding all of this. But perhaps that is also why even the Manifesto is somewhat conservative by using the terms ‘promote’ and ‘should’ rather than saying they ‘are’ or ‘have to be’.
All this said I do personally think that Scrum should be a bit more explicit in its wording at times. Something bold like “The Development Team should work at a sustainable pace which the team can maintain indefinitely” would make for a nice addition to the Scrum Guide, if only to emphasize what it already promotes.
9. Continuous attention to technical excellence and good design enhances agility.
I love this one.
With Scrum, during the Sprint:
“Quality goals do not decrease” — The Scrum Guide
During each Retrospective:
“Scrum Team plans ways to increase product quality” — The Scrum Guide
Quality is paramount in Scrum.
“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” — The Scrum Guide
Scrum Teams develop and enhance products. But continuous attention to quality doesn’t necessarily imply attention to technical excellence and good design, although the Retrospectives, Definitions of Done and the continuous alignment surely promote it. Scrum Teams do indeed not only enhance the product but also their work processes, work environment, practices, and tools!
“Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.” — The Scrum Guide
Scrum also promotes enhancement through continuous knowledge transfer:
“Scrum proved especially effective in iterative and incremental knowledge transfer.” — The Scrum Guide
I’ve engaged in several discussions where it has been argued that the incremental nature of Scrum gets in the way of ‘good design’ by those who haven’t yet practiced it. If this is the case then the same can be said of Agile in general as that too is incremental by nature. Practise shows that design flourishes when reinforced by such frequent iterations and continuous feedback and validation from users and other cross-functional individuals.
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” — The Scrum Guide
These generally include (but are not limited to) technical and design competencies being improved over time. And so I can summarise that Scrum Teams uphold and continuously increase quality, their knowledge, competencies, skills, tools, environment and so on. Awesome huh!
Does this enhance agility? It sure does. The Scrum Team is becoming increasingly creative, flexible and adaptive.
“These strengths continue operating in single, several, many, and networks of teams” — The Scrum Guide
10. Simplicity — the art of maximizing the amount of work not done — is essential.
In an online publication, Ken Schwaber explains that “Scrum is simple, just use it as is”. Here he too explains that Scrum is based on Lean principles.
Scrum Teams operate in a complex environment on complex challenges. Scrum is laid out so as to minimize complexities where possible. This starts by being a lightweight framework. Its roles, artifacts and events are “simple to understand”. But within the definitions of Scrum, we can find more clues on how Scrum is designed to reduce complexities such as the limitation of team size.
“Large Development Teams generate too much complexity for an empirical process to be useful.” — The Scrum Guide.
Next, Scrum emphasizes the need for regularity and consistency as these too reduce complexity. The duration of this cycle is also limited.
“When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase.” — The Scrum Guide.
Continuous alignment and direct collaboration should further reduce the need for documentation and disseminate meetings and all the administrative work related to it. Take for example the Daily Scrum.
“The Daily Scrum is held at the same time and place each day to reduce complexity.” — The Scrum Guide.
Also, Scrum Teams are designed to
“have all competencies needed to accomplish the work without depending on others not part of the team.” — The Scrum Guide.
Scrum is also reserved about engaging in too much projective work as it both boldly and sanely states that:
“In complex environments, what will happen is unknown.” — The Scrum Guide.
Complexity is further reduced by keeping all that is known to be needed in a single document.
“It is the single source of requirements for any changes to be made to the product.” — The Scrum Guide.
Few roles and rules, a small team, direct collaboration, little to none dependencies, regularity, sane expectations, and focus. This enables teams to calmly construct approaches.
Scrum patiently withholds any specification on how the work is to be done to the last responsible moment and generally occurs during the Sprint in which the work is done.
“Scrum employs an iterative, incremental approach to optimize predictability and control risk.” — The Scrum Guide.
A Development Team will remain focussed on that which is most valuable to do over a short period in time. The work done on an Increment is generally small and simple enough so it can be easily inspected and reviewed. They themselves organize their work during the Sprint.
“The increment is a step toward a vision or goal.” — The Scrum Guide.
By taking these small steps in a series of short Sprints, rather then in big leaps, progress remains transparent.
A Scrum Team, always inspecting and adapting, will reduce the risk of straying off course. They are always quickly maneuvering in the right direction. If they stray, they stray only little and they discover this at the earliest possible moment. Whereas with traditional projects teams may not discover this until the very end when the budget is spent and the deadline has struck.
The concept of MVP has become rather popular and is highly related to this principle. With Scrum, each Sprint delivers an MVP called an Increment. During each Sprint, including the first:
“a “Done”, useable, and potentially releasable product Increment is created.” — The Scrum Guide.
Does this imply Scrum Teams only do the very least that is required? Nope. Often they will try to outdo themselves and try to exceed expectations too. But they are only able to do so because they remain focussed on delivering value without engaging in wasteful practices.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
I’ve often heard the assumption that ‘Scrum’ prescribes how teams are organized. Sure, I agree that this is indeed the case to some extend. It’s roles, events and artifacts are part of how a Scrum Team is organized. Paradoxically perhaps, this organization promotes self-organization.
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” — The Scrum Guide
Now they are organized this way because:
“They collaborate and interoperate through sophisticated development architectures and target release environments.” — The Scrum Guide
I’ve already mentioned and quoted that the Development Team is structured and empowered by the organization to organize and manage their own work. Not even the Scrum Master can direct them in this, though he should support and facilitate them. A Scrum Team is also at liberty to determine how it organizes its Backlogs (containing designs and requirements).
It is often falsely assumed that a Designer can only limit its design work to what has been forecasted for a Sprint. This is not true. Designs may be part of Product Backlog refinement too. Thus Scrum teams generally engage in ‘Emerging Architecture’ and ‘Emerging Design’.
Although it may be tempting for organizations to resort to Architecture runways, Sprint zero’s or Design Sprints, these are not Scrum, but persistent Waterfall habits with a facade of Scrum terminology.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Now for this final principle, I could simply quote the entire section in the Scrum Guide related to the Retrospective. I too could run through each and every statement that involves inspection and adaptation. Most of these I have already addressed and sure, they may indeed be worth repeating. I will, however, leave it with one statement that pretty much covers it.
“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting [SN: into each Sprint Backlog].”
A final note.
If all this doesn’t cover it, then at least the Scrum Master is there to help the organization and team to “understanding and practicing agility” -SG.
Through this writing exercise, I hope to have demonstrated that indeed one can be Agile with Scrum. In fact, I hope to have illustrated that Scrum is a great way for teams to become Agile. Convinced or not, at the very least I hope that this exercise has helped to better your understanding of Scrum. It sure has improved mine. Through this exercise, I have learned, for example, that although it is often said that Agile is a mindset or culture, Scrum is too, and they match.
There might be lots that I have missed, and perhaps I have, at times, assumed too much. I would love to learn about this. So please return your thoughts and help me and others improve our understanding.
I guess some of the ‘distanciation’ by some Agilists to its framework heritage can be attributed to its puberty. Perhaps Agile’s parentage isn’t all that well known. Perhaps it’s time it met its mother (pun intended).
“So Scrum and XP are the parents of Agile which is not a framework or an operational implementation.” — Jeff Sutherland
At times I heard them incorrectly assume Scrum emerged from the Manifesto. But does it truly matter? It’s not a competition. Scrum and the Agile Manifesto are meant to go hand in hand; and they do.
Let’s agree on this harmony, rather than throw dissent. Scrum indeed surely isn’t the only way to go about it, but its surely a darn good one. But one can’t achieve serious results, without taking it seriously to begin with. Too often, ironically, Agile has become an excuse for organizations attempting Scrum, to not take it all that seriously… and consequently, not achieving its intended agility.
Thank you for taking the time to read and I hope you too will share your thoughts on this.
