Why Are We Doing This?
Have you ever wondered why your team is using its current development process?
If you’re the person facilitating the process, have you ever been asked “Why are we doing things this way?” and found yourself unable to articulate anything beyond process mechanics?
For me, an effective development process is meant to provide four key outcomes beyond merely delivering work. I expect these outcomes irrespective of the methodology, framework, or tools being used. My focus here is team-level development process, but the outcomes certainly scale to the organizational level.
Cultivate Understanding of Capacity
How comfortable is your team with answering what work items should be complete in the next two weeks? Four weeks? Six weeks?
Development teams exist to deliver outcomes. Most of the time, requests for those outcomes originate outside the team. As a result, teams are always being asked when a given item will be complete.
A team that does not understand its capacity cannot comfortably provide a projection of how long a given body of work will take. That discomfort can lead to anxiety within the team, and as external pressures for timelines increase, team members can lash out at one another in frustration, often laying blame for their problems at the feet of team members whose skillset is the most scarce, making an already strained situation worse.
The commit-execute-evaluate cycle of iteration exists for teams to come to understand the average volume of schedulable work they can complete. By breaking down work and committing to it in small batches, and evaluating the difference between our projection and what we completed, we develop a shared understanding of what we can deliver as a team. As we continue together in that cadence of commit, execute, and evaluate, we can better understand our capacity and increase our comfort with estimation and projection.
Build Cohesion
How easy is it for your team members to answer the question, “What does your team do?”
Team members need to feel a sense of belonging, that they are part of a team that exists for a reason, not some random assemblage of bodies thrown together. A team’s charter should convey clear ownership over a meaningful part of your product ecosystem. People who can map the effort of their days and weeks to how they help move the needle for your organization are more likely to be engaged, feel connected to their team, and take pride in their work.
Additionally, team composition should represent all the necessary functional skills to deliver against their charter. This allows them to meaningfully own delivery of outcomes from concept to customer. Having all the cross-functional perspectives present during ideation, backlog iteration, and estimation as well as during execution helps the team have less naive and more holistic estimates, implementation approaches, and delivery of their work.
Preserve Agency
Do your team members feel that they have a say in how they approach their work and the effort it will take to deliver it?
In this context, agency is team members having a voice in the commitments, timelines, and approach taken to deliver their work. Commitments, timelines, and approaches dictated without team member involvement erodes agency. When commitments are made on your behalf without your input, a common coping response is to detach yourself from the quality of the outcome. The peril here is that leadership making commitments on behalf of their teams can induce a cycle of apathy and low morale within the team, which leads to low quality, missed deliveries, and expectation mismanagement.
Healthy development process focuses on team member involvement in every event of the development cycle. Having everyone present and engaged to contribute their perspective to ideation, estimation, and planning begets better execution and delivery, and allows the team to come to decisions and commitments as a unit. Having everyone there is an investment in the health and effectiveness of the team, not a waste of developer hours.
Nurture Critical Thought about Effectiveness
At the end of your iteration cycle, are you merely asking “What did we deliver?”, or are you asking “How effective were we as a team?”
Most of the agile processes model the three pillars of empirical process control: transparency, inspection, and adaptation. The primary purpose for an end-of-cycle retrospective is to create space for that inspection and adaptation. When our cycle retrospectives are well-facilitated, they become fertile ground for us to think critically about our effectiveness and identify experiments to improve cycle over cycle.
Well-run retrospectives are not easy, and represent some of the most challenging facilitation that happens within development cycles. However, the investment in building that skill truly pays off when we get the team talking to one another and reflecting on how they could experiment to improve their situation.
Conclusion
There’s far more to the topic of healthy and effective teams, but these four outcomes are good to keep in mind all throughout your development process journey.