Agile Advice - Creating High Performance Teams In Business Organizations

By Mishkin Berteig

Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular Agile Advice blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including "Agile Mining at a Large Canadian Oil Sands Company", "Crossing the Knowing-Doing Gap", and "Becoming a Professional Software Developer". Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.

• Language: English
• Publisher: Berteig Consulting Inc.
• Release date: Jan 6, 2015
• ISBN: 9780993606403

Book preview

Agility.

Part One – Basics and Foundations

I always find it surprising how many people talk about or try to use Agile methods without really understanding their basics or foundations. Part of this is due to the popularity of misinformed or downright incorrect videos (Scrum in Under Ten Minutes found on youtube.com), articles (Agile Requirements Management from blogs.ptc.com) or horror stories (Slashdot abounds with these). Part is due to the natural processes of information decay, otherwise known as the telephone game. I hope that these articles help to refresh your perspective on Agile.

As you read this section, I hope you will keep in mind the Agile Manifesto (on the next page)...

The Agile Manifesto

http://www.agilemanifesto.org

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

That is, while there is value in the items on the right, we value the items on the left more.

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

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 fact-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.

Change is Natural – Embrace Change

AgileAdvice.com: http://bit.ly/ZL80kD

A long time ago I did a detailed examination and analysis of the Agile Manifesto. I was concerned that it was written only with software in mind. I wanted to find out what are the underlying values and principles and find a way to express them that was neutral to the kind of work being done. I wanted to find values and principles that could apply to any kind of work! From that analysis, I created a set of statements that I called the Agile Axioms. Change is Natural is one of three Agile Axioms along with People are Creators and Reality is Perceived.

This article about change is one of my very early articles on Agile Advice. Yet I still consider change to be one of the most fundamental concepts that still is not understood by-and-large among management and project managers. The concept is simple yet radical: you can't plan out past a certain point. And if somehow you could, you would be filthy stinking rich because you could predict things other people couldn't. I assume, since you are reading this, that you probably aren't that wealthy and therefore, like me, you are bad at predicting the future. Here's why...

Kent Beck’s book Extreme Programming Explained: Embrace Change provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all Agile work. (By the way, the book is excellent.)

Change really does occur everywhere. Change is constant. A google search for embrace change or change is constant will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it.

Nevertheless, it is sometimes difficult to accommodate change when we also have a legitimate and deep desire to know what is coming next.

For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people’s personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an Agile team can focus on being able to respond to change while still reaching a goal.

Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a horizon of predictability. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability.

Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be wishy-washy, uncertain, indecisive, uncommitted or even rebellious.

The terms Agility or Agile work refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of Agile work disciplines and practices.

Iterative Delivery

AgileAdvice.com: http://bit.ly/10Q3kLr

This early article explains the most basic process element of most Agile methods: the iteration. When I wrote this, flow Agile methods such as Kanban didn't exist. All Agile methods broke work up into short cycles. Scrum called these cycles Sprints but when this article was written, Extreme Programming was still predominant and it used the term iteration. I find it interesting how Scrum terminology has taken over as the default terminology of Agile. Now, most people think of a Sprint, a Product Owner and a ScrumMaster as Agile rather than as specific to Scrum. Nevertheless, other Agile methods use other terms, and iteration was the common term prior to about 2010.

Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. Work can often be divided up so that the smaller pieces are valuable on their own – one piece per iteration. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.

For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An Agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighbourhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group’s goal of attracting new members.

In a business environment, iterative delivery allows for a much faster return on investment. The diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:

One can see clearly from the diagram that the non-agile delivery of value at the end of a project is also extremely risk prone and susceptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the Agile iterative delivery situation, an endeavour can be cancelled at almost any time and it is likely that substantial value has already been delivered. Note: the diagram shows Agile Value Delivered as increasing early on. This is due to the nature of the intense learning that occurs in early iterations. Later, the amount of work delivered in an iteration declines as the work moves to items of less and less value.

Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Even in this mode, the inspection process should include actual customers or users, if possible, so that the feedback is as valid as possible. Either method of dividing work allows us to do the work in iterations.

The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, in a software development environment. However, in other environments iterations could be so short that many occur in a single day, or so long that an iteration lasts a year!

At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.

Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.

Wikipedia has a good article on iterative and incremental development focused on software development: http://en.wikipedia.org/wiki/Iterative_and_incremental_development.

Important Words about Scrum and Tools

AgileAdvice.com: http://bit.ly/z623rX

Since Scrum is the most commonly mis-used and mis-understood Agile method (despite nearly ubiquitous training availability), I felt readers could use a kick-in-the-pants clarification on the reality of Scrum. As a consultant and trainer, I see and hear about Scrum being done badly over and over and over. This article is really about a very basic concept that most people don't understand about Scrum. For a summary of the Scrum process, please check the appendix at the end of this book. For the official definition of Scrum please see http://www.scrumguides.org/.

Ken Schwaber, the founder of Scrum, has a blog article that got some great discussion (http://kenschwaber.wordpress.com/2012/01/02/i-was-thinking/). In it, someone mentioned that Scrum is changing. Ken responded:

If you change the Scrum framework you just simply aren’t using Scrum and are probably cancelling some of its most important benefits.

Thank you Ken! I wholeheartedly agree. Every Certified ScrumMaster (CSM) class I teach, I emphasize the complete nature of Scrum as a single tool, not a collection of tools. Learning Scrum is about learning the tool, not learning how to pick and choose pieces of a tool. Let’s explore this metaphor of Scrum as a tool.

Consider a hammer. A hammer is ideally suited for pounding nails into wood. It has two parts: a head and a handle. If you take the parts and use them separately, they can still be used for pounding nails into wood… but they are very ineffective compared to the hammer (although better than using your bare fist). It is non-sensical to decompose the hammer and try to use the pieces separately. However, a hammer is not suited to other purposes such as driving screws or cutting wood. It’s perfection is not just in its form, but also in its proper application. Holding the hammer by the head and pounding a nail with the handle is ineffective. A hammer works through a balanced combination of leverage and momentum.