Ursula is the Director of Digital Strategy & Innovation at the Danish IT company Miracle. She has hands-on experience implementing digital strategy and innovation processes in Danish companies. You will meet Ursula as a speaker at conferences and as a workshop facilitator addressing digital strategy, innovation processes and tech-people as a species. You might also have read one of her columns in Computerworld.dk.
U.K.: We exist in a competitive world. The correlation between time spent, money spent and value created is key to understanding how to develop an effective survival kit for the future. There is no room for survival by exertion anymore. Existing companies with a successful history and money to back-up new initiatives no longer can rely on their competitive “strength by resource”. Smarter companies can develop cool stuff both fast and cheap. And they will win the battle simply because they outperform traditional best practices.
U.K.: Traditional development processes are heavily burdened by “keep talking not acting”. In the very old days producing code was expensive, and computer time was something you had to reserve. Today we have perfect tools to help us produce high-quality consistent code. Programming is no longer expensive. Time is expensive. And we lose time when we insist on describing instead of prototyping. When we insist on testing (asking the right AND the wrong questions) instead of launching and follow up based on real-time statistic data.
U.K.: Fast Track Development is an action-based approach to digital development. The software engineer is heavily involved from day one. Because software engineers know stuff. They often know more about ie. iOS new navigation standards in the latest iOS version than traditional designers. They know more about what can be done easily using the standard tool kit and what will never work. And what they do not know they can try out – to get proof. Real proof. Much more reliable than academic analysis. So Fast Track Development is very much about minimizing risk. And about continuous progress – real progress.
U.K.: Fast Track development is carried out in two steps. First you develop a POC. And here you have a decision point – a GO/NoGO decision: does this look good? is this what we want? does it solve our problem? If yes, you continue to develop an MVP. The MVP is version 1.0 of your new digital service.
There will be no specs involved. Instead, during the development of the POC, we meet for three co-creation sessions. Business meets software engineers. They talk together from day one. Between each co-creation session there are 10 days of POC development. And the POC third edition is so much better than the POC first edition. The first edition mirrors the level of knowledge we would have had, had we gone with the traditional specification.
Besides, the POC is understandable to the decision-makers. They can actually see the vision for the final product. And ask questions. It helps improve the quality of the decision. Besides, our demo session does not eat up the same amount of time as a written specification attached to an e-mail. An e-mail that will be avoided for weeks – because no one has the time to read specifications. Go into detail. And ask questions.
When we started out on our Fast Track Journey it was dedicated to mobile projects. We knew that traditional IT-project management completely ruined projects for smartphones. They drowned in project overhead and no one quite understood that they had just asked for a native app looking like a traditional website. Prototyping with real look & feel (as opposed to wireframes) was part of the answer. Because of the mobile project background, the organization got an idea the Fast Track Development was only meant for mobile projects. It took some time to prove them wrong. However actual results are hard to ignore.
U.K.: This is the essence: the customer can actually see and follow the product development and changes can be made during the whole process. You do not have to operate with change requests and other initiative- and improvement killers. You just do the changes.
Then how will you ever finish you might ask? We finish after 12 weeks. The calendar rules the launch date. And we all respect that. Changes after the POC decision are considered twice. But still, we can choose to make changes. Simply because the first thoughts might prove themselves wrong.
U.K.: It has had a huge impact on all our projects. The quality of the digital service experience is simply much better. Project owners can do their day-to day-operations while developing new services. As opposed to the de facto panic project way with several dead bodies and worn out project managers. But timely, safely and on budget. It works.
U.K.: Well, even though the Fast Track Development process is new it has gone through some changes. We do not facilitate the co-creation processes with post-its and fail fast mantras anymore. We try to actually build stuff from day one. Post-its are fluffy. And it is often hard to know what was actually achieved/decided/rejected. Because they are based on words. And they are interpreted differently. And because of the level of abstraction, they are difficult to build on.
Also, we go through the Fast track Development process because we believe, we have the right idea. We might be proven wrong, and the POC might be rejected. But we do not enter a Fast Track Development project with the intention to fail fast. Fast track development is not about testing random ideas. It is about launching ideas we believe in.
U.K.: Calendar time is key to cost control. It is as simple as that. You cannot spend tons of money in 12 weeks. You cannot follow not significant issues if you are about to launch in a few weeks. “The forced launch” is the perfect driver. You will stay focused! You will focus on what is important. That is the recipe to success for start-up companies who do not have tons of money nor staff.
U.K.: We have had great success simply by involving staff from i.e. the project department in our fast track development projects. Once they have participated, been part of it, they know it is not the wild west. Developed in hippie land. By innovation freaks. It is about doing only things that improve the product. And knowing instead of guessing and hoping. And it gives the software engineer the opportunity to do his or her very best. And that is value for money too!