Excellence as a Habit

I'm a big fan of quality. It's not that hard to understand that the user visible quality of the software is a necessity. If the customer is constantly disappointed, (s)he won't be a happy customer. And probably quite soon not a customer at all. But the visible quality is not all. Most of the time it's just the tip of the iceberg.

With software also the internal quality matters. How well your interfaces have been defined, how long/short are your routines and how much coupling there are between modules. If you know what you are doing (and you are the one who wrote that code) you might be able to navigate efficiently in a bit hairier spaghetti. But for the other non-swamp guide developers it can be much harder. Yesterday's code will be tomorrow's legacy. Keep that in mind.

But writing good quality code requires another kind of quality also. Quality in operations. Into some extent I believe this equals having skill and discipline. Again, I'm raising up the need for craftsmanship. For software development with multiple programmers and teams quality in operations includes also commonly agreed coding standards.

I have always found it much easier to define rules than to actually get people to follow those (although I'm usually working more in the implementation side than in the definition). People either forget, they haven't cared in the first place or simply haven't even been informed about the existence of the rules to begin with. So, there's value in both crafting the rules and in making people understand the value of the rules. Many times the rules are enforced by different actors than their creator, which is fine. Different people have different strengths. And finally: there's value in reminding people about the rules.

Systematic built-in quality in operations requires someone to take good care of the big picture. Practicing wishful thinking is not enough, someone also needs to see the evidence that agreed things really happen. Quality systems and audits are a practical way to see if the organization really plays by the rules it has set for itself. Some see them as heavy or bureaucratic, but frankly I think those people usually lack some self-discipline. If you play by the rules then someone watching over isn't hindering your progress. And if the rules suck, please help improve them instead of whining!

And it's also all so natural and fitting for Agile ways of working. Working software should be the sole measure of progress. And for example in Scrum it is shown at the end of the Sprint. Talk and PowerPoints are cheap, demonstrating new functionality rocks!

Instead of sometimes succeeding and most of the time being unpredictable, make excellence a habit. Learn the rules, break the rules, be the rule: Shu-Ha-Ri. And apply the same principle on all levels of the organization. Self-discipline is needed in the Development teams but also in the management. Dare not to expect something from the people working for you that you are not willing to do yourself. If you want people to walk the extra mile, be prepared to walk in the front.

Agile Poem

This time something completely different...

Let me amuse you for a while

and let's talk about Agile.

In this game if you intend to win,

you need a lot of discipline.

World around you changes,

you meet unhappy faces.

But you can still do great

just start small and then iterate.

You can occasionally even beam

if you have a trusted team.

And when assessing results do take care

the only measure is working software.

Telling like father to a son:

it's not finished until it's Done.

And the only solid fact

is that you need to inspect and adapt!

Agile and Military Methods

"What? Dude, your out of your mind! Agile methods emphasize individuals and are cool. Military stuff is all about hierarchy, command and control. Yuck!"

Well, that's one view and I don't really argue about the hierarchy and C&C. But I do find a lot of similarities also. If you need to lead people in battle, the level of trust between you and your team needs to be high. You need to show example and as a leader you go always in first. Would be nice to see the other people following. Your people need to trust you and you need to trust your people. I believe that's a characteristic of efficient Agile teams also. Although in an ideal Agile team everyone is a leader.

And really army and the command and control part is not so black and white. Setting goals instead of giving specific instructions works best in both worlds. In software development requirements change and the only reasonable thing to do is to embrace this change. In his book Management 3.0 Jurgen Appelo summarises agility as

"Staying successful in ever-changing environments." 

In the heat of battle it is probably also safer bet to adapt to the current situation than to follow a predefined plan. US Marines and special forces like Navy SEALs operate with small yet effective teams with no centralized control.

The final example is maybe a bit more far fetched, but maybe just for amusement. If you are familiar with close-order drill, you know that it is a training where certain action is trained repeatedly. After each command the trainer will give feedback about the execution. Now my boldest comparison is between these drills and Sprints/Releases. After Sprint, there is a Review where the results are inspected and the team should get feedback. Improving the actions of the team happens in Retrospective. Iteratively the team improves its execution. Only in this case the whole team acts as the trainer (Scrum Master can catalyze the process).

And finally, practice and discipline are the basic requirements in both. Real professionals keep their heads cool and write those tests before making changes! Regarding discipline, I think the people in software development should take inspiration from the world of military. Lack of discipline in implementation seems to be a common stumbling block for many Agile adoptions. I think the pragmatic programmers and Clean Code movement have understood the significance of practice. Mastery doesn't just appear. It is earned through practice.