← Click the menu button top left to access posts by category
One Day Challenge
What is it?
Do a one day rapid prototype.
Why is it useful?
Pending a lot of time in an ‘idea’ based process which can become unproductive.The benefit is to test out an idea as quickly as possible and only rely on the planning stage in the bare minimum.
How do I use it?
A team, group of people, or person has to be very motivated to do the one-day challenge and come up with the solution. Therefore this method does not suit everyone or all institutions, because some large companies can’t move fast – e.g. it will take a day to decide to do the one-day challenge.
With the idea / brief available at the start of the day the aim is to have prototyped a solution by the end. This happens by using agile methods to scope high impact aspects of the project, and then rapid prototype them with models or rough materials.
Inspired by: http://www.arctickiwi.com/
Our commitment to you:
1. We have your requirement in our inbox at 9am with an agreed price.
2. We assemble a prototype of your request immediately.
3. By the end of the day you’ll have a prototype which you can start using, and this becomes the basis of your new product.
This is good because:
1. We don’t waste time writing elaborate specification documents which take days and are never accurate.
2. You can more easily see what you do and don’t want when you have something tangible.
3. We’re all on the same page with your requirements since we can see what you’re talking about.
4. We prove ourselves to you as smart, fast, agile and competent.
5. Changing a system is easy. Trying to imagine a requirement is hard.
The old method of developing applications and web sites involved a scoping meeting with all the developers, designers, DBA, team lead and client stake holders.
They would discuss the entire project and attempt to anticipate every requirement, function, detail, error and user interaction across the whole development process, months in advance.
This involves great speculation and imagination. Businesses change, requirements shift, stake holders leave, budgets run out, new features arise. In essence things change. This is a function of life.
Our approach is different. We don’t even bother sitting down and trying to scope all this out. We can work this way because our development process is extremely agile.
Change for us is easy, but getting the client to sign of a specification is hard, and rightly so since it becomes project gospel.
So we discard the psychologically challenging step of writing and signing off a spec by simply diving in and putting together an application we think you’ll want. We’ll spend a day, maximum.
Then we get your feedback and you can tell us what to change, add or remove. Our understanding becomes more attuned to what you are imagining, which is always the hardest part of any development project.
The requirement is complete when the application is finished
So the project evolves more naturally based on an immediate feedback-change-deploy loop. This also greatly increases project transparency so you always know how your application is progressing and if it will be ready in time.”