Create Exacting Workflow Documentation
In software development, there are typically phases such as planning, doing, reviewing, and deployment. Irrespective of the context of your workflow, it should be clear and unambiguous. If you want each new code feature to be reviewed, you make it a compulsory. It then becomes a practice, you don’t need to request it every time.
Once your workflow is obvious, you can start examining wastefulness and/or blockages in your process. Here are few things you might want to review:
- What workflow is slowest to produce
- Are some tasks repeatedly re-opened after they’ve been marked as done
- Are there lots of tasks that were removed
- The more transparent your process is, the easier it is to spot anomalies
Backlog Requirements
A good backlog requirements document helps you to focus on what’s most important right now, while not ignoring other, less critical ideas or pieces of work. Your backlog of items will likely contain many tasks. To handle this split your backlog into the work, committed to the near future, and work that you may do. You may do list should be somewhat stable in size, not expanding. Don’t worry about accidentally deleting something important from your backlog, if it’s important, it will come back
Detail an Absolute Definition of ‘Finished’
The Definition of Finished ensures everyone on the team knows exactly what it means when something is ‘finished’, and it removes any ambiguity. A finished definition must mean the feature is ready to be released for users. We’ve all heard someone saying, “but it works on my computer…” – that’s not ‘finished’.
An explicit completion criterion can also reduce testing errors, which happens when QA must repeatedly re-open the already completed task due to some missing element. It is faster to spend a little extra time and complete a task once, rather than having to revisit it several times to make fixes.
Definition of Finished is a set:
- Feature is implemented
- Unit tests are passing
- Documentation is up-to-date
- Feature is reviewed by QA
- Code is in master branch
- Code is deployed to production
Work In Progress (WIP)
Multitasking kills efficiency! When you overload people with work, output slows and the number of imperfections increases. The more multitasking, the longer it takes to complete any individual task. You accomplish this goal by controlling the WIP.
WIP should be taken as a plan and not an absolute rule. WIP has limits, you should try to reduce the amount of task provided to any one developer and each developer has different limits. As a rule, if tasks regularly get stuck as WIP, the task size is too large for that developer. Consider breaking tasks down to a size where there is a constant and steady flow of work across the board.
Visual Define Progress
Electronic tools like Jira or BaseCamp, while great for tracking your work, are hidden away, and generally must go looking for what progress made. But they do come with good APIs that enable you to pull data out for displaying on big public monitors. Always pick the data and visualizations that seem the most relevant to your situation and your team’s goals.
The human brain is literally designed to process visual information rapidly. The team that takes advantage of this and uses information images always performs better. A good image is visible, attention-grabbing, and displays essential information. However, the biggest benefit of an image is that it will start a conversation, about possible problems early on.
