Are You Agile and Scared to Change?

Introduction

This is the most amazing thing: Many teams that use Agile practices have been told by their Agile coach that if they change, they won’t be Agile anymore. So, they don’t change, and their overcommitment, quality and deadline problems persist.

This article is a quick summary of what it means to be Agile, and a reminder that Agile means “Agile”!

What does it mean to be Agile?

Agile means:

1. You are following the Agile principles* (the intent, a useful interpretation, not to the letter).
2. You deliver work incrementally.
3. You routinely collect and act on feedback from your customers and lessons learned from your team (retrospectives).

Agile does not mean:

1. Only do what your instructor, book or manifesto told you to do to comply.
2. Don’t change any practice, because of what someone said.
3. Follow the Agile principles, steps or ceremonies literally.

Realize that what ever you change, you can change it back for subsequent iterations. You are not stuck with anything.

Here are some examples of teams using Agile to improve their lives, rather than just doing the minimum to look Agile:

• Backlogs contain more than user stories, for example, use cases and quality attributes.
• Backlog grooming can be a peer review using a standard, rather than just a ten-minute discussion so the team can get on with coding.
• Estimates contain more than story points, for example: effort, effort ranges, and assumptions.
• Teams avoid overcommitting sprints by looking at capacity as well as velocity.
• Teams sit down at the daily stand-up because they don’t want to stand.
• Risk management is added to the planning step.
• Integrated master schedules are used to coordinate multiple teams.
• Design information is recorded incrementally in the tools being used (e.g., Jira, Rally, Confluence, SharePoint).
• Existing role names are used if they work better for the organization (e.g., systems engineer, business analyst, project manager, technical lead). Agile does not mean that certain titles have to be used.

There is no limit to the changes that can be made while still maintaining agility. Great teams are not bowing to an Agile God (Agile authors) or web page, and they are not saying, “Ooh, we can’t use ABC practice because that is an old word.” The Agile Gods I have spoken to want the intent, not the letter, of Agile to be followed, but that message is not routinely heard.

Conclusion

• Be Agile.
• Meet the intent of the principles.
• Adapt Agile to meet your needs (really be agile).
• Try something, learn from it, revert back if needed.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link

 

---

*Agile Principles from agilemanifesto.org/principles.html

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.