As I practice Scrum and tackle issues in Scrum Teams/Organizations, one common theme "emerges". Emergent is one of those funny words that gets thrown around quite a bit in the "agile" world. The Scrum Guide talks about embracing the idea that work "emerges" during the Sprint. The Agile Manifesto talks about the idea that "The best architectures, requirements, and designs emerge from self-organizing teams."
One of the largest problems organizations face when they experiment with agile, is that they like a plan. A plan to the organization is like a warm blanket. It shows there is a process for the people to figure out the work, they estimate the work, and through that process they know what they are doing. There is one big problem though; they don't!
I usually talk about the 3 things we wish were true as we develop complex systems (whether it be technology, software, or creative knowledge work):
- The customer knows what they want (they don't, they know their problems, they discover more as we deliver)
- The Development Team knows how to build what the customer wants (they don't, they have ideas and assumptions, but don't truly know until they do it. This is why empirical processes work great)
- Things rarely change once the plan is set (we all know that is false. Things change all the time and the more laborious the process, the harder it is to adapt to changes in the plan)
Now, planning is essential. In fact, I usually state that in an agile / empirical process we will actually do more planning than a defined (waterfall) process. The difference is that we tend to spread our decision making around the entirety of a project as we learn more, instead of making all the hard decisions at the beginning of the project (when we know the least). Planning is a valuable part of our process in an agile mindset. The plan is not. In fact the Agile Manifesto addresses this in the 4 value statements; namely, "We value responding to change over following a plan".
I usually quote the great General Eisenhower: “Plans are worthless, but planning is everything"
In an agile process, we have to embrace unknowns and the idea of emerging work. Many teams will struggle with this idea given the culture of over 150 years of manufacturing which constantly solidified the idea that we find the single best plan and then execute it.
Let's take a moment to look at what we mean by emerging work. In agile, we won't have a big requirements gathering phase. We do gather requirements, but we only focus on gaining clarity and details on the most important requirements. The more time we spend writing documents, designing, estimating, etc... the less time we spend building products. We have to be intentional and deliberate about balancing the time between planning and executing. Scrum accomplishes this by placing a constraint on the time a Development Team can spend in these types of activities (called Product Backlog Refinement). It is only 10% of their time each Sprint. As we learn more about how to tweak our agile process, we get better at managing this type of activity.
What does "emerging" work even mean? By definition, the word emergent means:
"in the process of coming into being or becoming prominent."
I was co-teaching a class with Andrew Sherwood this week and he used a great analogy for the class on what this means. Pretend you are driving on a freeway. Off in the distance you see a black object. You are pretty sure it is a car, but not certain, you just know something is there. As you get closer to the object, you realize it is a black Ford Pick-up. Some details emerged as it got closer to you. As you get even closer, now you can make out that it is a black Ford F-150, you also realize it is a King Ranch edition of the F-150. As you get even closer, you realize that the truck has grey leather interior and is a 2018 model year. Even closer, there are some dings on the front fender...
Hopefully you get the idea. As the truck moved closer to us, the more we learned and the more attention we paid to the object. The Product Backlog should be the same way. The Product Owner brings an idea. We discuss it briefly and become aware of it. As it gains priority, it moves closer to the top of the backlog (i.e. closer for us to implement). As it moves closer, we gain more details about it and start learning if it is too big to fit in the Sprint and start thinking of ways of breaking the work down into more manageable pieces that deliver value early to the customer. A key practice for this is to think about roadmap planning and various levels of estimation. I talk about that in this article.
A team should be comfortable not knowing everything before taking the work into our Sprints. Know enough to feel comfortable with the smaller emerging details. This type of behavior will help a team embrace the Agile Manifesto value statement about planning and Scrum's demand for constraining the Development Team's time in this activity. We spend the most time clarifying important things and less time spinning on details that are months or years out (and worse yet may never materialize at all).
