The Agile Principle #7 bring us one of the paramount pieces of Agile, at least in its origin, which was software development. It says:
“Working software is the primary measure of progress.”
To be clear, by working software, what we mean is a tested software that delivers value to the user (even if the user is the next system), integrated into whatever code management system you have. That piece of software is now part of whatever functionality existed before, not breaking anything, and it’s ready to be shipped to customers or at least deployed into production.
Now, I have to ask you: are you working in a team and organization that ships code frequently? Or at least an organization or team where you can, at any given point in time, have a view of what’s developed?
Congratulations! If your team process and work fits into the definition above, you belong to a select group of agilists that embody this Agile principle. Select because indeed there are not many organizations that successfully applied this principle. At least not at scale.
To understand the challenges and possibilities, let’s take a quick look on the history and motivation behind the Agile Principle #7, as well as on what are the important points to coach for success as far as working software (or product) goes.
Talk is cheap, show me the code
Not a long time ago, and in a few organizations if you look hard enough, projects and product development were managed based on tasks and individual output.
The way work was structured was rather different. And tasks would be carried out in the best way to manage resources (infrastructure and things, but also people) for cost oversight. Work was split and represented into a WBS, or work breakdown structure.
A big dysfunction with the WBS is that you could have work “finished”, say, on the database or infrastructure, yet have no functionality to display. You would carry out work staggered, with database and architecture work first, UI work, development later, and test hopefully in the end of it all. And managers would usually cut corners and shorten the final phases (mostly test), because you know, we have to deliver at the promised date!
That means you could say atrocious things such as “The project is 70% done” and yet have nothing to show for. Needless to say, it caused all sorts of issues, because until you have 100% done you couldn’t know how the software, or the product, would behave. Test would come in the end of it all, so to add insult to the injury, a page on your browser could look fine and be tagged as finished, yet it would bug as soon as you click a button.
It was the sort of approach that bred unjustified optimism on the project and ended up with disappointment and with developers having to over explain themselves for something they, at the time, could not control.
This was a layered approach. Imagine a hamburger. Would you accept just the top bun? That’s just bread. Or maybe just the lettuce? Well, that’s just salad. What makes them a hamburger is all of them put together!
That dissatisfaction and experimentation paved the way for things like User Stories and inventive ways of “slicing vertically”, which meant architecture, development, UI, test, all have to happen, but for smaller parts of the scope. Instead of breaking work structurally, work was now being broken by functionality. That’s an important reason why Agile principle #7 was born.
You can now eat slices of your hamburger!
Coaching point 1: the problem is not technology; it’s process
If you work in any technology team you know that the amount of technology we have today gives no excuse to not operating in a “show me the software, not the plan” approach. And the Agile principle #7 reminds us of that.
Yet, you can still find the old waterfall approach on software and product development. And the reason is not a technology barrier, technology advanced fast. The issue today is process.
Many organizations still “manage their resources”, aka their people, in a siloed way. They have the Test department and the Development department and the Business Analysis department. All that limits how people can interact.
A great way to overcome the siloed approach is having cross functional teams and stable teams but be mindful here. Clearly you can coach teams to operate in a “working software as measure of progress” type of way. There are techniques to teach and benefits to reap.
However, I find the challenge is usually not a simple lack of knowledge. It has more to do with what people will lose (or they think they will lose) if they change their current approach to work. How roles got structured, the reward and communication systems in place, the cost centers. It is beyond team discussion. This is departmental restructure.
And whenever you need to help your organization to rethink departments the battle is never against visible elements. It’s about emotion, status and what can be offered in the new system that is better than what they had before. Otherwise, people will rebel or resist. You really need to access human levels here, and ideally ask people to be part of the change themselves, hear them out, and be ready to integrate their suggestions on how to move forward.
Coaching point 2: prototypes are good but not sufficient
Once again it might seem we’re just talking product development here, yet coaching for Agile principle #7 is about process.
Prototypes, mockups, proof of concept, all those things are great. They are also not new, and they existed before in the waterfall world. Many times, they belonged to a phase 1 or feasibility study of a project.
So prototypes are incredible useful for validation, but they are not exactly or not always working software. Remember we wan to eat a hamburger? Prototypes many times abstract important architectural pieces and lack test. They are meant to gather basic information by specific pieces. They help you answer certain questions.
To show you an example, I’ve worked with cardboard cellphones filled with pebbles to simulate look, shape and weight (yes, I’m from that time!).
Then what happened after the prototype was accepted? Back to developing in a phased approach. Back to eating different layers of the burger. And to be fair, that cardboard prototype said nothing about the complications of the cellphone architecture.
What agile software development brought in was the ability to develop incrementally. Complete pieces of functionalities able to live in the production space on their own. Fully-fledged work that passed all stages of quality and control. That means you can automate, test more often, de-risk faster and earlier.
That implies developers and testers and analysts all working differently and more collaboratively. That’s right, not only they spend more time together, but they also approach the design and implementation of their products in a more robust way.
So, once again, be mindful that you might be coaching for potential department restructure.
Coaching point 3: what about customer delight?
Yes, Agile Principle #1 talks exactly about that: delighting our customers. But that is not the only thing that matters, hence 11 more principles to give you context of agile.
Suppose you just created a functionality that your customer dislikes. Is it not progress? Learning that you were going in the wrong direction? Yes, that is. Eliminating paths to your development is progress. And hopefully this development is incremental, so you discovered rather fast and can course-correct without much fuss. And you can only learn that you are going in the wrong direction if you have something to show for.
And on the flipside, be mindful of the customer loving your products and functionalities… yet the quality is poor, the architecture is wobbly. We don’t do things just to satisfy the customer without giving thoughts on how stable the product is or how easier it will be for later modifications. You’ll pay the price later, because of course the product will change eventually.
Cutting corners on your working software in the name of the alleged customer delight is a misinterpretation of customer value. Value for the customer is not just their delight. Having a bank app that is compliant with regulations is value add for your customers, although they might be blissfully ignorant of financial laws. There is a lot of value for your customers that is not right “in their faces” and you should support your teams and departments to take that into account.
And with that, check out the post on Agile Principle #9, the one that talks about technical excellence.
