I kid you not this is how almost all software development plans are created. Watch the video…
- Are you developing software this way?
Then, ask yourself:
- What’s the desired impact on the organization and how will 7 red lines accomplish it?
- Is the impact worthwhile, will it be worth the investment?
- What alternatives are there to 7 red lines?
- What if 7 red lines don’t work? When will we find out? Will the engineer be able to tell us before they are fully created?
- What if the engineer was tasked with the desired impact and not 7 red lines?
- What happens when an organization has a culture of focusing on inputs and not outcomes (desired impact)?
- If we get in the habit of obsessing over tasks, are we more or less likely to think about outcomes? What impact is this likely to have on making worthwhile investments?
- In reality this meeting ususally takes place in the form of a telephone call where the client calls the “business manager” and asks for 7 red lines, who then calls the supposed “project manager” and asks for 8 red lines, who then tells the “engineer” to make 9 red lines.
- In any game of telephone the message never arrives intact.
- There’s no engineering going on if the decisions have already been made.
- Why hire an engineer/expert if we don’t want them to help decide?
- Simply put, the fastest way to get feedback on whether a task (like 7 red lines) will have the desired impact, is to talk about the desired impact and let the engineers provide their expertise.
- Even better, don’t ask for 7 red lines, ask for the desired impact.
- When 7 red lines have no impact, the engineer will be asked to make 7 blue lines, without a single thought about the desired impact.