How to Effectively Steal from Agile Part 4
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.
A normal Tuesday turned into a fire drill as a red light blinked in the IT Manager’s office. That only meant one thing: Big customer X has an outage. We had to solve the problem as quickly as possible. This was no ordinary outage. Not only was this our largest client but the contract contained steep financial penalties for extended downtime. We needed an ad-hoc cross functional response team right away.
I pulled key individuals off of their current projects and assembled them in a room. The IT Manager gave us the information he had which wasn’t enough to get to the root of the issue. More questions were asked and answered, but we needed more information from the error logs. Luckily, we’d requested an error logging service early in the project, and it was approved. Whew.
Then I did what any decent manager should do: I listened, I asked questions, and most importantly, I got the hell out of the way.
What followed next was a series of steps the team took to solve the problem. They narrowed down the possible culprits, found the root cause, and deployed a short term fix.
As a leader, the next question I asked was: How do we keep this from happening in the future? For me, that means: Retrospective time.
In the Retro, we were able to discuss the causes of the problem and come up with a plan to prevent it from happening again. More importantly, we used the experience as a template for future response teams. After each incident, we would address the critical issues and evaluate the response team’s performance, making us better every time.
As it turns out, we were demonstrating the 4th distilled Agile Principle. The Manifesto and principles address leadership and team behaviors that improve outcomes and increase the success of your projects.
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.
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
We can 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, I believe that we can capture the spirit of Agile in a concentrated form.
Distilled Agile Principle #4 - Team Behavior and Outcomes:
From the ordered list, let’s take numbers 9, 15 and 16 and distill them down to a principle that is easily digestible.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
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.
These three are about the team, their behavior and generating the best outcomes.
Let’s break it down by extracting the words into the four categories:
People: motivated individuals, team/teams
Action: Build, give, trust, emerge, reflects, tunes, adjusts
Process: Projects, environment and support, best architectures, requirements, designs
Cadence: Regular intervals
People
Breaking down “Motivated individuals” is complex because you can get into the ways you can use the intrinsic motivators: autonomy, mastery and purpose, to drive performance. Dan Pink wrote a whole book on it called “Drive” which I highly recommend. Since he’s covered the subject very well, and I’m sure you’ve applied all of the lessons, I’m going to assume your individuals are motivated so we can boil all of this down to one word: Team.
Action
For me, “build,” “give,” and “trust” speak to a larger topic: Empowerment. Empowerment is one of the six core values of the SLAKK, my hybrid methodology, so you know I’m a fan! Let’s use “Empower.”
The word “emerge” in this context is about “outcomes,” so I’ll use that.
Finally, “reflect,” “tunes,” and “adjusts” is all about Continuous Improvement or Kaizen. Kaizen is the foundation of SLAKK and a part of many other methodologies, so “Continuous Improvement” will stay.
Process
When I read the words “environment” and “support” in the context of the principle, to me, that’s about equipping your team for success, so let’s go with “equip.”
As for “architectures,” “requirements,” and “designs,” this is about the outcomes we hope to achieve. We used that above, so we’re good here.
Cadence
I think it’s good that “regular intervals” is non-specific. It requires you to determine proper cadence. This idea is wrapped in the concept of “Continuous Improvement”, so I’m just going to go with that again.
That leaves us with:
People: Team
Action: Empower, Outcomes
Process: Equip
Cadence: Continuous Improvement
Which brings me to Distilled Agile Principle #4...
For the best outcomes, empower the team to self-organize, properly equip, and practice continuous improvement.
When I think back to that customer outage, I feel like we embodied this principle. I didn’t tell anyone what to do, they knew what to do. If I had stood over someone’s desk waiting for an answer to every question, I would’ve added to the stress of the situation. The team knew what to do, and I needed to be out of the way.
Fortunately for our team, leadership prioritized the expense of the error logging system. Sometimes financial restraints hinder a team’s access to the tools and resources that are essential to strong outcomes. In this scenario, allowing the team to properly equip paid off in a tremendous way.
Every problem is an opportunity to improve. If we had decided to high-five each other and call it a day after the short-term fix, then we would have encountered the same problem again. Unless you take proactive steps to avoid potential problems, you’re setting up your team for failure.
I help teams by coaching their leadership on how to apply Agile principles like this one. The typical response to the problem described here is to bear down on the team and push them to a solution. This causes more pressure in an already stressful environment and is counter-productive. By empowering your team and giving them what they need to be successful, you’re granting them the freedom required to be creative problem solvers. When you couple that with a robust continuous improvement framework, you can only succeed.
We have completed the first four Distilled Agile Principles, stay tuned next week for Part 5 of 5.
Stay tuned next week for the final installment of Distilling Agile.
