Honest Conversation with an Agile Purist – Part 2

The Agile Manifesto has been around for over 20 years now and is the biggest contributor to the evolving thought process for modern software management. Many have adopted the golden nuggets defined inside and now these firmly live as Agile mantras. Yet, like anything else, evolution keeps going and the theory eventually meets the reality of adoption. Let’s discuss some of these mantras and where the future has taken us.

#1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

This is one of the most powerful statements of Agile. All software is ultimately made for its end user and the user value from the software and its capabilities must always increase, otherwise why continue developing more software? That is the idealistic aspect, but the reality of software development is not just shiny rainbows and unicorns. What about managing costs? 

Let’s imagine a scenario where a company delivers value non-stop and is awesome at doing so, but the strive for perfection exceeds the company’s budgets. Or the market has slowed down. The company may take an initiative to reduce costs, for example, by overhauling the environments, merging deployables, or transitioning various enterprise components from one type of tech stack to another, and etc. These initiatives have nothing to do with the customer value aside from the ability to stay in business and keep the product live for the customer. The customer will click the same buttons and use the same functionality. And, the cost savings will probably not make it to the end user either. Software that works perfectly and beautifully and is well designed and enjoyed by customers may need a lift from the non-functional perspective. After all, if not done, the company may vanish and the value to the end users will disappear along with it.

So, the fact of the matter is that sometimes, priorities change. It’s the non glamorous part of software engineering. And the best we can do at that instance is focus on non-Agile things, like keeping the lights on. 

#2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Evolving requirements due to discovery is a big part of Agile. But, discovering something late in the development won’t win any accolades for many organizations. After all, the budgets and timelines have been defined, risks evaluated, and the only thing asked from engineering was the ability to deliver. Those are the expectations and not meeting them can be fatal for the career.

Even if all departments in the company are Agile, what is not Agile is an executed contract. It has concrete terms, and must be performed based on the terms defined. Yes, a business partner may agree to extend the terms if they believe in you, but what happens if they don’t? Is the organization comfortable assuming this risk from the legal perspective? Or from a public relations perspective?

Perfect software with evolving requirements and better experience and capabilities for the end user may not be critical for the partner. Speed of delivery, first mover advantage in the Market could be much more valuable.

#3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

This point has lots of merit and over the past 20 years of innovation into Cloud and DevOps has made some incredible things possible. For example, a modern release train. As soon as code is checked in and passes through the builds, it ends up in production, available to be consumed by end users.

But this striving to push the latest to the end user often makes matters worse. The biggest challenge – Quality. Frequent releases and rollbacks due to errors, increase in support cases, and pushing the developers into constant on-call schedules and late night bug fixes takes a toll on the staff that far exceeds the value delivered to the end user.  Often, it leads the org to self-implosion. After all, does the client really need something this fast? 

Most companies adopt Agile so their teams can work their regular weekly hours and still meet business needs. Many types of release trains do the opposite however. This bullet of the Agile Manifesto addresses the old ways of releasing software several times a year, and promotes a better way. However, 20 years later, we often face an opposite dilemma – deliverables that are too frequent create significant amount of stress and strain on the organization and the teams that run it.

#4. “Business people and developers must work together daily throughout the project.”

Sounds about right. Yet, which business people are we referring to here? Unfortunately, there are instances when business people do more harm than good and require being isolated from the teams throughout their Sprints to let the teams make progress. Protecting the team to get commitments done is critical.   

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

Motivation is not enough. Have you ever met an engineer who wanted to do everything from scratch, without using existing tools or solutions? An architect that proposed building something that already existed on the market and not within the company’s main goals? A product manager that had strong opinions in building something absolutely new, or maybe opposite just a blunt copy of a competing system?

Like anything else in software development, there needs to be a clear plan and trust needs to be more like “trust but verify”. Developers are creative thinkers and not surprisingly are so creative that they recreate the same wheel.

#6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Yes, while discussing, interacting, clarifying, or brainstorming. And absolutely no, when the teams needs to summarize what has been said, what was agreed on, and the list of action items that need to be handled. For companies, the worst thing to do for continuity is to trust that all the information rests in a tech lead or product manager’s head.  

However, the world is changing. Especially the post-COVID world. Remote work is here to stay and its become part of the software development culture so much so that without it, companies may find it difficult to hire new talent. So, while this bullet is true, it is so in the ideal world. In reality, teams are choosing their own way and medium of communication. Bringing everyone together face-to-face is becoming difficult and that means that everyone will need to adapt.

#7. “Working software is the primary measure of progress.”

Let’s pick at this a bit. The software could be working and doing the job for the end user, providing value, but carrying within its implementation a ton of technical debt. Yes, you can deem it progress, but don’t get fooled ignoring it.

Another scenario, the software works, but doesn’t do what’s needed. Progress? Maybe. Depends on whether it needs to be completely overhauled – one of those scenarios when the team makes one step forward, and two steps back.

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

This can be interpreted in so many ways. What does maintaining the pace mean? Does it imply team performance? Certainly the above mentioned is true as long as the team’s ability to maintain pace is not used as a metric of performance and judged erroneously by vanity metrics such as arbitrary story points, carry overs, or number of stories done. 

Why? Well, if you share a metric to the management you will be evaluated against this metric all the time. So keep those metrics internal to the team, and discuss the outcomes not the outputs.

#9. “Continuous attention to technical excellence and good design enhances agility.”

This makes sense. If software is developed and attention is not paid toward the tech debt or bugs, it is easy to envision that eventually they’ll grind the project to a halt. The challenge however is that most struggle doing that. How much time should be allocated to address technical debt? How many iterations of enhanced design are reasonable, especially if these do enhance user value? The answer as always – it depends…

The other consideration here is how do we define what is a “good design”? In the Agile world of discovery, good design evolves over time. Good design is not created from an initial conversation. Yes, there can be good instincts for creating a design that envisions and solves for future needs, but most of the time you get good design post factum – after the work is done. After refactoring and tech debt stories have been completed.

#10. “Simplicity–the art of maximizing the amount of work not done–is essential.”

This bullet needs a bit of help in explanation. The principle mentioned focuses around the need to eliminate any unnecessary work. If it’s not necessary, why work on it, why get it done? This is a reinforcement of the principal to deliver work that adds user value. However, this one also focuses on the need to drop the perfectionist mindset. Makes sense, but why word it as an ancient proverb?

#11. “The best architectures, requirements, and designs emerge from self-organizing teams.”

This is a bold statement. From one perspective we can envision that the people closest to the problems are best at addressing them, and it’s likely that the solution from the product side would be best. However, the architecture and design depend on the team member’s experience and knowledge. A group of inexperienced developers may be able to solve the problem, but could also create architecture that doesn’t scale, implementations that are tightly coupled, and design that’s hard to manage or inflexible for future needs.

This is where it’s important to provide teams with adequate quality advisory resources – software and enterprise architects, DevOPs, and Site Reliability folks, and many others who can help poke holes in team’s technical assertions.

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

Self-reflection and assessment is critical for continuous improvement, which in an Agile setting is done with regular cadence Sprint Retrospectives. Yet, let’s be honest about the regular intervals – this is too vague. If intervals are too big, let’s say each milestone, or quarterly, this simply may not work. Continuous improvement is about taking responsibility to address the very items that are identified for improvement. 

There are also scenarios when conducting an irregular assessment is extremely valuable and productive. For example, a post-mortem for each high severity support case can lead the team to make corrective actions to the very development process to help deliver products of higher quality.

While its easiest to just rely on the Sprint Retrospectives to cover all of scenarios, the best teams conduct Retrospectives, Reviews, and Brainstorm whenever they need them. If the goal is purely to conduct continuous improvement, regular Sprint Retrospectives are really more about enforcement – making sure folks actually meet and discuss improvements. In reality – this is the easiest and least involved commitment to working on improvement. There is no upper bound here. Teams can work to improve many areas all the time, but at some point, they need to stop improving themselves and actually get some work done.

Have you read Part 1 of “Honest Conversation with an Agile Purist?” Click the link below!

Honest Conversation with an Agile Purist – Part 1