Startup founder: How to turn your ideas into fully functioning software?
Posted on May 8, 2018
In the earlier blog post I covered the workflow from initial ideas to well prepared specifications with a properly configured Product Backlog. Now it’s time to take a closer look how developers can turn those ideas into production-ready software. For startup companies this means typically rapid iterations, sudden pivots and constant ideation. That’s why it’s important that software production is built on agile principles allowing us to adapt effectively into new situation.
The whole software industry has shifted from a waterfall process into an agile iterative model for a good reason: Software development is unpredictable and under constant bombardment of new ideas. You never know what you really want before you can play with the new feature. It's always more cost effective to deliver new features quickly with a minimum amount of functionality instead of making everything perfect before launch. The reason is simple: Software is never perfect - it’s under constant evolution.
That’s why we need to deliver new features in iterations instead of tightly fixed project phases. For example a project roadmap is already way too strict tool for most of the startup founders, because it tries to predict what to deliver and when. Agile Product Backlog works much better: Development is focusing on well-defined items on top, while new ideas are planned at the end of the list. Priority defines how critically those ideas are pulled to the top.
Even the largest software is built with small iterations
As soon as you have the Product Backlog available with enough ideas in “Ready for development" state (well specified, scoped and estimated by developers), you can start the first development iteration. Iteration length should be somewhere between two weeks to a month. A short iteration keeps you focusing more on bureaucracy, because you need to start, drive and end an iteration with some management activities. A long iteration on the other hand drives you easily to a situation where developers are working a week after week on same activities without easy way to measure the progress. Typically a three-week iteration or sprint is a good compromise if you don’t know yet how to approach this question. As in agile development overall, everything - especially your process - can be adjusted later to fit to your current situation.
Some agile models, such as Scrum, keep the iteration time always in a fixed time-box. It means that you always start and stop the iteration within a given time, regardless what was the outcome - as long as quality meets the requirements. There are several benefit in this: Developers focus easier on business goal instead of unnecessary perfectionism because deadline cannot be negotiated. Time-boxed sprints are also easier to plan and measure, because they repeat the same pattern again and again. This removes unnecessary complexity. But at the end of the day it doesn’t really matter if you use time-boxes or just scheduled iterations - the most important question in agile development is that you deliver often and you deliver fully functioning features that can be tested by the end users as early as possible.
Start well defined iterations with an actionable plan
An iteration starts with a proper planning. Outcome of the planning should always be a goal definition and a list of items (features, user stories, bug fixes, tasks etc.) selected from the top of your product backlog. This depends of course how many developers you have and what are their availability and skills. Goal helps later to keep the focus. During the iteration there might arise new questions or requirements, and that’s the moment to confirm that everyone is still working on the same goal.
No matter what, by the end of the iteration the selected items should be completed. That’s why you need to make sure already during planning that each developer understands what those selected items contain and every team member really commits to deliver. One easy way to confirm this is to assign each item for a named developer and ask them to give an exact work length estimate. If a developer can say how many hours the work takes, it also means that there’s a vision of the actual content and implementation.
While developers should have enough work on their plate for the full iteration, it’s also important that people are not overloaded with activities. Remember that there’s a big difference between “we need to deliver" and “we commit to deliver". Only the latter can guarantee the results. That’s why you should allow developers to decide their activities as much as possible, otherwise they lack commitment.
Execute iterations with a transparent workflow
During an iteration or sprint you should keep track on activities as automatically as possible. There shouldn’t be any need for status meetings if work is managed transparently. This is where for example a kanban can help. To-do list is of course formed from the “Ready for development" items that you selected during planning and the goal is to push those items from “Ready" to “Done". This sounds simple, but it’s crucial that you create a proper workflow for it, for example:
- To-do - Ready for development
- In Progress - Currently under development and technical testing
- Review - Quality assurance and end user testing
- Done - Feature is fully implemented, tested and documented
- Obsolete - Feature is no longer needed, no further development
A well-defined workflow helps to avoid unneeded meetings. One of the most misunderstood concepts of agile development is the daily standup. It’s too often kept as a status meeting where developers report the progress to manager. The questions is why? If you keep statuses updated on the workflow similar as described above, there’s no need for daily status meetings anymore. The most recent status is visible all the time to every team member.
Daily standup has more important goal: Improve the commitment. It’s based on a very simple psychological trick. Anyone who explains an upcoming task to another person, also commits to that task on deeper level than those who don’t share their work transparently. Therefore, instead of developers giving status updates to manager, they should give small promises each other. In an ideal situation daily standup is a motivational event and for developers only - managers should just stay quiet and learn.
Make a closure, learn and start a new iteration with better knowhow
Ending an iteration with a proper closure is as important as starting it with a proper planning. An iteration review demo is very good for this purpose. Everyone should have an opportunity to show what they created during the sprint and how things really look like for the end user. This should be very creative event and it should encourage people to talk also how the new feature might impact to the upcoming development. Product Backlog can still be adjusted before next iteration and this is exactly the moment to do it together.
After everything is finished for current iteration there’s still one very important activity to do: Look back to the ending iteration and find out how did the team perform. In Scrum for example this is called retrospective meeting. Now, instead of looking at the product it’s time to look together at the team, processes and tools. What should we start doing, what should we stop doing and what should we continue doing to make the next iteration even better. Every iteration should teach a lesson or two, thus making teams understand their current work environment better.
After the iteration is completed, repeat the steps with new iterations again and again .. until forever. The most practical goal is that every iteration should make your and your customers' world a bit better place to be.
As you can see, agile is not only about constantly adapting the product into new situations, but also the team should adapt. My next blog post will explain this in details. Stay tuned.