There's a - quite old now - image which goes around a lot by Henrik Kniberg about agile development, in which he tries to show in a nutshell what iterative development processes are supposed to look like, and equally what they're not supposed to look like:
Unfortunately, it was so misinterpreted over the years that the creator of it felt he had to write a blog post to explain it - Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable - but still, some people get stuck by the metaphor, so I thought I'd write this to explain a piece of work I've been doing the last few weeks.
The context to what I've been working on is twofold - first of all, one thing that I anecdotally observe in local government digital circles is a difficulty in resource planning; whether we're working as part of an empowered multidisciplinary team or if we're working more old-skool, for too many of us there's a pressure to try to deliver everything, everywhere, all at once, with the consequence being everything takes simply forever. Part of that is because some working cultures shift hard, but part of it is down to the problem that we don't have cheap and effective resource management tools at our disposal.
Another issue that's been identified, at least as far as one common project tool widely used and the level of access many of us have to it, Jira, is that when task cards are created it's not possible to assign the task to multiple staff members, which creates a false sense of who is busy and who has slack in their workload.
My response to this has been to start building a tool I've called easyResource, which combines an Air Traffic Control flightstrips metaphor I've established for task management on another project tool I've been working on with a simple timeline with rows for the resources - which is mainly staff members, but it doesn't need to be - in the team with a timeline view of the major pieces work that's been assigned, when it's expected to be done, and ultimately how confident all the predictions about the pieces of work are. To be clear, it's not a Gantt chart showing the microtasks and dependencies, it's simply a simple visual indication of who is expected to be up to what, and when.
This isn't an article introducing the tool to the world - I'll write a separate article doing that when it's actually ready to introduce to the world - rather, it's an article to link my development process with Henrik's vision of the progression from Skateboard to Sports Car.
First of all, the Skateboard delivery. This was the Minimum Useable Product - I'd knocked up a simple underlying database in MySQL, built a form to add resources, a form to add tasks and a form to edit them, and put the results of added resources and tasks on a page with the basic timeline view of vis.js; it took me a couple of days, and if I'd done nothing else it would still have been almost more functional than the Excel documents I'd been using for team and project management in years previously.
I say almost more functional - one thing which I always did with my Excel documents was to make extensive use of colour coding, so with the Scooter delivery I added colours to the tasks on the timeline to indicate the status of the task (added, in progress, under review, etc) and its priority (urgent, medium, whenever, etc), and I made it so below the timeline all the flightstrips can be seen and accessed, sorted by status and allocated team members.
The delivery I'm working on right now is the Bicycle - I've made it so comments can be added to individual tasks, and I've further refined the flightstrips views.
This is all well and good - but as it currently stands, only one set of users in one team with my direct permission can use the tool. Which would be fine if that was my only ambition for it, but since my college training was all about preparing me to perform on the Pyramid Stage at Glastonbury in June followed by having a premiere of one of my pieces of music at the First Night of the Proms in July, or as a consolation prize achieve some fame and notoriety in the world of Local Government Digital Strategy and Practice, then I want to enable other people to be able to use it too.
So the Motorcycle delivery will be to introduce a login system to the tool, and to enable organisations and teams to be created within it. Additionally, as part of the original Skateboard delivery the method of assigning multiple resources to tasks - one of the principle requirements - is something of a hard-coded blunt instrument where no more than three resources can be assigned. I coded the database part of this to enable unlimited resources to be assigned, but the actual form is restrictive.
The Car delivery - well, that's kind of up in the air, really. Something I absolutely don't want to do is feature-bloat the tool; I've called it easyResource for a reason. I've a vague idea that it might be useful to be able to group tasks into Epics, but in the LocalGovDigital context I don't know how genuinely useful that is. I've also identified a number of UX niggles which really should be resolved before I consider allowing people I don't know personally to use it - it'd be nice to resolve as many of those before I get to the Car stage, but any still outstanding would definitely be included in that delivery.
So there you have it - an example of a real life product development process with an end point but broken up into tangible steps, where the first deliverable began with something users could really use in real life, with each delivery adding a new and tangible piece of functionality.
And if you might be interested in using the tool yourself when I do release it to the world, feel free to contact me!
