Axioms are self-evident truths. The axioms of Software Development isolate key basics underpinning successful software development. Knowing and using them helps resolve the problems associated with coordinating developers, time and resources, ensuring your software project will be successful and provide a return on your investment.
This is part of the series on the Axioms of Software Development. If you haven’t read them all - you can see them here.
In part one of this series, I discussed the most important axiom; Axiom 1: Desired features ALWAYS exceed available budget. If you haven’t had a chance to read it, please go and read it first. These axioms build on each other and understanding the first axiom will make understanding the subsequent ones easier.
Here is the next axiom:
2. Communication is King
This seems simple, but it’s true and often overlooked. Because features will always exceed available budget, you have to make sure you are communicating enough to overcome that challenge, and thus, the next axiom is “Communication is King”.
Too often I see software projects sending the developer off on their own to build something. The developer comes back two weeks later, and the client says, “Um, that’s not what I wanted.” This shows there is a lack of communication between the developer and product owner for that two weeks.
You must keep communication very, very high between the stakeholders of a software application and the developer. That means lots of deployments and demonstrations while the software is being built. Lots of updates in chat rooms or screen shots of designs and progress.
Whatever Works in Keeping Communication as High as Possible
Communication is the most important thing that will derail a project. (Outside of the client expecting all the features for no money.)
If communication drops out, the client starts to feel ignored. They don’t have any reality of what’s going on anymore and because they don’t have any reality of what’s going on, their love of the project will start to drop. In a month or two the whole thing blows up in your face.
We have rules in reinteractive where our developers need to be updating the client two or three times each day on what they are doing and where they are going with the project. This usually is done as follows:
- A morning text update as the developer is starting work “I plan to work on points A and B today”.
- A stand up call with the client (preferably with the video on) to go over any issues or blockers or to clarify things with screen sharing.
- A mid-day update “A is done, I’m now working on B”.
- An end of day update “OK, B is taking longer than expected will continue tomorrow and will get onto C as well. I’m heading off in 15 minutes if you need to ask me anything”.
That level of communication keeps our client engaged and up to date. Some of you might think, “why bother with a morning update if it’s basically the same as the evening?” Well, it turns out that quite often, that overnight, after the developer has stepped away from the task and woken refreshed the next morning, a new way to tackle said problem has materialised. Also, the morning update reassures the client that we are working and active.
We put all of the work we are doing into stories in our task tracking system so that the client sees what’s happening. Clients are constantly reviewing and accepting the various stories through the various changes.
Working out Key Performance Indicators
After finding this axiom on communication, it helped me resolve another problem I had, which was trying to work out the key performance indicator (or statistic) of a developer. I had spent quite some time trying to work this out.
When you go out to the market and ask people what the KPI of a software developer is, you get back answers like ‘hours of coding delivered’ or ‘lines of code’, or something of that nature. None of that really worked for me. Because if it’s lines of code, the way you achieve a better KPI is to just hit return on your keyboard more often and make the lines shorter. “Hours spent coding”, well that’s obviously not the right thing either because one way to increase such a KPI is to get worse at coding so it takes you longer. So, neither was right.
The KPI I settled on is “features delivered and accepted as done”, with no regard to how big or small the feature is. It’s just the number of times a software developer delivers an item of work that is then accepted as done by the client of that project.
This creates a very interesting game dynamic between the client and the developer. The developer will want that KPI to go up as high as possible. When creating a sign-up form, it will be broken into 10 different stories, 10 sub-features. That’s totally fine. Because that forces the developer and the client to have a higher rate of communication. The client now has 10 features to review and accept on the various aspects of that form and it gives the client more opportunity to say, “Oh - we forgot number nine”. As opposed to ‘Oh, yeah, the sign-up form kind of looks like it works so I’ll hit accept”.
So, it actually increases the communication level between the client and the developer, which is something we very much want, and the client is saying “Yes this is good”, many, many more times during the development process.
The KPI of our developers: “number of features delivered and accepted as done by the customer of the project without regard to the size of the feature”.
What I mean by “without regard to size” is you might have something like, “implement the dashboard”. The developer might say, “Well, that’s a feature worth 20 points”.
Don’t do that. Don’t assign a different value to different features. Just make every feature worth one point on their KPI. And if you do it that way, the developer will drive the size of the feature down, because they want more points. And that will drive the communication level up with the client who must review and accept each one. It is a great way to keep that communication high.
And keeping communication high is something your clients love. The feedback we receive says they feel they are always in control and know what is going on with their software build.
Are These Axioms Helping You?
I hope you are getting value from these axioms. Please send me through your feedback and thoughts.
