Tag: Agile Manifesto

Posted on by — 5 Comments

Agile (What’s so funny about peace, love and future dreaming?)

The Agile Manifesto, and the movement that stemmed from it, has hugely improved the world. I believe in continuing the Agile dream and create an even better world (rather than focus on the inevitable downsides of the success).

In February 2001, seventeen software development leaders gathered at the Snowbird ski resort in Utah (United States) to discuss their views on software development. Those were times of failing waterfall and heavy-weight RUP projects (‘Rational Unified Process’). These 17 people were following different paths and methods; Scrum, eXtreme Programming, Adaptive Software Development, Crystal, Feature Driven Development, etc.

Much to their own surprise they found an agreement over a set of common principles, beliefs and viewpoints, published as the „Manifesto for Agile Software Development“. The adjective ‘Agile’ became the label to describe the views described in the Manifesto.

Even more to their surprise ‘Agile’ turned into a success, with many people signing the Manifesto and -albeit gradually- Agile taking over the world. A new paradigm was born, in the realm of the software industry. A movement stemmed from it, with Scrum as distinct definition of Agile heading the pack. Over time, Agile seeped into other domains of work and activities, beyond software and product development.

Today, the balance of society incessantly keeps shifting from industrial (often physical) labor to digital (often virtual) work. In many domains of society, the unpredictability of work increases, drastically and continually. The industrial paradigm is rendered useless, definitely. The need for the Agile paradigm is bigger than ever. Scrum is the new reality, now and in the foreseeable future. Actually, Agile and Scrum are inseparable ingredients.

The success of Agile was unplanned, unpredictable, a huge gamechanger and… undesirable (to some).

It deeply saddens me to read, hear and feel the scorning, the resentment, the cynicism. It deeply saddens me that people find little other purpose in life than to make a day job out of negativity, out of pointing at flaws (real or imagined), perceived shortcomings and the incompleteness of Agile. It deeply saddens me to hear people that still are not over the feeling they should have been invited to the Utah event.

Agile as described in the Manifesto, indeed, is imperfect and purposefully leaves room for ambiguities. And, yes, Agile partially turned into a business in itself with forms of bastardization into marketing and moneymaking schemes. And, maybe, there are people and organizations that don’t „get it“ and demonstrate a lack of ‘true’ understanding. That might mean we have not done a good job of helping them discover the value of Agile (in which case a new name will not solve the problem). It might just be in the eye of an ignorant beholder or self-acclaimed experts alike. Who are we to judge?

Regardless, Agile was and is a huge improvement to the world. I am grateful that those 17 people provided us with an amazing foundation upon which to build, discover even better ways to do our work, and keep creating a better world to live and work in.

And, yes, I am wary of the new cult too, the Big gestures and the beatification. I also see the hunts for adoration, name and fame. I observe ideas being stolen, ripped and degraded. All speaking against the Agile and Scrum Values, I know. In avoiding falling into the trap of scorning myself, I have no other choice than to remain with my belief that Agile is not about comic figure-like stereotypes and dress-up routines. Agile is not about massive tap dancing crowds or cheerful ticker tape parades. Agile is not in your title, not in how you look. Beyond being in what you say, Agile is primarily in what you do, how you act.

Still, Agile is a choice, not a must. Nobody needs to join me on my path of continuing the dream. I like to think I am open for any other new, deviant, disruptive idea that introduces more improvements and further humanizes the workplace. In the meantime, I’ll stick to trying whatever I can do to demonstrate the value of Agile, with the Scrum framework as favourite toolbox in my backpack. I can only suggest others to allow their ideas to speak for their positive selves. I am sure blaming Agile (for its broad adoption) is hardly helpful in that regard.

Warm regards
Gunther
your independent Scrum Caretaker

(Thank you, Higher View, for your professional expertise in video creations)

 

Posted on by — 5 Comments

Agile and Scrum, actually

In early 2001, with the creation of the Manifesto for Agile Software Development, the adjective ‘agile’ obtained a specific meaning in the context of software development. The manifesto, commonly known as the Agile Manifesto, holds 4 value statements with 12 principles behind it. In these values and principles the signatories of the manifesto captured the mindset, the DNA, common to their approaches to software development.

Over the years to follow, Agile became a proper noun, capitalized, pretty popular and ultimately big business as the methods for Agile software development were increasingly adopted. Success obfuscates and diminishes actionability, it seems. Today “Agile” is all over the place; coming in many flavors, wrappings, definitions, interpretations, and discounted. “Agile” sells. It is probably the most used prefix for roles, jobs, positions, functions and phases found in the software industry. The fact that Agile is a set of values and principles is easily ignored, as are the actual values and principles themselves.

Correlating ‘scaling’ to Agile has a similar neglect. Tactics change with scale. Strategies change with scale. Values and principles don’t change with scale. Claims and statements on the need, the ability, the inability, the whatever to scale Agile are plainly besides the point. Values and principles are agnostic of scale.

Agility, as an extension of Agile, refers to the state that people, teams, organizations hope to achieve by adopting Agile development processes. Agility, as such an extension, is a state of high responsiveness, speed and adaptiveness; a state of constant invocation of change, evolution and improvement. A state of agility enables people, teams, organizations to better deal with the natural complexity and unpredictability of the work of software development itself, the organizational context within which it happens and the external circumstances faced. The adoption of Agile indeed is an important foundation for this (business or enterprise) agility.

Scrum emerged in the early ’90s from the work of Jeff Sutherland and Ken Schwaber. They formalised and turned Scrum into a cohesive set of rules and roles for complex product development, that was formally presented to the public for the first time in 1995. The definition of Scrum, its rules and roles are described in the Scrum Guide. Both co-creators of Scrum are signatories of the Agile Manifesto. The values and principles of the Manifesto for Agile Software Development underpin the Scrum framework which thrives on empiricism and self-organization. Scrum is better understood when seen through the lens of the Agile Manifesto.

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.

In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.

Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.

Posted on by — Leave a comment

Scrum Is A Stance (too)

-An inquiry into the expression of behaviors through Scrum-

Scrum is not a cookbook ‘process’ with detailed and exhaustive prescriptions for every imaginable situation. Scrum is a framework of principles, roles and rules that thrive on the people doing Scrum. The true potential of Scrum lies in the discovery and emergence of practices, tools and techniques and in optimizing them for each organization’s specific context. Scrum is very much about behavior, much more than it is about process.

(from the preface of „Scrum – A Pocket Guide“, Gunther Verheyen, 2013)

It is worthwhile elaborating on the importance of people and behavior in Scrum. Because, indeed:

Scrum is very much about behavior, much more than it is about process.

Introduction: the simplicity of Scrum

Presumably there are many reasons why Scrum turned into the leading framework for Agile software development during the past decade. One of the reasons may be the simplicity of Scrum. Or, perhaps it is the opposite, the wide adoption of Scrum is more like a miracle given that same simplicity.

Yet, the simplicity of Scrum is ESSENTIAL. The simplicity of Scrum reminds us of the fact that the real complexity to be tackled in software development lies outside of the rules and roles of Scrum. The real complexity resides in the specific context within which Scrum is applied. In software development, ‘context’ starts and ends with people; what people do, don’t do, like, dislike, prefer, hate; how people jell, feel and behave. The rules and roles of Scrum help people tackle complexity. But no ‘process’ can replace or compensate the people aspect of software development.

The simplicity of Scrum creates openness. It is an open invitation for discovery and emergence. Yet, the simplicity of Scrum gives rise to many frowns, emotions, reactions, debates. It is experienced as enticing, provocative, offensive, powerful, inadequate, a mystery, impossible. Is the beauty of Scrum, expressed through this simplicity, therefore in the eye of the beholder only? Or is there more to Scrum than meets the eye?

In the end, more than the rules and roles of Scrum, people have the key to Scrum. Behavior is the key to unleashing the potential of Scrum. Scrum is a stance, too.

The eye of the beholder

The rules and roles of Scrum are described in the Scrum Guide. The Scrum Guide was created and is maintained by Jeff Sutherland and Ken Schwaber, co-creators of Scrum. It is the definite body of knowledge to Scrum.

The rules and roles included in the Scrum Guide can be applied and followed as described, with no further inquiry into the why of these rules and roles. They can be regarded as ‘to be followed’ instructions, merely because the Scrum Guide prescribes them.

Blindly following the described roles and rules is for many in the industry of software development at least a great start to transform to Scrum. It helps. People, teams and organizations start, learn, and improve in creating and delivering software iterative-incrementally, with small steps of validated learning. However, sticking to, not transcending, such blind view and usage of Scrum is likely to turn Scrum into no more than yet another IT delivery process. As such it still leaves many holes, gaps, disconnects and waste. The rules and roles of Scrum, as described in the Scrum Guide, in themselves might not be enough to grasp the depth of Scrum and reap the full benefits of employing Scrum. The simplicity of Scrum may be somewhat deceptive.

It helps to dig deeper by:

  1. Reflecting on the definition of Scrum included in that same Scrum Guide document,
    “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
    In the Scrum Guide this definition precedes the description of the rules and roles. This definition shows how Scrum is intended, i.e. an aid for the people employing Scrum, a way for people to structure and organize their own work. It sheds a different light on the subsequent roles and rules of the Scrum Guide. Yet, both are in the same document. Ultimately, the roles and rules described in the Scrum Guide can only be fully understood from the definition of Scrum and the clear intent expressed in that definition.
  2. Reading the description of the roles and rules again, e.g. some time after having started with Scrum. It often leads to the discovery that the Scrum Guide describes behavior more than it has technical prescriptions. A typical focus of many processes is on ceremonial technicalities like meetings, deliverables, timings, phases; i.e. on what is expected from people. Scrum is a framework that gives people the room to organize their own work, yet provides boundaries as every healthy ecosystem needs.
  3. Stepping back to a perspective that goes beyond the Scrum Guide document, the perspective offered in the Manifesto for Agile Software Development. The rules and roles described in the Scrum Guide, the behavior described, don’t just stand on their own. They are grounded in the values and principles expressed in the Agile Manifesto. Ultimately, the Scrum framework can only be fully comprehended when seen as an expression of these values and principles. Ultimately, the rules and roles of Scrum, the behavior described in the Scrum Guide, can only be fully understood in combination with the fundamental views expressed in the Agile Manifesto.

The intent and definition of Scrum, matched against the agile values and principles should ground and then drive the behavior expressed through Scrum.

The Stance of Scrum

Scrum has many facets. Scrum is a framework, not a methodology. The framework of Scrum is not just a set of technical prescriptions, but a recipe to deal with complex challenges. The rules and roles of Scrum support and complement, not replace, the intelligence and creativity of people. The framework of Scrum is an implementation of the values and principles of the Agile Manifesto. Scrum implements empiricism in software development.

The framework of Scrum thrives on implied principles, thinking and… behavior, on people taking a stance to product development through Scrum, a Scrum stance.

The definition of Scrum shows the way to the core of the stance typical to Scrum. If Scrum is an operating system for the values and principles expressed in the Agile Manifesto, the definition from the Scrum Guide shows the way to the kernel of the operating system.

The kernel is expressed as:

PEOPLE EMPLOY EMPIRICISM TO OPTIMIZE THE VALUE OF THEIR WORK.

Where:

  • People are respected for their intelligence, creativity and ability to organize their own work, to self-organize. People collaborate, thereby adhering to the values and principles of the Agile Manifesto and embodying the Scrum values of respect, focus, courage, openness, and commitment.
  • Empiricism serves to deal with the complexity typical to software development. In empiricism only reality and past results are accepted as certain. At a regular cadence outcomes and behaviors are transparently inspected for new and changed insights against set goals. These insights are used to adapt to observed reality.
  • The value of outcomes, work delivered to an ecosystem of creators, stakeholders and consumers, is constantly evaluated, optimized and maximized as a shared goal. Value comes in different shapes and appearances; satisfaction, money, improvement, credibility, risk. Optimizing value is very different from adhering to traditional development drivers like budget, tasks, scope, time, schedule.

In the end, Scrum has many appearances. In the end, Scrum -like all things agile- starts and ends with people. Scrum is a stance, too.

The Scrum Stance