is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals

​

Understanding and Applying the Scrum Framework 

Manifesto for Agile Software Development
 

We are uncovering better ways of developing software by doing it and helping others do it.

 

Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

 

 

Principles behind the Agile Manifesto

​

We follow these principles:

​

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

​

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

​

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

​

Business people and developers must work together daily throughout the project.

​

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

​

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

​

Working software is the primary measure of progress.

​

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

​

Continuous attention to technical excellence and good design enhances agility.

 

Simplicity--the art of maximizing the amount of work not done--is essential.

​

The best architectures, requirements, and designs emerge from self-organizing teams.

​

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

​

Empiricism, the act of making decisions based on what is

 

Empiricism is the act of making decisions based on what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

​

A Product Owner plans a release based on all current information. He or she lays out the goals, the features and capabilities that will deliver those goals, and the probable cost and date of delivery. From that point on, the Product Owner’s job is to assess what is possible given the Team’s capabilities, and to make the best decisions to reach the desired goal. Given the nature of technology, markets, requirements, and people, trade-offs are made. Sometimes the goal cannot be reached for a reasonable price. Sometimes the goal will be reached, but in a way different from what the Product Owner initially intended. This is empiricism in action.

 

The Team (of developers) on the Scrum Team does the same. It meets with the Product Owner and assesses what the Product Owner views as the most important things to do next. If done, these will move the emergent product in the best direction toward the desired goal. The Team selects as much as it believes it can do over the upcoming Sprint. The cost of the team and Sprint length are fixed. Only the amount of Product Backlog selected can vary.  The Product Owner and Team often define a goal for the Sprint. This is a subset of the release goal.

 

When the Team selects Product Backlog Items in a Sprint Planning meeting, it commits to do it during the Sprint.  A definition of “commit” is:

 

To bind or obligate, as by pledge or assurance; pledge: to commit oneself to a promise; to be committed to a course of action. (www.dictionary.com)

​

This conforms to my intentions of the word commit, which is a pledge, a commitment to a course of action.

​

However, many Scrum Teams use the word commit as if it were a “guarantee.” This is a residue of waterfall, where an estimate was a contract. However, it still rings in the heads of product owners and developers. I have found team after team that feels they have to do anything to deliver their commitment. The usual victim is quality.

​

Scrum is a pledge to do our best with what we have.

​

The Three Pillars of Empiricism (Scrum)

 

Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility.

The three pillars of empiricism are as follows:

​
 

 

​

​​

​

​

​

• Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda.

 

• Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can be done for the product, processes, people aspects, practices, and continuous improvements. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis.

 

• Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation should eventually relay back to one of the reasons for adapting Agile—for example, faster time to market, increased return on investment through value- based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and employee satisfaction.

 

Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased customer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management.

​

Agile is constant change

​

One of the key foundations of helping your business become Agile is the use of empiricism. Empiricism is the scientific approach based on evidence, where any idea must be tested against observations, rather than intuition. Empiricism is based on three pillars: transparency, inspection and adaptation. Adaptation has many synonyms, of which ‘change’ is the most common. One of the reasons that I like working within the Scrum framework is that there are clear learning opportunities built in – otherwise you need to put these in yourself.

After a short time you and your team should reflect on what has happened, and how it affected the performance within the team. Building on the better understanding, the team should decide what they will do to enhance the good things, and remove the bad things – that is you should focus on changing the environment to be better. This means that things will be different. If the situation is not different, then you have not acted on the learning (or your team are perfect).

​

Try to change too much

​

Limit the number of things that you are going to change. If it is a significant or challenging thing, then only take one action. Talk about this item in each Daily Scrum.
 

Nothing to Change

​

There are two extremes for this mindset, one extreme is being overwhelmed, and the other extreme is that of not seeing any way that the team could work better.

In both situations a way around this is to focus on a clear vision. If the team have a common goal, then the current state can be compared with that goal, and then find the one change that will give the most benefit for the least effort. Once a change, no matter how small, is enacted then you are moving and the momentum can grow.
 

Team vs Organisation change

​

Often the smaller teams (development and Scrum) gain the insight that agility is a continuous process and a mindset, not a state. Many organisations and leaders think that agile is a silver bullet, that gets invoked and that is all that is required.

The organisation needs to move to the mindset that things will be different, every day, every week. That is at the heart of business agility.

Helping this understanding take hold at a wider level is the responsibility of all the people helping develop the agility of the organisation. Depending on the organisation using a framework may help – the structure provides the robustness needed to embed an enduring change.

You will know your team is actively being agile when you use the phrase “for our team, we have found …” to describe your ways of working- regardless of what framework you started out with. Your team will have developed into a state of continuous improvement, using agile tools and techniques to deliver a better product, more frequently.

​

​

Escaping the Predictability Trap

​

It has been said that the definition of insanity is doing the same thing and expecting different results, and yet we engage in an unconscious fiction of predictability every day. We work in an uncertain world, and our main goal in pursuing agility is to confront the unknown, and in doing so, to master it. Pursuing predictability causes us to lay a veneer of fiction over the real world, making it conform to a plan of what we would like to believe is true rather than what really is.

​

The reality, however, is that organizations, and the people in them, hate uncertainty. They find predictability comforting, even when it is an illusion. But to gain greater insight and achieve greater results, we have to strip away our false conceptions and see the world as it is. Agility without full transparency is a sham that reduces real agility to empty rituals.

​

Humans are wired to avoid uncertainty; psychology studies have shown that people will choose a certain but poor outcome over an uncertain but potentially better outcome.  We have to, somehow, let that go. Predictability sounds good, and it would be nice if we could predict the future, but we have to be realistic. Those things we call “plans”? They’re just guesses with a nice-sounding wrapper around them. Forecasts? Same thing. 

​

Demanding predictability creates a set of predictable dysfunctions

​

Being forced to produce predictability warps reality and causes people to spend time and energy creating a façade that meets expectations. The common scenarios span a range of behaviors:

​

• Predictable plans - Comparing actuals to plans is deeply ingrained in many organizations who somehow think that the future can be predicted with accuracy, so any deviation from a plan is evidence of poor performance, and questioning a plan is viewed as “being negative”. Unfortunately, we live in an uncertain world. False certainty does us no good; it actually prevents us from making good choices and from achieving greater goals.  And punishing people because they didn’t guess correctly is a waste of time and discourages important learning.  Instead of demanding predictable plans, focus on articulating clear goals and clearly framing experiments, including how you will evaluate them, and be open to learning new things.

​​

• Predictable productivity - Managers love focusing on productivity and “efficiency” but frequently fail to consider the value that is being delivered. Delivering value is what is important, not how many “units of work” (like story points, which are themselves just guesses) were delivered. What is better: driving 100 miles per hour in the wrong direction, or one mile per hour in the right? Productivity is important, but tracking does not help to improve it. Instead, focus your efforts on removing waste and impediments, and clearly articulating goals. When walking a rough and uncertain path, it’s not how fast you go that matters but whether you reach your destination. To go faster, place smaller bets, run shorter experiments, and evaluate where you are more frequently; you’ll save time not having to backtrack later.

​​

• Predictable careers - Each of us likes to believe that we are on the path to success. The notion of a “career” is a story we tell ourselves about how what we are doing now is leading to something better. The problem is that we are not very good at anticipating the future, and we really have no idea of the kinds of opportunities we may encounter along the way. It may seem a bit scary that we really don’t know where we are headed, and that luck plays a large part in what we end up doing. The reality is that we cannot really imagine what jobs will exist in ten years, or even five, nor can we conceive that many of today’s jobs will no longer exist. So how to do we prepare ourselves for what lies ahead? By cultivating flexibility, by trying new things, and by solving hard problems and acquiring whatever skills we need to do so. In the end, adaptability and ability to learn quickly are the keys to success, not steadily marching to the beat of someone else’s drum. Just as with Scrum, we succeed personally by trying new approaches and evaluating the results, in measured experiments.

 

• Predictable agile transformation - “Transformation” is a word that I often associate with the phrase “magical thinking”: organizations seem to believe that they can predictively plan how they are going to “become agile”.  This is usually based on the misconception that agile is a process, or is rather like a tool, that can be “installed” or “rolled out” to an organization. It doesn’t work that way. Agility, or the word I think better captures the essence of what we seek, adaptability, is a cultural quality, a way of thinking and acting that deeply changes the way that people see and act in the world. It is not a specific set of practices or behaviors that can be adopted. It is a way of thinking and acting that involves continually seeking better results and better outcomes. As such, specific practices will change as conditions and skills change. We cannot plan how this is going to proceed, and as different teams have different challenges, their path toward agility will be different. There is no “magical” set of practices, roles, or processes that makes this easier.

If predictability is bad, what’s the alternative?

As manufacturers learned, “lean” manufacturing involved a lot more than installing andon cords to enable the line to be stopped; it relied on the cultural values that let any employee pull the andon cord if they see something that is wrong. In pursuit of agile cultural values, organizations will find that agility may look messy on the surface, as different teams make different decisions in pursuit of their own continuous improvement toward their own goals. What is predictable is the empirical approach that defines our path: making observations, forming experiments on how we think we can improve, and continually seeking better performance. 

When you embrace uncertainty, you open your eyes to new possibilities. You are no longer blinded by your pre-conceptions. Once open to the facts, you can see new opportunities, new solutions. 

​

​

​

​

​

​

​

​