Agile Vs. Scrum –what is the difference?
What is the difference between Scrum and Agile?
A LOT of people think that:
- Scrum = Agile; and
- Agile = Scrum.
But that ain’t so.
Scrum predates the Manifesto for Agile Software Development, often known as the Agile Manifesto. And Scrum inherits from Lean. Scrum is only one of many options from the original signatories of the Agile Manifesto.
A brief history
The Agile Manifesto was created in February 2001. The twelve principles were crafted and agreed upon in subsequent hours, weeks, and months. The Agile Manifesto has, more or less, stood the test of time.
If you change the words:
- “software” to “product” or “product development”; and
- “project” to “product” in the manifesto and the twelve principles,
it still kind of works, albeit in a 2001 kind of way.
The Manifesto is showing its age, and even though there have been a number of attempts to supersede the Agile Manifesto, they haven’t really taken off, in my view.
Processes are important, but not when they get in the way of delivering value. Delivery is important, but not when the wrong stuff is delivered. And what do we see? Employees get pressurized, managers act like it’s business as usual, and customers get forgotten; such is the distance between teams and customers.
Scrum
Avoid assuming Scrum and Agile are the same thing. Agile has values and principles. Scrum has rules and guidelines. Scrum has many things neither mentioned in Agile nor Lean, including different values, three pillars, five events, three “commitments,” three accountabilities, and a highly recommended activity.
– The Scrum Pillars are Transparency (if you don’t know what you’re looking at, you’ll have a poor inspection and worse adaptation), Inspection, and Adaptation; use these to help deal with complexity.
– The Scrum Values are Focus, Openness, Courage, Commitment, and Respect; use these or something better to stay in the spirit of Scrum.
– The Scrum Accountabilities are Scrum Master (guardian for the effectiveness of the team), Product Owner (maximizes value ), and Developers (people who do the work, discovery and delivery, and deliver a high-quality cumulative product increment)
– The Scrum Events are the rhythmic Sprint of one month or less, Sprint Planning (plan the Sprint Goal, the selected items, and the related work), Daily Scrum (check progress toward the Sprint Goal, adapting as needed), Sprint Review (sensing what customers, users, and other critical stakeholders need, inspect progress toward the Product Goal, adapting as needed but I also expect learning via feedback, analytics, and experiments), and Sprint Retrospective (improve the team’s effectiveness and approach to built-in quality).
–Artifacts are Product Backlog (work of the Scrum Team, mostly toward the Product Goal), Sprint Backlog (Sprint Goal and plan for the work for the Sprint), and Increment (the potential value delivered that complies with the Definition of Done). There is an expectation of 1+ Done increments per sprint that are valuable, useful, and (hopefully) usable.
–Commitments are the Product Goal (North Star for the Scrum Team), the Sprint Goal (a possible step toward the Product Goal or mini-north-star within the Sprint), and the Definition of Done (the explicit agreement on what quality means that the Scrum Team commits to and continually improves, and simplifies as trust improves).
–Product Backlog Refinement is a highly recommended activity for the Scrum Team to get a common understanding of the work in, for example, the upcoming 2–3 Sprints, where work gets commonly understood, sized, and split into still potentially valuable items that fit well into a sprint alongside other items. I suggest you have 4–6 items per team per sprint so items are understood by stakeholders without explanation and the Product Owner’s brain doesn’t explode. Also, examples get elicited from customers, users, and other critical stakeholders, and maybe even research, experiments, and design get triggered or discussed.
The world is tiring…
In my view, the world is tiring of “Agile,” which has been destroyed by fakery, industrialization, “agile/digital transformations,” a lack of appreciation for the business domain and technical excellence and organizational process alignment, “inflicting help,” and overplaying the professional coaching stance when people needing help lack the wherewithal yet crave answers. It’s worth checking out a talk by Martin Fowler where he talks about the Agile Industrial Complex.
The world is also tiring of “Scrum,” which has been destroyed by the same ills, as well as some artificial change agents who do not live and breathe the essence of Scrum — a small cross-functional empowered team continually inspecting and adapting to complex problems in a direction, and getting real rapid feedback from stakeholders including users and customers, improving and learning all the while.
When a company hires a transformation offer, I wonder who the not-so-transforming officers are. Delegating change does not feel like the right answer; in my view, change is for everyone who is willing, but it has to be fully supported from the very top, bottom, and right across.
I am in the camp of great managers having the potential to become great Scrum Masters, as they have more power and influence to deal with impediments. If Mary is my manager and I am a Scrum Team member, I hope she is the Scrum Master for a different team and not my team. I prefer that to an easier target for cost-cutting of Scrum Masters who didn’t do themselves any favors.
But, I’ve seen cases where being the manager and Scrum Master for the same Developers was not a problem; it was more honest. There is nothing worse than being empowered until you’re not empowered — it erodes trust.
When adopting new ways of working, it’s tempting to pick Scrum because it has lots of support, but Scrum is also the victim of its own success, with people ill-suited to it and Scrum being ill-suited to some types of work in some contexts.
I personally prefer no Scrum Master to a bad Scrum Master; it’s an accountability that can be shared by the team. I also prefer no Product Owner to someone who does not own the product but is called a “Product Owner.” Scrum.org has consistent classes if you want well-trained Scrum Masters, “Developers,” and Product Owners.
Aside from that, Kanplexity takes advantage of the change agents already in the organization. It asks for explicitness about who is most worried about what but embraces “fuzziness.”
How did the Agile Manifesto come about? What does it encompass?
The Agile Manifesto explains what Agile is, and Agile has four values and 12 principles. Seventeen people were on that skiing trip when they created the four values for the Agile Manifesto. Jim Highsmith summed it up officially. See also the views of the originators (I personally like Kent Beck’s proposed evolution of the manifesto values in 2011). I loved listening to the Agile Uprising podcast interviews with most of the original manifesto signatories.
To my knowledge, three of the original signatories represented Scrum: Mike Beedle (RIP), Jeff Sutherland, and Ken Schwaber. There were 14 other people there representing all sorts of other approaches. These include eXtreme Programming (XP), lean software development, feature-driven development (FDD), and Crystal, to name but a few.
Inspirations for facilitation and creation of the “Agile Manifesto”
Martin Fowler documents the road to the manifesto at https://martinfowler.com/articles/agileStory.html. Martin’s article refers to other articles by:
– (Pragmatic) Dave Thomas at https://pragdave.me/thoughts/active/2007-02-24-some-agile-history.html
– Robert C. Martin at https://sites.google.com/site/unclebobconsultingllc/the-founding-of-the-agile-alliance
– Caroline Mimbs Nyce at https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/
– a video by Jeff Sutherland at https://youtu.be/AGdi3zZutXk?si=DhI6lHztZM6bHNul.
In addition, Alistair Cockburn recalled in 2023 that there were several precursors to the February 2001 Snowbird event, namely:
– WOOD at Snowbird also — they were designed around morning work, afternoon skiing, evening work, agenda built after arrival, etc.
– PLOP (Pattern Languages of Programs) by Hillside — see https://www.hillside.net/ — Alistair Cockburn recounted in late 2023 that the PLOP conference gave Ward Cunningham, Kent Beck, Martin Fowler, and himself a language of interaction inside the workshops, which helped sessions. Hillside was the patterns group before PLOP. According to Alistair, Ward Cunningham and Kent Beck used to attend the Hillside events.
So, what is the difference between Agile and Scrum?
Agile can be considered as a set of values, a set of principles. Agile is considered by some as a family of methods, frameworks, and strategies in which people can pick which option they want to apply to improve their agility; that kind of misses the point of anarchy, perhaps the original intent.
But, it’s understandable as the seventeen people represented different parts of the Agile spectrum, even if they managed to avoid talking about that. Simon Powers describes Agile with an Agile Onion.
So Scrum is only one of the options. It is probably the most popular option. “Kanban” and the “Lean” methods are catching up fairly quickly. Many would argue Kanban is more of a Lean approach; some would argue it’s not Agile or even part of the broader school of agility because they believe it is more derived from the works of W. Edwards Deming and Walter Shewhart.
There’s a lot of work in product management that is similar to what people are doing in the agile space, except there’s more focus on discovery, getting customer data, and quantitative and quality data-informed decision-making. In addition, product management has more focus on the problem space. I discovered this when I researched the work of product and design thought leaders for the Xagility podcasts at http://xagility.org. And for the past few years, I have been a product manager.
Is Scrum moving towards product management?
The more I see Scrum with UX developing, the more I see Scrum moving towards the product management space. There’s still a lot of room for improvement.
In product management, some people talk about product managers and product leaders. In Scrum, they have product owners, and there’s only one product owner for the product.
I have no problem with a tech lead, design lead, and product manager on each team as “developers” on the Scrum Team as long as they don’t get in the way of the work of other members of the Scrum Team and as long as a product leader acts as the only product owner. I talk about that in another article.
But I prefer teams to see the big picture with a transparent and up-to-the-minute “company bets” list to avoid someone working on priority number 25 and blocking someone on priority number 1 (hat tip to Cliff Hazell). This is why a single product backlog helps, as Scrum requires.
A consolidated timeline of the evolution of Scrum
– Takeuchi, H. and Nonaka, I. (originally published in print in 1986, electronically published 2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game. This is regarded as the seminal paper, the first time the word “Scrum” was officially associated with knowledge work.
Scrum is just one option, and Scrum was formed in the early to mid-nineties. It was announced at an OOPSLA conference in 1995 and has been iterated and evolved over the last number of years. There have been a number of versions of the Scrum guide, and the latest version is the 2020 Scrum guide.
There are lots of benefits to the latest version of the Scrum guide, but there is a bit of a disconnect in some communities, like, for example, the LeSS community, which has actually disassociated itself from the 2020 Scrum guide and has, instead, chose to stick to the 2017 Scrum guide.
What is a “product”?
Scrum is not designed for project management. It is designed for product development. Maybe it’s helpful to understand what a product is.
My personal opinion, even though I’m a LeSS-friendly Scrum trainer, is that the 2020 guide is a major step forward. I took the definition of product in the scrum guide with a pinch of salt, and I came up with my own approach, which I also talked about in another article.
What would the external customer or end-user recognize, and what would they pay with their money, data, or some other consideration? It’s not an internal platform. It’s not a complicated subsystem. It’s something that an external customer or end-user would recognize. There are critical stakeholders such as a consumer and a producer, and Scrum is designed for product development. It’s a bit of an oversimplification, but that’s how I define a product.
Scrum predates Agile
Scrum is older than Agile. So it’s funny when Scrum adopters talk about returning to the Agile Manifesto. The Agile Manifesto postdates some of the methods, but there have been some new approaches since the Agile Manifesto, some Agile, some Lean, and some closer to product management. Kanban (as we know it now) for knowledge work, Lean Startup, Lean UX, and design thinking have developed a lot since 2001.
And Scrum has been developed since Agile was developed. Is Scrum an Agile approach? That’s a debate for another day. Some people argue that it’s not.
Some people argue against frameworks, methods, and strategies. In my view, Scrum’s evolution has been inspired by Agile, Lean, Extreme Programming (XP), Lean Startup, Lean UX, Kanban, Scrum.org Evidence-Based Management™, and XP. Ensemble work and DevOps are popular.
I like to ask people to sort the Agile Manifesto principles and select their top 3 and bottom 1 of the ones they like, as opposed to what’s possible. I also like to ask why people really feel their organization is attempting agility. One thing is certain: one person’s Agile is not another person’s Agile.
The pillars of Scrum
The 2020 Scrum Guide states that Scrum is based on empiricism or empirical thinking and lean.
Some would argue that it’s not based on empiricism and empirical thinking. If you do a Google search on empiricism, you’ll find very little about the three pillars of Scrum. But the pillars do seem reasonable. Nigel Thurlow wrote a wonderful article that digs more deeply into that topic.
The three pillars of Scrum:
- inspection;
- transparency; and
- adaptation.
The basic idea is to try things and decide what to do next based on the evidence and the learnings of what we did last. That seems reasonable. But let’s be informed rather than driven by the data, and let's be open to experimenting with some hunches.
We’re also seeing Lean Agile approaches. As of 2017, we’ve got Scrum with Kanban, although it can also be applied via Kanban Guide. And then we’ve got Scrum with UX, based on Lean UX, which is like a 21st-century variant of Lean for Knowledge work.
In Lean UX, we’re not just talking about manufacturing or getting work through the system quicker and knowledge work, but we’re also trying to figure out, well actually, should we build anything or is there something better to build or a more important and urgent problem to solve? Should we run some experiments and talk to customers to get evidence to see what we should build?
Scrum has grown up, particularly under the scrum.org umbrella, and with complementary approaches like Kanban and Lean UX and other approaches, Scrum is becoming more agile than Agile in many respects.
The essence
I believe the essence of Scrum is to have a small, empowered team continually inspecting and adapting potential solutions to complex problems in a direction, getting real rapid feedback from users and customers, and improving and learning all the while.
Getting lost
People get lost by having delivery managers, agile project managers in Scrum Master clothing, project managers, or business analysts in Product Owner clothing. I only ever met two empowered Business Analysts, so I prefer them to be “Developers’ like other people doing the work.
Managers get lost by treating estimates or Sprint Goal commitments as hard commitments, thereby sacrificing fit-for-purpose product fidelity (hat tip to Karl Scotland) and quality. Managers also assume that the work to deal with complex problems is fully known and predictable.
Organizations get lost by assuming agility is a team sport (hat tip to Klaus Leopold). Organizations must declutter, simplify, and refactor workflows, processes, and systems, including budgeting, procurement, and HR.
The birth of Kanplexity
I personally think there is value in scaffolding for people. Not everybody can follow values and principles independently, and I’ve been known to create methods, frameworks, and strategies for teams. In fact, Kanplexity (Kanban for complexity) — was designed for exactly that purpose.
Kanplexity was built for teams and crews that couldn’t use an available option, yet they and I felt they needed something beyond values and principles. We won’t get into that debate right now. I fully support people who are involved in open agility, and I get what they’re doing. It’s just that I do sometimes see the benefit of frameworks, strategies, and methods.
Before the “Agile Manifesto,” Before Scrum
When I was in school, I seemed to naively think everything was invented during my lifetime or maybe shortly before it. You may feel the same now, perhaps?
As I got older, I realized my mentors had mentors who also had mentors. 2nd hand accounts for events 100 years ago are within my reach, and I trust the people offering me first-hand information. One of my mentors was friends with Deming and another with Drucker.
As I dug more into the history of Agile, I discovered that people were Agile before Scrum and before the “Agile Manifesto.”
Before it had a name, Tom Gilb lived and breathed agility in the 1960s. He published a book on it in 1976, “Software Metrics” (Winthrop).
Leading lights had been practicing iterative and incremental development since the mid-1980s. Craig Larman and Victor L. Basili published a paper on the history of iterative and incremental development pre-manifesto.
In 2011, a paper by Torgeir Dingsøyr, Sridhar Nerur, VenuGopal Balijepally, and Nils Brede Moe reviewed progress.
Leading lights were listed in chapter 15 of Tom Gilb’s Principles of Software Engineering Management, 1988, Addison-Wesley; it’s a classic still worth reading today. Leading Lights include:
– Eric Allman and Michael Stonebraker, UC Berkeley, “Observations on the Evolution of a Software System,” IEEE Computer, June 1982, pp. 27–32, ©1982 IEEE.
– Robert Balzer, USC/Information Sciences Institute, “Program Enhancement, ACM Software Eng. Notes, August 1986, Trabuco Canyon Workshop position paper, pp. 66–67.
– William Swartout and Robert Balzer, USC/Information Services Institute, “On the Inevitable intertwining of specification and implementation,” Comm. of ACM, July 1982, pp. 438–440.
– Victor R. Basili, University of Maryland, and Albert J. Turner, Clemson University South Carolina, “Iterative Enhancement: A Practical Technique for Software Development,” IEEE Trans. on Software Engineering, December 1975, pp. 390–396, ©1975 IEEE.
– Barry W. Boehm (TRW Defense Systems Group), “A Spiral Model of Development and Enhancement,” ACM SIGSOFT Software Eng. Notes, Vol. 11, №4, August 1986, pp 14–24 (Proceedings of International Workshop on the Software Process and Software Environments, Trabuco Canyon CA 27–29 March 1985, ACM Order 592861).
– F.P. Brooks, The Mythical Man-Month, Addison Wesley, 1975, where Brooks talked about “growing over building software.”
– P. Allen Currit, Michael Dyer, and Harland Mills, “Certifying the Reliability of Software,” IEEE Trans. on Software Engineering, Vol. SE-12, №1, January 1986, pp. 3–11, ©1986 IEEE.
– Swedish Language article in Nordisk Datanytt 17/86 pp. 40–43, “Programmeringsomgivninger” (Software Environments), Hans Petter Dahle (Inst. for Informatikk, University of Oslo), and Boris Magnusson (Lund’s Engineering University).
– An English report Mjølner — “A Highly Efficient Programming Environment for Industrial Use,” edited by H.P. Dahle et al., Mjølner Report №1, available from Norsk Regnesentral, Forskningsveien 1b, Blindern, Oslo 3, Norway.
– Michael Dyer, IBM Federal Systems Division, “Software Development Processes,” IBM Systems Journal, Vol. 19, №4, 1980, pp. 451–465
– Ken Eason, HUSAT, Loughborough, UK, “Methodological Issues in the Study of Human Factors in Teleinformatic Systems,” Behavior and Information Technology, Taylor & Francis, UK, 1983, Vol. 2, №1, pp. 357–364.
– Robert L. Glass, “An Elementary Discussion of Compiler/Interpreter Writing, ” ACM Computing Surveys, Vol. 1, №1, March 1969.
– Michael A. Jackson and Daniel D. McCracken, “Life Cycle Concept Considered Harmful,” ACM Software Eng. Notes, Vol. 7, №2, April 1982, pp. 29–32.
– Stefan Jahnichen and G. Goos, GMD Research Center, Karlsruhe, “Towards an Alternative Model for Software Developments,” ACM Software Eng. Notes, August 1986, pp. 36–38.
– Lech Krzanik, “Dynamic Optimization of Delivery Step Structure in Evolutionary Project Delivery Planning,” Proc. Cybernetics in Organization and Management, 7th European Meeting, Vienna 24–27 April 1984, R. Trappl (ed.), North Holland, 1984.
– M. M. Lehman and L.a. Belady, Program Evolution: Processes of Software Change, Academic Press, 1985, originally published in Journal of Systems and Software, Vol. 1, №3, 1980, ©1980 Elsevier Science Publishing Co, Inc.
– Paul R. Melichar, IBM Information Systems Management Institute, Chicago, “Management Strategies for High-risk Projects,” Class Handout, approx. 1983.
– David L. Parnas, “Designing Software for Ease of Extension and Contraction,” IEEE Trans. on Software Engineering, Vol. SE-5, №2, March 1979, ©1979 IEEE.
– Robert E. Quinnan, “Software Engineering Management Practices,” IBM Systems Journal, Vol. 19, №4, 1980, pp. 466–477.
– Ron A. Radice et al., A Programming Process Architecture, IBM Systems Journal, Vol. 24, №2, 1985, pp. 79-90.
– Leonard B. Robertson and Glenn A. Secor, AT&T, “Effective Management of Software Development,” AT&T Technical Journal, March/April 1986, Vol. 65, Issue 2, pp. 94–101, ©1986 AT&T.
– Rzevski’s evolutionary design methodology, source: Leonard B. Robertson and Glenn A. Secor, AT&T, “Effective Management of Software Development,” AT&T Technical Journal, March/April 1986, Vol. 65, Issue 2, pp. 94–101, ©1986 AT&T.
– K.R. Popper, Objective Knowledge, an Evolutionary Approach, Oxford University Press, 1972.
– T.S. Kuhn, The Structure of Scientific Revolutions, University of Chicago Press, 1970.
–Sachs, author or Lotus 1–2–3 (a precursor to Microsoft Excel), source: Susan Lammers, Programmers at Work, Microsoft Press (USA and Canada), Penguin Books elsewhere, 1986, ©1986 Microsoft Press, All Rights Reserved.
– Ben Schneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison-Wesley, 1987.
– Carroll and Rosson, “Usability specifications as a tool in iterative development,” H. Rex (ed.), Advances in Human-Computer Interaction 1, Ablex Publishing, Norwood NJ, 1985.
– Charles Garfield, Peak Performers, William Morrow & Co., Inc., NY, 1986.
–Andrew S. Grove, Intel Chairman and Founder, High Output Management, Souvenir Press (UK), Random House (USA), 1983.
– Rosabeth Moss Kanter, The Changemasters, ©1983, Simon & Schuster, Inc.
– Tom Peters and Nancy Austin, A Passion for Excellence, Collins (UK), Random House (USA), 1985, ©1985 Thomas J. Peters and Nancy K. Austin.
– Peters and Waterman, In Search of Excellence, Harper and Row, New York, 1982.
–W. Edwards Deming, Out of the Crisis, MIT CAES, 1986, Cambridge University Press.
– Billy V. Koen, “Toward a Definition of the Engineering Method,” Spring 1985 The BENT of Beta Pi, ©IEEE.
– Shewhart, source: W.E. Deming, “Tributes to Walter A. Shewhart,” Industrial Quality Control, Vol. 24, №2, August 1967, cited in AT&T Technical Journal March/April 1986, pp. 11–12 (note that Shewhart was a mentor to W.E. Deming and Joseph M. Juran).
– Christopher Alexander, Murray Silverstein, Sara Ishikawa, et al., The Oregon Experiment, ©1975 The Center for Environment Structure.
– Frank Lloyd Wright, An Autobiography, Horizon Press, NY, 1977.
– Patrick J. Meehan (ed.), The Master Architect — Conversations with Frank Lloyd Wright, John Wiley & Sons, Inc., 1984.
– Victor Papanek, Design for the Real World, Granada, 1974.
–A. Morley Davies, Evolution and its modern critics, Thomas & Co., London 1937.
– Benjamin Franklin via Tuchman, source Barbara Tuchman, The March of Follow, Abacus, 1984, p. 248.
From Agile Manufacturing to Agile Systems Engineering
Some of the leading software/systems engineering practitioners were not invited to Snowbird in 2001, despite best efforts For the Snowbird 2001 event to have a broad reach.
The design community (or whatever it was called back then) was also not so present at the metaphorical. I think that was a missed opportunity. We might have had more thought around critical stakeholders and leadership.
Indeed, in the context of knowledge work, the word Agile was first publicly touted in 1991 by Rick Dove in the OSD-funded project at Lehigh University to identify what would come after Lean. The Agile Systems Engineering folks were not pulled in; some believe the manifesto was designed by coders, not systems engineers.
Dove, R. (2021) Real-Time Chronicles: Short Essays on Emerging Agility Knowledge, Library: Agility Essays, realsearch, change proficiency, knowledge management, agility reference. Available at: http://www.parshift.com/library.htm (Accessed: 22 January 2024).
Dove, R. (1994) The Meaning of Life & The Meaning of Agility, Agility Essay #1: The meaning of life and the meaning of agility. Available at: http://www.parshift.com/Essays/essay001.htm (Accessed: 22 January 2024).
In my view, 20th-century Lean lacks ambidexterity, a balance of the short-term and the long-term. Look at how the combustion engine auto manufacturers struggle to make money from EV or H2.
Tesla has been leading the way with what I can best describe as Agile Manufacturing.
We are humans, and Tesla is still run by humans, so Tesla is not perfect. I write about Tesla in an upcoming publication. Rick Dove had the vision to spot the possibility of Agile in 1991. Back then and again in 2014, Rick referred to agility as “that characteristic which allows an organization to thrive in an environment of constant and unpredictable change.”
Dove, R. (2014) Fundamentals of Agile Systems Engineering — Part 1 — parshift.com, parshift.com. Available at: http://parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf (Accessed: 22 January 2024).
While the “Agile” word might have been back of mind from Agile in hardware or Agile manufacturing or Agile Systems Engineering at Snowbird in February 2001 as alternatives to “Lightweight” were considered, the Snowbird February 2001 group seemed to land on that word independently. I am curious what might have happened if “adaptive” was selected instead.
1985 — Back to the future
I cannot help noticing the frequency of the word “evolution” in the pre-Scrum history of agility. Tom Gilb is the first person I noticed writing about the traditional approach as “revolutionary.” That initially gave me a double-take, but it kind of makes sense on another level. Tom was credited by most, if not all, of the Agile Manifesto signatories.
On one level, today’s Agile focuses too little on iterative and incremental. On another level, today’s Agile focuses too much on iterative and incremental and insufficiently on feedback, data-informed learning, and change. I would add that today’s Agile needs a more interlaced focus on the problem space, discovery, delivery, and value actualization.
For this reason, I am curious about efforts to reimagine Agile with more of a focus on people. People need focus as happy people can lead to happy customers, but let's not forget:
– critical stakeholders such as the customer, the user, the consumer, vendors, regulators, and organizational stakeholders
– the problem space
– discovery
– technical agility
– value actualization
– cultivating an environment where agility can grow
A rejection of Agile does not have to mean no to frameworks and methods. It could mean a worthwhile jump into a Delorean back in 1985, but try to sneak some of the stuff we should not forget into the back seat of that Delorean car:). Rolling back to now, what would the world be like?
Concluding remarks
Many approaches have some history in Lean, and essentially, in Scrum, we’re trying to eliminate some waste, e.g., waiting time. But Scrum is really designed for effectiveness over efficiency. Lean is more about “efficiency,” although one’s efficiency is challenged if one is ineffective.
21st-century Lean is more about effectiveness regarding whether we are building the right thing. Should we be running experiments to figure out the right thing to build?
Agility could arise from the use of a selection of these things. It could be based on lean, agile, lean-agile, product management, DevOps, modern agile, et cetera.
If you select Agile, but if you do that, maybe try being Agile over doing Agile. Agile is not something you implement; it’s something you adopt, live, and breathe.
If you select Scrum, try living the essence of Scrum over mechanical application. Scrum is only a framework (some would argue a method, but let’s not get into that). Scrum does not tell you how to do marketing, HR, Finance, software development, or product management, for example.
You might be tempted to select something more built out so you don’t have to think. Not thinking is dangerous.
The best way to live Scrum is to focus more on actualizing value and improving the team. Spend less time making the rules noticeable. Great rugby referees preserve the game's flow and are careful not to blow the whistle too often.
Go back to the basics and the essence. Enjoy!
Feedback welcome. Words are my own. No AI was used for this article.
