How to Effectively Steal from Agile part 3

Blog Graphics-06.png

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.


In my software development days, before Agile, a jumbled mess of incomplete and incoherent code was dropped in my lap when its sole developer left our company. It appeared that parts of the project had been started then abandoned for other aspects whenever the developer became stuck on a problem. Not only had I been given a knot of flaming snakes to unravel, but all the customer had seen were wireframes of the screens and no functional application.

The directive from leadership was, “Get it done, whatever it takes.”

I paired with a Designer/Front End Developer. Something had to get to the customer as soon as possible. We started one page at a time, one section at a time, crunching through opposite ends simultaneously. We kept it simple, assured it worked, then moved to the next section. This enabled us to present small demonstrations to the customer almost weekly.

The problem was we were heads-down for 55-65 hours per week for several weeks. This led to the most dreaded feeling a developer can have: burnout. Burnout can make rudimentary math seem more like calculus and a simple conversation an exercise in mental gymnastics. This level of exhaustion makes errors inevitable.

We made so many gains at the beginning, but eventually we hit the wall. Bugs piled up. Rework is a waste of time, and we had no time to waste. Clearly, this was unsustainable.

The good news is Agile can correct or even prevent this type of situation.

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 and the second article about “Valuable, Working Products” here.

  1. Individuals and interactions over processes and tools

  2. Working software over comprehensive documentation

  3. Customer collaboration over contract negotiation

  4. Responding to change over following a plan

  5. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

  6. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

  7. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  8. Business people and developers must work together daily throughout the project.

  9. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  10. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  11. Working software is the primary measure of progress.

  12. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  13. Continuous attention to technical excellence and good design enhances agility.

  14. Simplicity--the art of maximizing the amount of work not done--is essential.

  15. The best architectures, requirements, and designs emerge from self-organizing teams.

  16. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Seeking Combinations

We can extract commonalities by evaluating the values and principles. Let’s group them into 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?

 These four categories capture the spirit of Agile in a concentrated form. 

Photo by Mimi Thian on Unsplash

Distilled Agile Principle #3 - Simplicity & Sustainability: 

From the ordered list, let’s take numbers 12 and 14 and distill them down to a principle that is easily digestible.

  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

  • Simplicity--the art of maximizing the amount of work not done--is essential.

These two are about sustainable development and keeping things as simple as possible.

Let’s break it down by extracting the words into the four categories:

People: sponsors, developers, and users

Action: maintain, maximizing 

Process: sustainable development, constant pace, the amount of work not done, simplicity

Cadence: indefinitely

People

As I have done in the other posts, I’m going to trim this one down to as few words as possible. “Sponsors, developers and users” doesn’t really cover everyone does it? I mean, do you want Product Owners working at an unsustainable pace? Of course not. If someone is operating at an unsustainable pace, then at some point, they’ll hit a wall and become a bottleneck in the process. We want sustainability for all. So, I’m going with “all.”

Action

Our goal here is to maximize our efforts and maintain that effort. Maintenance of our efforts is achieved with a sustainable pace as we have discussed above. Maximizing our efforts requires focus. When you have the ability to focus on one thing at a time, you have the potential to create your best work. “Focus” is what’s important here.

Process

The two sections above mention “sustainable”, so that one stays. “Constant” is good but “indefinitely”, in the next section fits better, and we don’t need both. “The amount of work not done” to me is talking about the Lean concept of “eliminating waste.” One way to eliminate waste is to keep things simple. Attacking a complex problem without breaking it down into smaller pieces is just asking for trouble. Let’s not make this too complex and just keep “simplicity.”

Cadence

“Indefinitely”. That’s good. Let’s stick with that.

That leaves us with:

People: All

Action: Focus

Process: Sustainable pace, eliminating waste, simplicity

Cadence: Indefinitely

Which brings me to Distilled Agile Principle #3…

Eliminate waste by focusing on simplicity and an indefinitely sustainable pace for all.

I help teams identify and eliminate wastes in their processes, whether in Operations, Software development or another team. Once we are able to focus the organization strategically, we can then align the teams with their most important work, break it into simple functional pieces (MVP) and get that done first. By doing this we allow them to focus and deliver.

Along the way we collect data around workflow and sprint performance of the team and seek opportunities for improvement. To achieve an indefinitely sustainable pace, we assess their mental states and look for signs of burnout. In doing so, we limit the number of errors that could have been created which eliminates potential waste. 

Since I began my coaching career, I’ve had multiple opportunities to work with teams in a position similar to what I faced as a developer: unfocused and burning out. As Brené Brown wrote in Rising Strong, “In the absence of data, we will always make up stories.” It’s as true for leaders of companies as it is for workers on the front line. What looks like employee laziness or incompetence may indicate a different problem. When I present leadership with new data, they’re able to drop their imagined narrative and save their team from implosion by employing new strategic focus.


This is part three of a five part series. I hope you have enjoyed reading it.

Stay tuned next week for the next installment of Distilling Agile.

Previous
Previous

How to Effectively Steal from Agile Part 4

Next
Next

How to Effectively Steal from Agile PArt 2