Commitments in Agile software development
Learning in software development is key. Agile is a mindset that values learning as a core principle. Scrum is one process to implement that learning mindset — and it keeps evolving. But what is the next evolution?
Teams are pretty clear on making commitments at sprint planning. Most often, sprint commitments are for stakeholders. That is, as a stakeholder, I can rely on a team to deliver a sprint-length commitment. Yet, the most valuable aspect of a sprint commitment is the opportunity for transparency and inspection it provides.
Transparency and inspection is a key requirement of learning. Learning is complex, but in simple terms:
1) having transparency provides more information (feedback),
2) inspecting what that information is, and
3) adapting based on that information.
Setting commitments provides both
a) “more” information and
b) information that is more actionable for adaptation.
Choosing a target is an important aspect of commitments and learning. Let’s look at an analogy of shipping software being like moving an actual ship. Setting a sprint commitment is like a beacon emanating it’s signal. It helps pull us through the fog, cross-wind, and waves during each iteration. Without a commitment of where we want to go, it’s easy to lose where we planned to be. We will even make decisions to do work that take us in the wrong direction. Moreover, most important for learning, is that when we don’t have a target, it’s near impossible to notice (gather information about) how much “all the things” that happened in the sprint pushed us around. Commitments help increase our sensitivity in measuring what is working (or not). Without commitments it’s easy to get in the habit of working hard and not learning. Then, not arriving where we intended.
Commitments create an affordance for discussions to ask is “what we are doing” actually taking us where we intended. When new work comes up, our context is now superior for guiding us to question “does this helps us reach our goal” or not. Further, if we miss our goal, it allows us to say “here is where we went wrong in our commitment, and what we learned”. This context, which affords these discussions, is a massive improvement for individual and shared learning — and one of the most exhilarating parts of software development.
Using Sprint Commitments for learning is still rare. But let’s not rest on our laurels. We can all push our learning process much further. Anders Ericsson’s 10,000 hours research (made famous by Malcolm Gladwell in “Outliers”) and related follow up research is still foundational to understanding developing elite skill. In sum, it notes that 10,000 hours of “deliberate practice” will lead to expertise. Deliberate practice is a daily, consistent approach to each task with the intent of learning . Two of the key aspects to maximize “practice” are to fail (some) and to be deliberate about learning . Typical software development practices do not match with this theory or the practice of elite athletes/coaches. We have a long way to get to that level — whatever that level looks like in software.
One next step in software is to increase our opportunities for learning or deliberate practice. We can increase these opportunities by making Daily Commitments at “Stand-up”. In addition to sprint level commitments discussed above. Rather than only learning every two weeks as a team, there are daily learnings for each member. Furthermore, this daily practice reinforces a learning mindset. Which trickles down into every smaller task throughout the day through self-directed learning.
If you want to try this on your own. I encourage you to explore ways you can chunk a task into a component. Then approach that component of work with a focus on getting better at that component. For example, one might want to get faster at estimation. First, define what it would look like to you, what’s your target. Let’s say it is reducing your planning meeting in half. Second, whenever you engage in estimation, focus on what you can do to make that faster. Third, have a feedback mechanism. In this case, it would be the total time for planning.
In software development, we don’t yet have the kind of practice Anders Ericsson talks about in his theory of Deliberate Practice. Coaches (managers) are not assigning every task throughout the day with a deliberate plan for learning. On the other hand, Ericsson does discuss a stage where learning is self-directed. So, in software, we rely on self-directed-learning — a pretty common trait among software developers. It becomes the role of managers to set the right environment for developers to find their own learning opportunities to optimally challenge themselves every day and get feedback.
When we set a commitment, we set a target that stretches us outside our comfort zone. And, regardless of the outcome, we know where we are at relative to that target. If we never set a target, we don’t pull ourselves out of our comfort zone, we don’t get to compare how we did, and we miss opportunities for learning.
