This agile principle probably speaks easily to software developers. It might be less easy to understand from the point of view of management and business. Nonetheless, as with the others, the agile principle #9 is an important one and it helps complete the full picture proposed by the agile manifesto.
“Continuous attention to technical excellence and good design enhances agility.”
The customer does not care about software. True, and…
I’m not sure if you notice the same, but I find a ton of people these days like to play the game of taking the agile principles out of context. They are 12 and they go together. But if you forget that, by the time you got to principle #9 you are hard press to think it’s about why should be spend time being precious about writing code. “Software is not what the customer asks for”, they say. Or “The customer doesn’t care about the software”.
Not true. They care, they just don’t know they do. Technology is important and implicit in what the customer cares for. You wouldn’t like a dishwasher that breaks all the time or is super noisy, or a camera that is constantly out of focus.
It is true the customer, unless it’s a technical one for technical problems, also doesn’t understand technology, especially software, and what goes in it and how it can affect their lives. They do however remember technology when a hardcore law or a creepy move from an organization makes them exposed to the reality that the world today is software, and software is spying on us or helping us.
So yeah, the customer doesn’t know or doesn’t understand it, but the craft of software making will impact their lives. The first iPhone took almost 3 years to be built. Now 2 versions come out every 6 months. Without great design and craftsmanship, this would not be possible. This speed when tending to the customer is only possible when great engineering practices are present.
And it wasn’t always like that.
Shortcuts and bad scope of decisions
When traditional project management was the rule, the project steps were rather phases, one arriving after the other. In there you would have 2 months to think about a problem (analysis). Then 2 months to implement it all (development). Usually, the time allotted for actual development was never that much and shortcuts were encouraged. After all, “we’ve got a date to hit”.
Also, when change requests would arrive, questions would be asked if they could be done “quick” in the name of arriving at that date no matter what. And then “we come back and fix that later”. Except that later never happened.
When the “quick and dirty” approach was encouraged, terrible software was created and it was more and more difficult to maintain. Talk about delivering value with “dirty and cheap”! Not possible. In fact, I addressed this briefly when talking about agile principle #1. There’s a lot of value that can’t be seen, like when your data is properly protected and when the software can offer you new features at virtually almost any time, to keep up with changes in your market.
There are a lot of decisions that belong to the world of business and teams should be kept in the loop and gain understanding of that world for servicing their customers. But managers who do not understand how software is developed can’t simply make decisions that jeopardize the ability to produce great product in the name of a short term gain. There should be dialogue.
Also, so that the opposite would not occur. Which we’ll cover next.
Technical ivory tower
Technical excellence is not being in an ivory tower where the product will never be finished because we keep polishing the silver. Where the “beauty” of the software is more important than its ability to serve the customer. There are tradeoffs in technical excellence and great design as well and there is a point of diminished return of investment. You know, that threshold you cross when making it “better” will actually cost more that bring value to the customer. That could be a misunderstanding of agile principle #9.
Sometimes you can be too proactive. You foresee success in the long run and for that you want to prepare your application right now to have 1 million users. Thing is… you don’t even have a 100 yet. You don’t know how the system behaves in totality; you don’t know necessarily which functionalities the customers will use more.
You can and should anticipate what you can in your design. But it should be a choice, a well informed one. Not a given.
That’s the challenge and something to be on the lookout for. While craftsmanship is to be encouraged, you don’t want to be too precious. The software part of the product is not there to amuse its creator. Have fun producing your work, but its not for your personal pleasure. It has a purpose, a function, a form and all devoted to the customer. When those are attained, even though we could keep adding more robustness to it, we shouldn’t be carried away. Because no matter what we do, changes will still happen and we should welcome them. And as we solve for current problems, we are always paving the way for future issues anyway.
What is and why technical excellence and good design
It’s not purism to call for technical excellence though. It’s just good business.
Technical excellence enhances flexibility, the ability to change code, to introduce and interconnect new pieces, which will always be necessary. Technology will change. Customer requirements will change. The more you can focus in making your software changeable, gracefully accepting of change_ agile there is_ the better for your ability to service your customers timely without compromising quality.
Do you know there is hardware and software right? Well, they are so called because one is hard to change and the other isn’t. That’s right, my friend, the soft in software speaks of its malleability. So, software should always be changeable. Easily changeable. By definition.
Not a house of cards that crumbles or cause pain when touched.
Now, how to get there? How to try and live agile principle #9?
Coaching for technical excellence and good design
There are many fronts to attack in the agile principle #9 and the first one is the level of knowledge.
A fellow colleague on LinkedIn talked about a definition that made me laugh, but that makes sense: “script kids”.
I’ve been one, when young and before college I would script things. That’s how I learned how to code. And I would create cool stuff! But solving my tiny issues with BASIC, then Java and JavaScript on my PC is not the same as working in a team of software developers in a professional setting. There are patterns and best practices (for a reason) and great theory behind a software that is made to last a long time and adapt to circumstances over time.
There’s a significant difference between school projects and a corporation-funded product. The expectations of what they can do differ and so do their impact. Knowing some technology is necessary. And so is how to best use it, not how to just whip a solution quickly.
So we want to encourage the organization to keep learning technological avenues. Conferences, courses, workshops. Managers should care for the development of the technical skills of their people. After all, doing the work is technical. It shouldn’t be something that employees should try and find time late at night after dinner.
Agile coaches and scrum masters should be creating the dialogue that encourages managers and developers to keep growing their technical abilities.
And in that dialogue, we are not talking about one or two developers. But how about the whole group? How can everybody keep growing their skills? How can the skills acquired on a project or after a conference be shared among peers?
We’re not looking at having 2 individuals as the expert in the organization. We are looking at self-sustained knowledge across teams, healthy organizations where we know people will eventually leave or at least change positions. The job of the agile coach here is helping people understand what resources they have or want to put in place to make their lives easier when enhancing the technical excellence of their teams and products.
And it can start with very simple things. It can start with agile retrospectives where the coach encourages the team (and managers) to take a look at what has been challenging this time around, to investigate some of the issues encountered, and start asking themselves how to avoid them next time around.
A Final Word
Many scrum masters and agile coaches today don’t necessarily come from the world of technology.
While they are not required to be software developers, understanding software development intricacies beyond analysis->design->development->test is important. It’s a sort of acumen that is needed and the more an agile coach understands the domain that they help (software, marketing, health care), the more insights they can offer. Remember the agile coaching framework. And if you want to recap a bit the difference between agile coaches and scrum masters, check out this post.
Now, non-technical agile coaches can also help their people to understand all that if they are excellent professional coaches. A professional coach, while might not be specialized in domains of work such as software development, is specialized in human thinking, in helping others to search for and to find actual paths for betterment in their careers and personal lives. They would, for example, observe that a lot of these painful events I mentioned throughout the post happen to the team, they would point that out and explore possible avenues for success with them.
Some of us lucked out, like me: I love development and had a career there before I became an agile coach and a professional coach. But you do have two great avenues to explore if you are just starting out.
What’s your experience with coaching for technical excellence among your teams?
