Iterate towards your win condition
You’ve defined requirements, found a developer and you’re now shipping software. You need to keep doing this and focus on achieving your win condition. Working in iterations will help you do this.
Work in iterations
In iteration is a fixed period of work on your project that results in software that you can put in front of users. Iterations usually last one or two weeks. Each iteration should move your software closer to your win condition.
For an iteration to be successful, a number of things have to happen.
First, decide how long an iteration is going to be. The shorter the iteration, the more meeting overhead it requires. One week can be good for projects getting started as it allows for quicker changes in direction. Later on when your win conditions/requirements are understood in greater detail, you might find productivity gains in increasing the iteration length to two weeks.
Before any iterations begin, you need to define in as much detail as possible the tasks that you want to accomplish. Once you’ve consulted with developers and defined these tasks in sufficient detail to implement them they become your “backlog”. This is a set of task definitions that is ready for you to prioritise. Your backlog will need to be refined, pruned and added to so that you have a ready list of tasks that your developers can work on.
You should prioritise iterations based on the “launchability” of the delivered software. Instead of working up to large complex features, assume for a moment that this is iteration will be the only work done on this project. Choose features that if successfully developed by the end of the iteration, you could deliver to your users. If you have large, complex features to deliver, start with a small, simple version that gives user 10% of the desired functionality. Prioritising like this means that you’re thinking in terms of your product launch from day one.
Before each iteration, after prioritising your tasks decide with a developer what tasks they estimate they can reasonably deliver by the end of the iteration. The goal here is not pin-point accuracy, just a shared understanding of what you can reasonably expect to have delivered by the end of the iteration. The smaller the tasks, the easier it is for the developer to reason about the time it takes to complete them. There’s no guarantee that what you agree upon will actually be shipped by the end of the iteration, but the act of agreeing will focus both you and the developer on a clear goal for the time box. Having a fixed set of tasks to work on for the iteration also allows your developer to focus more fully on the task at hand.
Soon you’ll see your task definitions being delivered as working software. Once your developer confirms them as done, the best thing you can do is manually test the new functionality yourself as soon as possible. If the delivered result doesn’t match the previously agreed acceptance criteria for the task, then push back and make the developer amend the work.
The delivered software may comply with a reasonable reading of the acceptance criteria but still not be what you intended for this iteration. In this case, create a new task definition and use the differences between what was delivered and what you intended as acceptance criteria. Schedule this task into the next iteration rather than the current one.
During testing you might find what appear to be bugs in the delivered software. In order to get these fixed as swiftly as possible, create a task definition for the bug that describes it in detail. The definition should provide details of the expected/observed behaviour, steps to reproduce and the specific acceptance criteria that the behaviour violates.
While the developer is working through the implementation, you need to be preparing your backlog for the next iteration. This means observing progress, meeting with other stakeholders, re-evaluating the priority of existing tasks and writing up new task definitions with clear acceptance criteria. At some point during the iteration, you will need to consult with your developer about the acceptance criteria on your task definitions, in particular about tasks that you intend to schedule in the next few iterations.
If the developer manages to complete all tasks in this iteration before the end, then you can pull in smaller tasks from the backlog that are ready to start. If one or two tasks were not completed by the end of the iteration, they can be continued in the next iteration.
Towards the end of the iteration, you’ll want to start the process again. Decide with your developer a set of tasks that can reasonably be expected to be completed by the end of the next iteration and schedule them in.
At the end of each iteration, remember the win condition that you defined at the beginning of your project. Ask yourself if you’re moving closer to it. What development tasks do you need to schedule in to get closer to that condition?
There will be problems with any conceivable development process and you will need to adapt it to the situation on the ground. You should meet regularly with your developer to ask if there’s anything you can change about your development process to make it better. Your aim is to remove obstacles to getting work done.
Launch is the beginning
Software is never finished. Think of any successful web software company. They have software products with product-market fit. Why do they keep expensive engineering teams on staff? If their products are successful, they could surely just keep a skeleton crew on staff for maintenance and stop all work on development.
This is because the win conditions on software projects change. If you meet the goal of doing a product launch, the next win condition might be to get it to one thousand users. After that your win condition might change to some metric of user engagement.
The scope of your software project will change. The team may expand or contract. The project may in fact be put into maintenance mode or instead become the main focus of your business. It’s very difficult to predict how software projects change over time.
An iterative development process helps you respond to that change. It helps you get maximum productivity and communication from your development team. It means that you can re-prioritise tasks at the end of each iteration rather than at large project milestones. It allows you to demo a working version of your product almost as soon as you start development on it.
While you may be focused on your product launch now, it is just the beginning. Once you have a first version in front of users, the requests for features will pour in. Both leading up to the product launch and after it, you will need a process that helps you respond to change. An iterative development process will do that.
- Najaf Ali
Find this article useful? Sign up to our mailing list to get updates like this in your inbox every week. No spam, and you can unsubscribe at any time.
Give me the goodies