How to Effectively Steal from Agile Part 5
Distilling the core of Agile-ness can help you achieve your goals.
The Digital Custodian R&D (Rip off & Duplicate) Department has been hard at work trying to find yet another way to steal from Agile. We’ve developed a process that leverages the core of Agile-ness, and we’re making this information open to the public for general consumption. We’re confident that integration of this core into your business framework can help you achieve your goals.
The hotline rang. Excitement was palpable. Sales and marketing were enthusiastic about a potential new feature based on recent customer feedback that could drastically increase sales. Using our strategic alignment and scoring system, the product team determined that this is what development should be working on. NOW!
Of course, there were some problems. First, the roadmap had already been established for the next 2 sprints. Second, the next sprint started tomorrow and it would be 2 weeks before work could even begin on the exciting new project.
But there’s a big difference between being a systematic dynamic Agile organization and a context-switching dumpster fire of chaos masquerading as agility.
I had been coaching the product and development teams for several months and their progress had been phenomenal. What was once chaotic and frustrating had become focused and performant. We achieved the transformation by starting at the strategic/leadership level. Then we created a workflow system based on Agile to implement the strategy. This new exciting project was an opportunity to test our system.
Could we handle shifting priorities without throwing the entire organization into chaos?
As you may have guessed already, Agile principles apply in this situation, too.
Let’s revisit the ordinal list to the Manifesto and the Principles that I created in part 1. The first four are what I consider the “values” of the manifesto, and the following twelve are the principles. The strikeout items were covered in the first article about “Communication” here, the second article about “Valuable, Working Products” here, and the third, “Simplicity and Sustainability” here, and the fourth “Team Behavior and Outcomes” here.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
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.
Seeking Combinations
Again, we’ll look for commonalities by inspecting the values and principles established by the manifesto. Let’s break them down by 4 categories:
People - Who is the value/principle referring to?
Action - What actions are suggested for the people?
Process - In what way will these people follow these actions?
Cadence - How often should the people follow this action for full effectiveness?
By using these four categories, we can capture the spirit of Agile in a concentrated form.
Distilled Agile Principle #5 - Responding to change:
From the ordered list, let’s take numbers 4, 6 and 13 and distill them down to a principle that is easily digestible.
Responding to change over following a plan.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Continuous attention to technical excellence and good design enhances agility.
These three are about responding to change and excellence.
Let’s break it down by extracting the words into the four categories:
People: (Not Specified)
Action: Responding, welcome, harness change
Process: Requirements, attention to technical excellence and good design
Cadence: Even late, continuous
People
Not much to say here. When it’s not specified we go with the understanding that it means “everyone”.
Action
In my mind “responding” is all about readiness to adapt to any situation. In context, the word “welcome” here means “Bring it on. We’re ready.” What I really love about the phrase “harness change” is that it’s about taking control of the unexpected and using it to your customer’s advantage. Distilled down, to me this means be ready, willing and able to change as quickly as possible.
Process
“Requirements” are the specification of the work with a definition of “done.” Overall, the requirements combine to create your plan, and as we all know, plans change. When plans change, are you able to maintain focus on “technical excellence and good design?” I sure hope so, because if you can’t then you are bound to fail. What’s more important than a plan is the system that handles changes to that plan while maintaining a high level of quality.
Cadence
Humans tend to resist change, so we need to accept that as a fact and work around it. When a customer wants to change the plan “even late” in the process, our natural resistance is amplified. The best remedy is to have an adaptable mindset and a system that supports it.
That leaves us with:
People: Everyone
Action: Be ready, change, focus
Process: Plans, design and technical excellence
Cadence: Always
Our fifth and final Agile Principle is distilled into:
Be ready to change plans while maintaining focus on design and technical excellence.
In the sprint planning session, the development team talked about the new project and understood the potential impact of the new feature. After some debate they decided to change the upcoming sprint to a 1 week sprint which would include a spike into the new feature. After this short sprint, the feature MVP was defined. When the following sprint began, the team was both able to begin the work and to complete it. A new level of agility was achieved. Yay!
Did everything go perfectly? Nope. The short sprint caused a backlog of work for QA, updating the sprint calendar was a giant pain, and there were other minor issues. The short sprint was an experiment to see if it could be done, and it worked!
Did they want to do it again in the future? Nope. In the Retrospective, we were able to talk about what they would do differently next time. The experiment paid off by being able to deliver the new feature and a potential new way to handle this in the future. Continuous improvement achieved. These teams gained confidence in their ability to change and adapt on future projects because they now have a workflow that will support a dynamic marketplace.
I coach leadership, product, and development teams to create a collaborative unified system to handle change. In leadership, we start with strategic alignment and assure the company priorities are transparent to everyone. This allows the product team to create an adaptable plan focused on the goals of the strategy. Then the development team can execute with the knowledge that they’re working on the most important thing.
That’s all folks! We have completed all of the five Distilled Agile Principles.
Thanks for reading, I hope this has helped you gain a better understanding of what it means to be “Agile.”