By Chris Foley
Let's consider the 12 Agile Principles.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
How soon after build initiation is software made available to the customer for feedback?
Do we have a regular delivery cadence?
How do we know that the software we are delivering is valuable?
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Do we establish the product backlog up front, or do we work with the customer sprint by sprint to build an emergent backlog?
Do we use change control boards? Change approval boards? Change requests to control deviations from plans agreed at the start of the release?
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
How often is software delivered into an environment that allows an end user to use and asses the features? (No, the content does not need to be commercially viable.)
Daily? Weekly? Monthly? Every quarter? Longer?
Business people and developers must work together daily throughout the project.
Do we promote daily interaction between the business and the development team ?
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
Do we facilitate the development teams to plan and execute the work required to deliver the product?
Or do we manage how much work should be taken into each sprint?
Do we estimate the work on behalf of the team?
Do we discourage all team members from attending meetings and discussions so that they are not distracted from "doing the work," hence "making the team more productive"?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Do the team members meet daily to discuss commitments and impediments?
Do the team members refine the backlog together so that everyone has a common understanding of needs and criteria?
Do the team members work as a team to support one another?
Do team leads do the analysis? It is more efficient to tell the junior team members what to do?
Do we have a project manager/release manager who works directly with the development team, and across teams to manage the work ?
Working software is the primary measure of progress.
How do we measure progress?
Do we measure Individual performance?
Are velocity and the number of delivered story points a key measure of progress?
What is "working" software? Do we all understand what needs to be completed to meet a Definition of Done?
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Is work organized into increments, where everyone understands the repeatable cycle of planning, analysis, design, implementation, documentation, and verification in each increment?
Or perhaps the work can't be organized into increments. The work is done when the work is completed, right? (Working software over artificially fitting things into a sprint.)
We always need to work longer hours to get things completed and delivered. It's the way we always do it, and we always deliver on time.
Continuous attention to technical excellence and good design enhances agility.
Do we continuously look to find new ways of doing things better? Perhaps there's only one way to do good design — the tried and trusted way.
Simplicity — the art of maximizing the amount of work not done — is essential.
Do we minimize the amount of work in progress?
Do we start work, bring it as far as we can, and then start other work? We avoid wasting time by having lots of work on the go. Waiting for decisions doesn't prevent other work from getting started.
If we use sprints, do we complete work within a sprint?
The best architectures, requirements, and designs emerge from self-organizing teams.
Are architectural designs and strategies agreed upon up front, outside of the team?
Do the architects who design the interfaces work closely with the team to see how the design is used, and then adapt and progress the design accordingly?
Does the product owner work closely with the entire team to discus high-level needs and criteria?
Does the team work together on the analysis and design and work closely with one another to review one another's work ?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Do we actively participate in retrospective discussion to agree on what we are doing well and where we need to improve?
Do we retrospect daily . . . sprint by sprint? at the end of each product release ?
It's not easy to be truly Agile. We are always learning. Always striving to become more Agile, sprint after sprint. It's more than a journey. We know where we have come from, but where we want to get to will always keep changing. The best we can do is keep striving to "become more Agile" . . . and there's plenty that we can all do to be "more Agile."