•November 18, 2019
I was recently pointed by some colleagues to a paper/article I co-authored 17 years ago called “The Rules of the Game.” As I re-read the paper, I was amazed at how relevant it still is, even with the advancement of tools that we enjoy today.
I’ll refer to it as I attempt to point out the key points that I have found contribute to the ultimate success of an investment in custom software development.
The six rules we identified in the original paper were about Extreme Programming. But let’s look at them now, and remove the words “Extreme Programming” or “XP”. If we ignore the fact that they were originally meant to help understand whether you were “Doing XP” or not, and instead consider how important each “rule” is in the success of an investment in Custom Software, we have a fairly concise list of important points.
Let’s discuss each briefly:
E1. [The Team] consists of a group of people dedicated to the production of a software product. This product may or may not be a piece of a larger product. There can be many roles on this team, but there must be at least a [Product Owner] and a developer role.
Rather than a master/servant relationship, it is important to have everyone recognized as a valuable member of the team, no matter who is paying the bills. It is also important to recognize that someone (or group of someones) needs to be responsible to identify the target, and someone (or group of someones) needs to work hard to hit the target. In the original language of XP that would have been called the “customer”, but it has generally evolved and accepted to be known as the “Product Owner”.
The target may (and almost always is) moving to some extent. The product is being built for some set of target users to accomplish something in a better way than they can without the proposed software. The beneficiaries of this improvement can be singular or many. The reality is usually that one of the beneficiaries is funding the effort. They are a “stakeholder”. They may be:
There could certainly be multiple stakeholders.
If the goals of the stakeholders include pleasing some set of ultimate users of the software (perhaps a customer of theirs), the Product Owner should have a pretty good idea of what might achieve that goal. They need to be (or quickly become) a Subject Matter Expert (SME) that has the stakeholders’ interests in mind. Getting real user feedback to validate that the goals might actually be met is invaluable.
Could there be a group of Product Owners? Certainly, as long as the group can figure out how to clarify what needs to be done. At the end of the day, if it is not clear who the Product Owner(s) is/are or how to figure out what they intend, you are doomed.
That doesn’t mean the Product Owner is all-knowing. Jim Highsmith referred to one study that showed initial requirements are typically 15% complete and 7% accurate. If the Product Owner were four times better at defining requirements than that average, that would make them only 60% complete and 28% accurate. And even if they were close to all-knowing, there is the problem of perfect communication to the developers who are not.
It is also important to recognize that the developers (the ones who produce the software) have an understanding of how to build software that the Product Owner either does not have, or does not have the capacity to execute. The developer is a “subject matter expert” of a different subject. They also have a communication challenge in conveying their knowledge sufficiently to the Product Owner.
That leads to…
E2. The [Product Owner] must set and continuously adjust the objectives and priorities based on estimates and other information provided by the developers or other members of the team. Objectives are defined in terms of what, not how.
“Priorities don’t matter as long as you get everything done.” I’m not sure who first said it, but the reality is that you will rarely get “everything” done and you will never get everything done at once. I’ve heard it said that “software is never done, it is only released.”
When a project is started, you are the least intelligent you will ever be about what really needs to be built to hit the target. As what is asked for is manifested in working software (or not quite working software) new realizations will come to light. You are on a journey in a dynamic world. When you start, you are trying to hit a fuzzy point on a horizon. But there are two things you must consider:
E3. The [Product Owner] is always available and supplies information on demand to assist developers in forming estimates or supplying desired deliverables. The [Product Owner] is an integral part of the team.
Due to the nature of all of the above, as developers tackle tasks, new questions will come up and new discoveries will be made. If decisions about how to respond to those questions or discoveries are left to the developer, who presumably understands the implications less than the Product Owner, they could go down a wrong path.
In the last two weeks, I saw a requested feature derailed twice when a developer who thought he understood what was needed came up with a “different” way to deliver what they thought was requested.
The first time, the Product Owner wasn’t in the room when the developer came up with an alternate approach to the problem that would be simpler than what had been discussed. Instead of validating that this simpler approach could work with the Product Owner, they asked another developer if they thought it would work. The second developer agreed that it would be simpler. The developer then spent a day working on it, when the Product Owner checked back in to see what kind of progress was made. As soon as the “simpler approach” was explained, the Product Owner instantly recognized a side effect that this approach would cause that would undermine the integrity of the system. He pointed that out to the developer, who recognized they needed to start over.
Due to unforeseen circumstances, that developer was unable to continue on the project, so a new developer took on the task. They sat down with the Product Owner who explained what was needed and why the “simpler” version was counterproductive. The new developer understood the parameters and “got on it.” Again, the Product Owner was distracted for a couple of days. The developer felt that the UI that had been sketched out would not work in certain cases and came up with an alternative. He went down that path for a day and then, when the Product Owner became more readily available, reviewed it.
This time the Product Owner saw that the new UI would be more cumbersome for the 95+% case, and confusing for the remaining 5% case. Two days of development were spent on wrong paths because the developer and Product Owner did not have a tighter feedback loop.
Whether it was the developer’s fault for being presumptuous, or the Product Owner’s fault for not being more readily available is not important. The fact is that the longer the feedback loop between Product Owner and developer, the greater the possibility of efforts spent on misunderstandings will be.
In my 35+ years in the software industry, I can point to the projects that got the most “bang for the buck”. They had two key ingredients:
The Product Owner would wisely push pause when direction on a certain feature or task was not clear or respectfully challenged, redirecting developers to work on something that was more clear while they sorted out the details needed to get clearer/better direction on the feature or task.
I recognize that perfect combination is hard to find.
A strong, experienced Product Owner with an inexperienced development team and low customer empathy can sometimes keep the developers on task with some level of success.
A humble, inexperienced Product Owner who is always available with a strong, experienced development team can come up to speed pretty quickly and also achieve some level of success.
A strong Product Owner who is not quite always available can also succeed if they have an experienced development team with strong customer empathy.
But woe to the rarely available, inexperienced Product Owner with an inexperienced development team with low customer empathy.
E4. At any point, any member of the team must be able to measure the team’s progress towards the [Product Owner]’s objectives.
If the objectives are not clear, people will get caught up in whatever interests them at the time. We try to make it clear what “success” looks like in both the short and longer term, and make sure everyone knows what they are. For example, “by next week, we’d like to be able to 3D print a guide that can be used in surgery for a normal (90%) case.” There could be all sorts of questions about the best UI for a feature, the optimal way to store something in a database, the nuances of an exceptional case, and many more interesting items to discuss and explore. Having clear objectives can keep all those discussions and explorations at bay.
Anyone on the team should be able to ask, “How does [whatever you are working on] help us meet our current objective?” And, anyone on the team should be able to recognize “we’re halfway through the time allotted to achieve the objective, and it doesn’t feel like we’re anywhere close to halfway to the objective. Something has to change… either our focus, approach, or the Product Owner’s expectations. Time to raise a flag.”
The worst waste of money I ever saw on a software project was due to high level managers stating outrageous objectives, and not wanting to hear anyone raise concerns about whether they were achievable. A three month deadline was given at the beginning of the project. It was clear that you could not question the deadline or suggest that we pull back some of the grandiose objectives. When the deadline came, and the objectives weren’t met, someone in the management chain would get fired and a new deadline would be set (typically 2–3 months later) without asking the team what really needed to happen to meet the objectives or how to scale back the objectives to make the deadline achievable. Tens of millions of dollars were spent over the better part of two years with about 7 deadlines that were never met. None of the grandiose objectives were met either by the time someone finally decided to stop the madness and abandon the project.
E5. The team must act as an Effective Social Network, this means:
When something is harder than was hoped, communication happens that raises the flag and discusses the reasons. People who might be able to effect alternative approaches (e.g. more modest objectives, a different angle, or more/different resources) need to discuss it.
Reality is going to hit people in the face eventually, so you might as well embrace it early to work through the challenges.
Realize that you will be (or at least should be) smarter as you go, but only if you embrace what you find and incorporate it into the effort to meet the objectives. The Product Owners, the developers, stakeholders and others will all be learning, and identifying puzzle pieces that can be helpful in achieving the goals. Encourage them to share what they learn so they can put the puzzle pieces together. The discussions had in working through the problem together may (and often do) turn an arduous task into an achievable one.
Giving a team of ten people each ten pieces of a one hundred piece puzzle, and then asking them to work independently to put the entire puzzle together would be ludicrous. And making them go through some grand ceremony each time they might suspect the other can help them in the name of “protecting their time” is ludicrous, too. Make sure everyone is aligned to the same objectives, and trust them enough to manage their own time to help get there. If something is getting in the way of effective communication address it. You will not achieve your goals if the people holding the puzzle pieces can’t freely collaborate.
Don’t tell someone they are responsible for getting a job done, and then put a spending freeze on them, or tell them they need to use a certain set of technology because the IT department has standardized on it if they have a good reason that using the technology would jeopardize that stated goals. Ask them what they need to get the job done, respectfully question if there are alternatives that might be more cost-effective, or have better side benefits, and then enable them to succeed.
Giving someone authority to go with the responsibility they are given may or may not work. Not giving someone the authority to fulfill the responsibility they were given is doomed to failure.
Many years ago, at a previous company, I recommended a brilliant young overachiever be interviewed for my team. I was told that we had no room for him in the budget so the interview was denied. But a few weeks later, I was given a “new hire” on my team. Another manager had hired him and he somehow got him assigned to me, even though I had recommended against the particular new hire. The new hire was the owner’s nephew. Nice guy, but totally incapable of contributing to the task I was given or pretty much anything we were doing at the company, and he was given no training. He had also been hired at twice the salary for which I thought we could have hired the overachiever. A few weeks later, the president of the company confronted me about the cost of my team and why he hadn’t seen the payback. Somehow I managed to calmly explain that I didn’t ask for the overpaid new hire and he wasn’t capable of contributing. I suggested the fastest way of getting things back in line was to fire the young man we never should have hired. He said, “I may be dumb, but I’m not stupid. I’m not going to fire the owner’s nephew!” He never explained how I was going to be able to reduce my budget.
So, I ended up doing the only thing I had the authority to do. I left that job and started my own company. That’s the kind of thing people do when they feel like they are caught between a rock and a hard place.
E6. Timeboxing is used to identify segments of development effort and each segment is no more than one month in duration.
I’ll assert the following:
Sometimes I am presented with a problem, and confidently go in a direction that leads to a dead end. I am worth zero in that hour. (Though my education has value that could be helpful later).
There are some hours that all of my years of experience culminate in being at the right place at the right time to solve a problem, and I am worth thousands or tens of thousands of dollars for that hour, just like Charles Steinmetz.
Henry Ford once balked at paying $10,000 to General Electric for work done troubleshooting a generator, and asked for an itemized bill. The engineer who performed the work, Charles Steinmetz, sent this:
“Making chalk mark on generator, $1. Knowing where to make mark, $9,999.” Ford paid the bill.
If I tell someone a software project is going to cost on the order of $250,000 to $500,000, and they decide that it is worth the risk to spend that kind of money to receive what they expect to be a greater reward, it is unreasonable to expect that they’ll just write a check for $500,000 and schedule a meeting for 6 months later to see how it went.
On the other hand, it is unreasonable for them to break the perceived value into rough hourly tasks that would each be worth $250 until it added up to $319,750 and the big spender got exactly what he wanted.
A much more reasonable approach might be to spend some time to explore the problem space and then break down the value into milestones that can be checked along the way. Being too stringent on every detail of those milestones would be counterproductive (see most of the discussion on the previous rules).
Put objectives on every iteration of a reasonably-sized timebox to get things done. Make sure everyone knows the objectives and agrees that they are reasonable and worthy. Recognize that adjustments will be made as the team learns. Expect them to flag any big surprises anytime they occur, and what is being done to mitigate them. Get a summary of where things actually are at every milestone, and have the team adjust accordingly.
At RoleModel, we tell our clients that it is both of our jobs to manage the budget together. We both need to be prepared to make trade-offs as we learn new things and share what we learn. If things look we’re not going to achieve major goals, we may have to scale back our expectations and cut out some valuable but non-essential features. If it looks like we may be able to achieve major goals sooner than expected, we discuss whether we should just come in under budget and be satisfied, or add some other value added features that we didn’t think we’d be able to get.
By having a good cadence for communication about budget and timeline, nothing should ever go to far from expectations in either direction, and micro-managing should be avoided.
These rules of engagement are somewhat timeless and are really rules of a healthy relationship between people of different talents working together to achieve shared goals in the complex world of software creation… turning hard-earned expertise into a high impact asset — that can exploit that expertise — from scratch.
Following these rules of engagement will get you far with respect to desired features, and managing a budget. However, none of what we discussed really addressed the implications of long term quality or the ability to quickly adapt to things you continue to learn over time.
For that, we’ll need to address the “Rules of Play”. I’ll do that in another article.