The Story Behind Uclusion
We founded Uclusion to solve the problem of working on what is most important. Over the years we’ve had many experiences that led us to strongly believe there has to be a better way.
A tale of three development process disasters
Top down waterfall
Our first story comes from back when Scrum was first becoming really popular and for good reason, since the problem it was trying to solve was so painful. We thought that if we follow these ceremonies (as opposed to the spirit of Scrum) we would be led out of the desert.
So we embarked on a re-write of our software with several Sprints of design work for requirements that came from on high. Now you may say, “Oh a re-write those are doomed to fail.” You would be right of course — the only thing less likely to succeed than a re-write is never re-writing — as yet there are no simple solutions. However doing all the design work up front i.e. waterfall doesn’t account for what is learned while doing.
The result was pure disaster — acrimony, despair, people leaving and little code ever deployed.
Bottom up agile
This time, different company, we all voted on the top priority technical debt project. Our team was lucky (we thought) to get the top voted project and we then followed a much more agile process where coding could begin right away.
And again pure disaster — acrimony, despair, people leaving and little code ever deployed. What went wrong this time?
First off our method of voting was incorrect. A vote for a project doesn’t mean much if you don’t also know how certain that vote is and a reason why. Our top voted project turned out only to reflect very recent down time incidents.
Second how you implement the project also requires a lot of collaboration. We naively divided the stories up without giving much thought to time boxing them or considering and voting on different implementations. Agile had become an excuse for needlessly poor planning.
This project wasn’t mine but its one of the most successful, from a moving the needle forward perspective, that I’ve seen. The problem it was solving was perfect, the solution was perfect and the code was deployed to immediate wonderful effect.
And yet acrimony, despair and people leaving! What gives?
Well from management’s perspective if the solution was skunkworks without collaborating to build proper support then it didn’t really matter what problem it solved.
Uclusion’s first attempt
Our first idea was that if you only work on projects that customers really want then you can’t go too wrong. We set out to build software that would measure large scale customer desire for a feature. This approach failed for a number of reasons:
Votes age — even a system that captures the quantity and intensity of support for a direction is not enough — any vote can only be considered point in time. You need continuous collaboration if you want to avoid harvesting dead wood.
Existing customers are biased. They will have a hard time weighing in on technical debt or pushing for a direction that expands the customer base in new ways. Lean startup ideas can be used to get around this but again this is a hard problem and any one solution is limited.
Development process has some things in common with a pandemic. Without a cure or vaccine its easy to imagine that only a complete solution matters. But places that practice simple techniques like social distancing, masks and hand washing do much better.
Similarly Uclusion is not offering a cure but does make best practices easier.
Be as agile as possible but don’t skimp on approval for projects, stories and story implementations. Record your votes with certainty and reasons.
Time box everything — decisions, stories, vote expiration, responding to notifications and giving status (which your software should help with).
Prefer simple notes on requirements to fully groomed backlogs.
Keep your asynchronous collaboration with the requirements and stories and have that online collaboration instead of or at least before calling any meeting.