This is mostly an experiment in two things: A) PowerPoint slide reductionism and B) free infographic tools available on the web. But the result is kinda fun and quite honestly even though it’s sketchy UX work at best it’s still kinda pretty looking by my standards.
Many people would answer my questions in the software weatherman, part 1 with a “yes, go for it” and many people would say “nope, not worth the risk.” I’m not sure there is a right answer on the surface. Perhaps it will be OK to risk it and perhaps not. But if you are at all concerned with wasting the extremely expensive paint by taking this risk, you probably don’t go for it.
Software is developed in a similarly risk environment. Software is painted in the outdoors, if you will. You have to be concerned with such inherently unpredictable things as the weather.
This is good news.
If you work with your business to understand how software is created and how features grow into a product, you will create a shared understanding of the complex, creative, and at times unpredictable process of creating software.
The more they understand this, the more they understand the environment in which you create software, the more honest you can be about forecasting the work. The business / your Product Owner / your customer already knows that they have bought some extremely expensive paint, and you can bet they do not want to waste it, or risk having something not be done and done right.
With this context in place, you’ll find it orders of magnitude easier to have those tough schedule/budget/scope conversations with stakeholders. Your job is software weatherman, forecasting the project in an environment of uncertainty, more sure about the next day’s weather than the next month’s, and treating your estimates as nothing more than a forecast.
Now, this doesn’t mean you are off the hook. Even a rookie weatherman can predict the weather with some certainty. They know it’s cold in winter and hot in summer. You as a software weatherman have the responsibility to forecast in at least the same way. It’s not acceptable to your stakeholders to hear things like “there’s no way to know” or “we all used the infinity card in planning poker” or “it’s so complex and there are too many unknowns.” Even a rookie software developer can tell if something is a week or year worth of work. Step up, and in the context of giving forecasts, give one! You will modify it later as you learn more, do a little work, and re-evaluate.
If you’re business understands the environment in which you create software, they will behave more wisely. You will see commitments and must-haves and multiple #1 priorities shift into ordered backlogs and agile roadmapping. Give it a try. Go explain to your business partners how you create software.
bowtie agile 