008. Structure
A sensible approach for establishing more formalized processes.
If you find that you’ve got plenty of productive teammates but your backlog doesn’t seem to be getting any smaller, congratulations! You’ve reached a critical stage in the growth of your team and you’re ready for what comes next.
Increased productivity usually coincides with the need to implement more structured processes. Structure benefits your team by clarifying and focusing work efforts, communicating expectations to management and stakeholders, and building trust between the team and its leadership. The approach this edition will recommend can apply to any process, but is particularly useful when choosing a software development workflow.
Many options for development workflows abound. The naive approach would be to read about all of them, choose the one you like best, then foist it on your team. While this approach will not certainly result in failure, it does certainly fail to take advantage of the knowledge and experience of the talented team you've built up thus far.
Structure is best implemented from the bottom-up. As a leader, it does not usually serve you well to find a box that sounds good and then try to put your team into it. Instead, think of structure like a scaffold that you build around your team, so that it supports them. Here’s how.
Implementing a Software Development Workflow
Following a formal process that you've created can help to establish trust between you and your team. It creates opportunities for you to make decisions and then follow through, sticking to your word. Part of what helps to build that trust is implementing these structured processes together — as a team.
Just as we discussed all the way back in 002, explain, don't dictate. Start by holding a meeting with your team with the intended outcome of deciding on a process to try out. Discuss the goals of implementing a more structured workflow process with your team. You may wish to more easily track work, to have a regular release schedule, or to better communicate expectations to customers. Ensuring your team understands overall goals will help to build engagement and trust.
Different members of your team may have opinions about specific workflows that they'd like to share. Perhaps there's an aspect of Scrum that someone really enjoys. Someone may feel that Waterfall is best suited to your product. Someone else may dislike Kanban for particular reasons. It's important to become familiar with how your team perceives different options and to understand the reasoning behind those perceptions. You'll likely find you learn something new.
That said, avoid going down rabbit holes of debating which established process is the right choice for your team. The goal of the meeting is not to decide to, for example, "do Scrum," but to determine the individual stages of the process that the team believes would be beneficial. Always manage the conversation in terms of coming to conclusions — not be-all, end-all decisions, just the ideas you'd like to try out in an initial run.
The outcome of a successful meeting may look like a simple list of phases or point-form notes. Ensure you capture what each phase is going to be, the expected outcomes of each one, and how long it should last. For example:
Planning (1 week): decide the specific tasks we're going to work on this cycle.
Research (2 days): create an initial plan of attack, off-line prototypes, and determine possible roadblocks.
Build (2 weeks): write the code, test, iterate.
Test and Deploy (3 days): run any integration tests, deploy, and communicate to stakeholders.
At the end of your meeting, you may have a process that matches up quite closely with an established software development workflow, but likely with small differences that will make all the difference for your team.
Try It Once
After deciding on a process to try, stick to it for at least one cycle. Remember that this is your first iteration — learn from it! If during the cycle it becomes apparent that changing the time frame of any phase would be beneficial, implement these changes in the second run through. Avoid making mid-cycle changes to the process: this creates a sense of instability and can degrade trust.
At some point in the process, it may be discovered that the full scope of the work you set out to do cannot be accomplished during the given time. In these situations, trim down the scope in order to ship the work that can be completed on time. Use feature flags to gate any partially implemented features. Trim scope instead of letting the cycle length creep — you'll get better at planning and estimation in future cycles.
Iterate
After each cycle, discuss what worked and what didn't work with your team. Decide on any changes to try for the next cycle -- you can experiment with cycle length, phase length, or add some periods of free, unstructured time between cycles for tackling bugs or tech debt. Iteratively developing your software development process makes it maximally useful for your unique team.
Take it to work today:
Start with a scaffold. Build an initial "first try" process around your team, with your team.
Try it out. Stick to your plan for at least one round. Determine what works and what didn't.
Iterate. Experiment with changes in the next cycle to create a process that uniquely benefits your team.