If you want to change something, give it a name. Make it explicit. Make it a topic of conversation. Be part of the conversation, but let it grow outside of you.
You might be surprised of how much energy you can attract, and how seamless can change happen.
The review session in a Scrum project is a place where both the team and the stakeholders come together to assess the current state of the project and to figure out what is left to do. On the one hand, this is important for stakeholders to get in touch with their investment. On the other hand, it is equally important for identifying possible problems or opportunities.
Most sessions I saw tend to go like this. The Scrum Master starts the session by enumerating the stories in the backlog. He takes the first story, and the concerned developers start to demonstrate the progress. They explain the story, and this explanation typically boils down to saying that the story requested that if "you click here, you should get that." Then they start the program, get to the point relevant for the story, and say "you click here, you get that." Everyone is happy, and the next developers take the stage to demonstrate the next story. And so it repeats until all stories are done.
This approach limits the review to facts stating. "You click here, you get that" is just a fact, and facts are never exciting. Facts get exciting when they are surrounded by a story that is relevant for the current context.
It is for this reason that many review sessions fail to incite the audience, and as a consequence, they generate little feedback. Often stakeholders have to switch from their typical activities to participate in this meeting. They might remember little from the last review they visited, and as a consequence they feel rather remote when someone is showing some details inside the product. They need context to get involved. It’s in everyone’s interest for stakeholders to bring their energy and generate feedback.
To turn the problem around, go beyond the click. Tell them a story for why the story is important. Build a little tension. Make them want it. Then give it to them. Something as simple as "In our context, it would be beneficial to get that. Would it not be great if we could just click here, and we would get that?" can do miracles with the energy in the room.
This exercise goes hand in hand with the ideas behind impact mapping. The more you emphasize the big picture and how it reflects in the actual software solution, the more everyone’s understanding is aligned, and the more chances you get to uncover traps or opportunities.
Storytelling is a skill that can be built over time. You just have to want it.
On September 6, I will give a presentation on daily assessment at the Lean, Agile & Scrum Conference 2013, Zurich. The presentation focuses specifically on how daily assessment provides the means for steering the architecture in an agile project.
Here is the official abstract:
"Emerge your architecture" goes the agile mantra. Emerge as in do not plan too much in advance because "you ain’t gonna need it". Instead, build and evolve it along the way. Sounds good, but how do you ensure the cohesiveness of the result?
Testing, pair programming and code reviewing are the proposed means to approach this problem. However, testing is only concerned with the functional side of a system, and thus, it is not able to capture structural contracts. Pair programming and reviewing work well in the small, but they do not scale when you need to handle the millions of details that form modern systems.
The architecture of the system is important and it deserves special attention. Daily assessment is a simple process consisting of the following routine:
- make architectural concerns explicit,
- craft automated checkers to capture the concerns,
- discuss findings within the team,
- distill corrective actions, and
- act.
This process requires both a new kind of infrastructure, like Moose, and the associated skill to enable you to craft checkers fast and cheaply. However, this is a technical detail. The critical benefit comes from making architectural decisions explicit, from involving the entire team, and from the daily system cleaning.
This tutorial is targeted to both engineers and managers. We cover the basics of the process, and we accompany the conceptual descriptions with real life examples.
More details can be found at humane-assessment.com.
On August 28, I will give at talk at Agile Breakfast Bern on the topic of reflective thinking.
The abstract goes as follows:
On the one hand, agile processes, like Scrum, promote a set of practices. On the other hand, they are based on a set of principles. While practices are important at present time, principles allow us to adapt to future situations.In this talk we look at Inspection and Adaptation and construct an underlying theory to help organizations practice them. Why a theory? Because, as much as we want to, simply invoking "Inspect and Adapt" will not make it happen.
For almost half a century the software engineering community has been working on a theory of reflection, which is defined as "the ability of a system to inspect and adapt itself". We draw parallels between the design of software systems and the design of organizations, and learn several lessons:
- Reflection must be built into the organization.
- Reflection incurs a cost that must be planned for.
- Inspection is easier than adaptation.
- We can only reflect on what is explicit.
- Reflection is a design tool that enables unanticipated evolution.
This sounds technical, but the most important observation is that reflection is an inherent human ability. It only requires training to develop into a capability.
Pharo is not Smalltalk. Pharo is Smalltalk-inspired.
Certainly, when inspecting the code, one might say that Pharo is Smalltalk. After all, Pharo started from Squeak, and Squeak started from Smalltalk. Pharo does share to a large extent the original Smalltalk syntax and some of the original model and libraries, but much else has changed. To name a few new things: the traits model, the slots model, the flexible compiler, the new debugger, the command line interface, or the vectorial canvas. These issues are not cosmetics, they are essential differences.
Being Smalltalk meant something for four decades. It still does. However, meanwhile many arguments turn into "how this or that construct is not compliant with ANSI or with the original Smalltalk implementation".
For too long have smalltalkers worshiped the mastery of the originators. It is time to grow up and respect what they did without getting trapped into a religious land. First, there are many interesting things happening outside of the Smalltalk world. Second, there are even more interesting things that are not yet happening anywhere.
Pharo is not Smalltalk. Pharo is Smalltalk-inspired.
And what a great inspiration source that is. Smalltalk was a breakthrough. It was so far into the future that it took 2 decades to be understood by a few. It then took 2 more decades to be rediscovered in various forms. And still several of the ideas promoted with Smalltalk are not yet mainstream, the most prominent being the image and the live tooling. But, Smalltalk is not the end of innovation. There is more to do. It is for this reason that we have to transcend it.
We have to respect it, but we have to look towards the future. Pharo honors Smalltalk precisely because the original specs are not important. We look at the ideas behind Smalltalk and take them further both in shape and in content.
But perhaps the largest difference between Pharo and Smalltalk is not to be seen in code, but in the organization of the overall project. Pharo is more than code. Pharo is a project that fuels on the energy of wanting to shape a different future without being driven by the past. It is an open and inclusive project that favors initiative over seniority.
If you want to experience Pharo and only look at the code, you are missing a significant part of it. Give it a try and join us. We want to shape the future together others that want to shape the future. And the future is not the one defined four decades ago.
Pharo is not Smalltalk. Pharo is Smalltalk-inspired.
Pharo is Pharo.