Agile Education at a primary school in Italy - Part 2

In a previous blog post, I introduced the experiment my brother and I conducted between November 2016 and May 2017 applying Scrum in a primary school in Italy.
I talked about how the whole idea started, how we selected the school project and how we kicked off the experiment. In this post you will find the whole experience report, the results of the experiment and some conclusion we feel we could draw.

The experience report

The stand-up routine triggered very quickly some interesting behaviors right from Sprint 1.

Each team had their stand-up meeting on Tuesdays, Thursdays, Fridays and Saturdays from 8.45 to 9.00, where each kid learned to explain:

●       What did I do since our last stand-up meeting that helped my team meet the Sprint Goal?

●       What will I do today to help my team meet the Sprint Goal?

●       Do I see any impediment that prevents me or my team from meeting the Sprint Goal?

In the same days they got one hour to actually execute the tasks they had pulled into work.

The self-organizing daily planning was pretty rapidly received and understood by the kids, even though it was a completely new practice for them. It even affected school entrance punctuality in a very positive way: all kids tended to arrive on time to attend the stand-up and not to lose the opportunity to speak up.

As described in the previous post, each backlog item consisted in representing one of the 20 Italian regions on construction paper, visualizing morphological characteristics, hydrography and main cities; the team which pulled the story had to study everything concerning the specific learning object, including economic activities, relevant historical figures, monuments, customs and traditions, without this information was presented or explained in any way.

Each Sprint was three weeks long and ended with a Sprint Review where each team had to show what they learned and created during the Sprint to the teacher and the rest of the class. The shape they created on the construction paper was also integrated on the big map to get a truly potentially shippable product at the end of each Sprint, which all teams contributed to. Many even deepened the subjects presented in the school book with additional researches and volunteer studies.

The demo was organized directly by the students in an autonomous and simple fashion, by splitting tasks inside each team. Each kid had his/her specific role in the product presentation, even though everyone was able to discuss any aspect concerning the region under review: this was yet another proof point for us that the ability to self-organize is kind of natural and desirable even for the youngest.

After the joint Sprint Review, each team had their own Sprint Retrospective to encourage a collective self-reflection both on the quality of the work done and on the interpersonal dynamics which characterized the path towards the delivered product at the end of Sprint.

The retrospectives, held before starting the new Sprint, were facilitated in a lightweight way (e.g. using straightforward activities like Mad-Sad-Glad) to allow the kids to point out more easily the key items to reflect upon. Usually each retrospective had an individual reflection time first and then a team sharing to give everyone equal air time and avoid stronger characters to take the monopoly of the conversation. 

The highest voted improvement item by the team triggered a team commitment to one or more improvement actions to execute in the coming Sprint.

For instance, in the first Sprint, one of the teams had wrongly interpreted the information on the atlas map and included inside Veneto (Venice region) a big lake where you are supposed to find Dolomites! During the retrospective the team had the chance to reflect that, possibly, studying the region first, before representing it graphically on the construction paper, would be a better option (before the end of the school year they also managed to fix the mistake effectively!).

It was extremely interesting for us to notice how, thanks to regular retrospectives, each team developed a self-consciousness of being one team with one common goal. 
At the beginning, some students, usually poorly disposed to stay focused and participate actively to the school activities, tended to isolate during the daily working time or to group with classmates from other teams, who had the same low commitment or the same poor inclination to teamwork.

These aspects started to emerge during the Sprint retrospective and some kids, publicly confronted by their teammates, first reacted with denial and even burst into tears, accusing the others of not involving them. Every team has to go through a Storming phase!

However these heated debates brought their fruits. 
The students, who did not show commitment, realized that their disengagement wasn’t going unnoticed; at the same time the “hard-working part” of the team acquired a higher sense of responsibility in engaging their teammates, who probably wanted (and needed) to be a bit more stimulated and supported in their learning journey.

In some cases, this sense of responsibility took some particularly capable and mature student to play a mentoring role towards the kids who showed some learning difficulties, naturally nudged by the framework to practice “cooperative learning” and “learning by doing”. 
In a wonderful talk to a group of young students, Simon Sinek says: “Learn by practicing helping each other. It will be the most valuable thing you ever learned in your entire life”. And this was exactly what our kids were experimenting.

The fact that no one was a formally recognized leader, nor could ever be, put a stop to some usually strong leaderships, who used to dominate the class. This boosted instead who more often preferred to follow others. Interpersonal dynamics enjoyed great benefits during the journey, especially due to the need for the team members to necessarily achieve some form of group consensus, in order to move forward and progress in the work.

As the northern regions were inserted into the map and started to connect with each other, a discrepancy in the quality of the work among the different teams and few integration issues became obvious. 

For instance, the coloring looked in-homogeneous, while rivers crossing over multiple regions flew incongruently. It was so visible, that the kids realized that they needed to collaborate across teams, especially to define the borders between different regions and to agree on the execution of common areas to multiple regions. They also co-created a common Definition of Done.

This contributed greatly to improve the work execution and the general quality of the unique product (the big map of Italy) that all teams realized they had to collaborate to produce: the power of fast feedback loops and early integration :)

At the end of the school year, the last region to complete was Campania, their home region. In that specific case the backlog item was divided into smaller chunks (five provinces) to allow all teams to collaborate, but still keep their own Sprint backlog.

Both half-way and at the end of the year, all parents were invited to the Sprint Review to experience first-hand what their children were doing and learning. The reactions were enthusiast to say the least: they said that their kids were telling them what they did at school, but seeing them in action in a fully autonomous and self-organized way was a source of great satisfaction for them. 
In both cases the day ended with a celebration in the classroom, where the whole group could taste delicious food and cakes which the kids and their parents had prepared at home and brought to school.

Results

We analyzed the results of the experiment through collection of both subjective and objective data.

First we asked kids and their parents to fill in a multiple choices questionnaire to evaluate the experience compared to a similar course they had to study in the previous years.

The idea was to look at what happened from the perspective of the students and the perception of their parents.

Here is the list of questions we proposed:

Since I started using Scrum and compared to the geography class during last school year:

1. I learned much less/less/about the same/more/much more
2. I understood the task the teacher was asking me to do much less/less/about the same/more/much more
3. I had fun much less/less/about the same/more/much more
4. I felt motivated much less/less/about the same/more/much more
5. I collaborated with others much less/less/about the same/more/much more
6. I felt autonomous much less/less/about the same/more/much more
7. I organized my work much less/less/about the same/more/much more
8. I feel satisfied of what I have achieved much less/less/about the same/more/much more
9. If it was solely up to you to decide, would you continue using Scrum at school? Definitely No/No/Doesn’t matter/Yes/Definitely Yes
10. Would you suggest Scrum to your friends inside or outside your school? Definitely No/No/Doesn’t matter/Yes/Definitely Yes

The questionnaire for the parents contained the same questions: we just replaced “I” with “My child”.

The results were astonishing.

More than 84% of the kids' answers were positive, including all the answers reporting "More" or "Much more", "Yes" or "Definitely yes" in the definition of "positive". The rest were basically neutral answers with less than 2% of the answers being negative.

The parents' evaluation was even more positive: 95% of the answers were positive and absolutely none was negative.

In particular below are charts showing the percentage of the answers for the different statements in the questionnaire for the students and their parents.

Answers from kids

Answers from kids

Answers from parents

Answers from parents

The objective evaluation includes the proficiency the different kids achieved in a variety of skills and disciplines analyzed from the teacher perspectives.
The data emerged at the end of the project are reported in the table below and are classified in different areas, to make them easier to read.

Relationships and Social skills	Before the project, the class group had already a good level of social and relational skills, but there was a certain tendency to privilege some friendly relationships compared to others, which were kind of less “desired”. The need to involve and get consensus from others, with no chance to “impose” any decision, has clearly sharpened the relational skills of every student, both those who are more naturally inclined to lead and those who are more kind of “followers”. The former ones had to learn how to articulate their ideas more effectively, the latter ones got finally the chance to dissent and propose, although still with hesitance, alternative suggestions. And everything happened in a more and more collaborative and fun environment as the time went by.
Respect of ground rules	The framework gave structure and a feeling of rhythm and cadence to the work. This made the rules of the game more visible, more effective and thus easier to follow, with a direct consequence on the kids’ ability to respect ground rules about living at school and outside the school.
Personal interest	The interest of the kids into all activities and consequently into the studied discipline was very high throughout the whole experiment. This gets even more relevance if analyzed in comparison with the same discipline studied in the previous school year. The clarity of the expected outcome and the enablers in the framework gave the possibility to constantly reflect on strengths and improvement areas and directly act on them both on individual and team level. As a consequence the level of ownership was always pretty high.
Motivation	Capturing attention and stimulating motivation is usually pretty hard with a subject like geography at a primary school. Differently from last year and from former professional experiences the teacher had with grade 5 students, there was no need to motivate kids to learn this time. They just showed so much drive towards their goal and how to reach it in the best possible way, that no additional motivator was necessary.
Engagement	The participation to the class activities was very high. The major educational success of this activity was determined by the high level of engagement, especially of those who were more prone to lose focus and used to participate less. The proposed project looked just like a technical and graphical activity, but in reality required an accurate study of the discipline, which the kids accomplished without even realizing it. The strive to achieve the final result pushed them to research as much information as possible, in order to deliver a quality product (the map) which was easy to understand also for the classmates, who had not studied the specific region.
Commitment	The level of commitment was simply a result of motivation and engagement, so obviously the results were very positive. The students who were used to achieve outstanding results, simply excelled in the project. But most important, the kids who were used to struggle to achieve a sufficient grade, reached educational results far above their average, also thanks to the support and help from their teammates.
Planning and time management	One of the biggest outcomes of this project was the improvement in terms of ability to plan the work and time management: at the end of the year all the students reached an outstanding level of autonomy and self-organization. Even the kids, who had more troubles in finding an effective time management approach, had the chance to catch up thanks to the intrinsic focus and the teamwork.
Competence level	The class group which experimented this project had already pretty high average level of proficiency and grades. However the multiple elements, emerging from the project, contributed to determine a generally much more positive grade compared to the results achieved by the same students in previous school years. It is interesting to highlight that the results achieved have been even more positive for the students who had already outstanding grades. Those who had good grades accomplished remarkable improvements, with a greater awareness of their own abilities. Those who barely reached a sufficient grade had numerically better grades, but the fundamental outcome of this experiment was an actual acquisition of new competences from all kids. Those competences include the ones that in the European Commission White paper “Teaching andlearning: Towards the Learning Society” are denoted as: the Know-how (skills), the Know-how-to-be (attitudes), the Knowledge. These are the goals to purse at school: the students must acquire Knowledge (Rome is the capital city of Italy; Monte Bianco is on the Alps, etc.), but they have to acquire also, and much more than the mere knowledge, the Know-How (logical skills, intuitive skills, linguistic skills, etc.) and the right Know-how-to-be. Actually the most important task of the school nowadays should be to help kids learn how to learn, so that they can keep learning for the rest of their life and the applied methodology seemed to support very much this direction.

Conclusion

The experiment tried to give an answer to following questions.

Can Scrum used in education support to create a learning experience for kids which would encompass the following?

• Being more adaptable to a kid’s specific learning needs
• Being a meaningful experience involving feelings and physical emotions
• Fostering self-development and co-education
• Training skills which are crucial in the 21st century and the school is traditionally not that good at teaching, e.g.
• self-organization
• leadership
• ability to plan
• imagination
• self-reflection
• dealing with uncertainties and the unknown

Can this work in the context of a primary school in the South Italy?

The empirical evidence of what happened during the experience (including the observation of the behaviors naturally nudged by the adoption of the Scrum framework) as well the collected results, encourage a positive answer to these questions and validate the assumption that Scrum is a powerful change engine in many different contexts.

Scrum is founded on empirical process control theory, which asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize chances of success when addressing a complex problem, a problem where solution is unknown or multi-faceted, including learning something new.

Empirical process control has three pillars: transparency, inspection, and adaptation. When you manage to create an environment where the values of commitment, courage, focus, openness and respect are embodied and lived by the Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. Then people, whether kids or adults, are capable to learn and explore as they work with Scrum.

On top of that, the students could engage with their classmates and their teacher in a much more human and profound way and live an experience they will probably remember forever and tell to their grandchildren.

And that’s what made this experience mostly rewarding for my brother and me!

Happy Scrum students with their teacher :)

Agile Education at a primary school in Italy - Part 1

Agile In Education Compass - designed by Stuart Young (Radtac) 

My brother Marco is a primary school teacher in Italy. 

From this perspective we share a common interest, since I am a trainer and I am interested in how people learn. 

I’ve been actually interested in that for more than 25 years: as a Scout leader it has been very clear for me that educating boys and girls is giving them the opportunity to learn and become the best they can be.

It is not by chance that the verb “to educate” comes from the Latin “ex ducere”, which literally means “to lead out” what a person already potentially is.

Last year we happened to talk about how to create a learning experience for primary school kids which would encompass the following:

• Being more adaptable to a kid’s specific learning needs
• Being a meaningful experience involving feelings and physical emotions
• Fostering self-development and co-education
• Training skills which are crucial in the 21st century and the school is traditionally not that good at teaching, e.g.
• self-organization
• leadership
• ability to plan
• imagination
• self-reflection
• dealing with uncertainties and the unknown

As an Agile coach and trainer, all these things resonated a lot with me as they sounded like the skills of true "agilistas" or the characteristic of an awesome Agile team.

On the other side, I was aware of the many experiences in the field of Agile in Education, which are summarized on the website agileineducation.org and conceptualized through the Agile Education compass created by a group of Agile educators at the Scrum Gathering in Orlando in April 2016.

So the proposal was kind of natural: why not trying a learning experience based on Agile values and principles? Learning and using the Scrum framework looked to me the simplest and most straightforward option to help the kids practice agility at school.

The very first step was actually to educate Marco in Scrum: I led him through an introductory session to the Agile manifesto, Scrum and its foundation, including Empirical Process Control.

This was enough in catching him up in the idea: the confidence in his older brother did the rest in accumulating enough enthusiasm and motivation to get going with the whole experiment J

Basically we wanted to have a first-hand validation that applying Scrum in a primary school class is doable, kids enjoy it, they can learn faster and practice skills they normally do not in a traditional classroom environment.

Below I will describe the whole concept we adopted, how we structured it, a report of the different phases and some final results we achieved (I will actually split the whole story over a couple of posts to make each post reasonably short).

Selecting the project

The first problem to solve was to pick a learning project which was suitable for the experiment.

It should have been challenging enough to get a meaningful result out of it.

At the same time it should have been concrete enough, so that the kids could actually produce something tangible (iteratively and incrementally) and see the outcome of their work.

There is no Scrum team without a productJ.

The class consisted of 19 kids: considering the recommended size of a Scrum team between 3-9 people, the selected learning project should have been suitable to work in multi-team environment. Multiple Scrum teams had to work in parallel on the same product and get success by collaborating and integrating their work, hopefully at each and every iteration.

The natural choice emerged to be an interdisciplinary geography project, including learning objectives in arts (mainly image), math (mainly statistics) and humanities.

Students in the 5^th grade are supposed to study the whole Italy and specifically each of the different 20 regions which form the country. This looked very promising for creating a backlog of multiple items, which many teams could work on at the same time: each Product Backlog Item would have been one of the 20 regions.

Kick-off

The whole experiment started in the first week of November 2016.
In a previous meeting, Marco had informed all parents about the trial which would have involved their children during the year. He explained them the idea and the rationale and all of them showed curiosity and agreed to move on, based also on the trust they had in the teacher.
The kids were also prepared. They were informed that this year they would have studied geography in a different way: they got full of enthusiasm but also expectations.

Whenever I kick-off one or multiple Scrum teams, I basically help them learn three things:

1. Know about the Process
2. Know about the Product
3. Know about each other

So, we reserved one full school day to achieve the following results:

• Deliver an introductory training on Agile and Scrum to all students
• Create and kick-start the different teams
• Getting the teams acquainted with the backlog
• Hold the first Sprint Planning

Marco introduced the day and then we had a 2-hours interactive training so that the kids could understand:

• What is the most suitable approach to solving complex problems, like learning something new
• The Agile values and principles'
• The Scrum roles, events and artifacts

The day could have not been started better than by trying the Marshmallow Challenge and learn the beauty and effectiveness of “prototype and refine” and why it works better than planning upfront and just following the plan, when an individual or a team faces something they have never tried before.

It was just amazing how they immediately grasped this and made all sense to them.

At the end of the 2 hours they could explain what a Product Owner or a Sprint is.

After a short break we moved to their actual classroom where my brother had prepared all the necessary supply I had instructed him to buy to facilitate the day and the team work.

So we started presenting the backlog. To make the final product visual, Marco prepared a big blank map of Italy, just reporting the borders of the different regions (see the draft picture below).

Each backlog item (i.e. representing each of the 20 Italian regions) had to fulfill the following Acceptance Criteria.

• A construction paper shape of the region must be prepared:
• Borders must conform to the map
• High and low grounds are represented
• Hydrography is represented
• Cities are positioned properly and regional/provincial capitals highlighted
• Different sectors of local economy are represented 
• Peculiarities of the region are highlighted
•  A report on the whole region must be prepared and shared by the team with the whole class

In that way the kids had something concrete to produce and an underlying architecture which made integration easy. At the same time the different teams could work independently.

Then we moved to form the Scrum teams: with a class of 19 kids we decided to split them in three teams. The teacher would have the role of Product Owner and I would formally act as a Scrum Master for all teams.

However I knew that I could not be present so I instructed my brother that he should work as a facilitator as well and take actually care of the Scrum Mastering part, while I would have coached and consulted him remotely along the way.

During the preparation phase we evaluated whether it would be a good idea to let the kids self-organize in three teams by following a certain number of constraints, but we discarded the option. Marco did not feel too comfortable and he wanted to make sure that the groups had enough diversity from many perspectives, including different learning styles and proficiency at school, which probably the kids would have not been able to take into the right consideration themselves.

So we proceeded with the splitting: the first empirical evidence was that they did not look surprised at all about how their teacher split them up and no one complained. This might mean either that the split made sense to them or they simply did not care or did not dare to speak out about their teacher’s decision. Having interacted with the kids and having seen the teacher-students relationship in the class, the first option looked more plausible to me.

Then we gave time to the different teams to select a team name and logo and enjoy some practical activity to create their task boards, pick a corner in the classroom space, hang the whiteboard on the wall and craft their own team space.

The next step was to stipulate an agreement on our routines.

When it comes to decide the Sprint length and day/time for the different events, we had some constraints:

• Marco works only 4 days a week in that class (school week in Italy is 6 days)
• We wanted the kids to work on the project mainly at school, not at home, so that we could observe and facilitate team dynamics
• I had mainly Friday and Saturday available to join them remotely over Skype

The agreement came pretty constrained:

• Sprint length: 3 weeks
• Sprint Planning: Saturday mornings
• Sprint Review and Retrospective: Friday after lunch
• Daily Scrum: 8.45 in the morning (but 4 times a week,  when my brother was in the class)

The different teams worked on drafting their own team ground rules on a flip-chart, which they then hung in their team space.

Last step before moving to Sprint Planning was to draft the first version of Definition of Done, which I renamed with the slogan “We will have done a good job, if…” to translate in a more suitable language for 5^th graders J

Here below is a picture of how one of the team’s corner looked like at the time they were building it the first day.

We had finally everything ready to get going with the first Sprint Planning.

My brother explained the first few backlog items on top of the backlog, re-read and clarified the Acceptance Criteria. He mentioned more than once that each team could pull any backlog item they wanted in the order they were presented, but if they felt that one item was too much to get done in 3 weeks, he was available to discuss possible ways to split the work in smaller chunks.

No team actually considered this as necessary and on the other side no team believed they could take more than one region into the Sprint. The whole class collaborated to agree which team pulled which of the top 3 items in the backlog.

The teams moved to decide on how the chosen work would get done. 

I instructed them to split the Backlog items in smaller tasks and the kids even started pulling tasks.

Each student designed a magnet with his/her own avatar and put it close to a post-it. 

We encouraged pair working from the very beginning.

The day ended with a celebration.

The kids were extremely happy and enthusiast. Some of the comments I got from them included:

• “Will you stay with us for the whole school year?”
• “I usually have troubles in following, but today I understood everything”
• “We love you!” (This obviously moved me to tears!)

It looked like we were on a good track and had managed to create the right foundations for the experiment to give the expected results.

Side note: the day after, I met the mother of one of the kids, which is a dear friend and an ex-school mate of mine. 

She stopped me and asked: “What the heck did you do at school yesterday? My son came back so enthusiast like I have never seen him before after a school day!”

I was in a hurry: I simply smiled, hugged her and left. This event triggered the idea to involve the parents as much as possible moving forward in the experience.

Stay tuned for the continuation of the story in a coming post!

How to teach Scrum to your boss (and why)

One of the biggest challenges I usually faced in my experience as Scrum coach is not really related to Scrum as such, but more to the consequences that Scrum creates in the organization by exposing the real problems.

So it often happens that some people (especially among managers and senior technical experts), afraid of losing their position, start to get alarmed by the serious challenge of the status quo and do their best to slow down the change.

Ever seen that? I'm sure you have. 

And if you want to have any probability of success with Scrum, you'd better do something to address the natural resistance of middle management to move away from a command and control leadership style.

Where to start? Don't look too far: Start with your boss. 

Help her become a professional 21^st century manager capable to build a trust environment where people can develop and team can flourish at their best potential. If she becomes knowledgeable enough, she will understand and consequently start dismissing traditional management practices, which make no sense and are even detrimental in a knowledge working environment.

That's what I normally do with the managers I work with.

In two of his inspiring articles, Steve Denning, author of the best selling book The Leader's Guide to Radical Management - Re-inventing the Workplace for the 21st Century, says that Agile is The Best-Kept Management Secret on the Planet and that Scrum is a Major Management Discovery. 

Bingo! If you want your boss to support your company Agile transformation and introduction of Scrum, you just have to teach her... Agile and Scrum.

How can you do that?

1. Training and self-education

I dedicate a consistent amount of time in delivering training to managers, in individual coaching as well as in team coaching with the Leadership team. 

The Management learning program I propose has the following structure:

- Kick-off with 2-days Scrum training

- 2-days Lean and Agile Leadership training

- Individual and team assessment to identify strengths, improvement areas and further learning needs (I described a bit the content of the assessment tool in a previous blog post).

- Training program (monthly sessions) based on assessment outcomes, which is usually self-led by managers pairing up with a coach and leveraging on a Learning by Teaching approach

- Weekly self-learning activities (Lunch and learn or Lunch and share, Book club)

2. Gemba

Respect is one of five Scrum core values. Getting bit deeper than its generic surface, it means giving people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. It’s about staying close to the teams, where "real" things happen and you can identify ways to improve the system .

Gemba is the Japanese word which means "the real place" (for instance Japanese detectives call the crime scene gemba). So if you want to help your boss to learn Scrum, encourage her to walk where work happens and Scrum actually comes to life.

In all teams I coach, I try to introduce managers into this “go and see” culture, not only with the goal of getting them to understand teams’ problems and ready to support, but also for making them learn Scrum by interacting with a real Scrum team.

Advertise Sprint reviews (maybe posting catchy flipcharts) or encourage your team to forward invitation even to top managers: for some of them it might be a culture hack, because they might think it is a development team’s stuff.

Pass by your boss' desk and invite her to join for the Daily Scrum. She might claim that she does not want to disturb the team: challenge her to stop asking weekly reports and join the Daily standup instead.

3. Deliberate Practice

Scrum is founded on an empirical process control: the biggest amount of knowledge is created by experience and feedback.

I usually coach the Leadership Team to use Scrum for their work, so that they can learn Scrum by actually practicing it.

Have your boss feel the pain as well as the excitement of working in short iterations.

Additional suggestion  

Have a look at the book Teaching smart people how to learn by professor Chris Argyris, Harvard Business School. 
He talks about avoidance of learning and how discrepancy between espoused and actual theories of action harms people’s learning: these are actually the biggest problems I found with people and especially with managers which you would not classify as innovators or ealry adopters in the Rogers’ Bell curve on diffusion of innovation.

So try to keep an empiricist approach: you will lower down your boss' defends and have her more open to new things, because she would feel less in danger.

Address concrete and painful problems and show how Scrum can help her with them. Avoid to fall into the trap of: "this is Scrum, this is not Scrum", or "this is right, this is wrong". Escape discussions based on personal opinions, but try to build a we-are-together- against-the-problem atmosphere. At least you will save a lot of talks and useless discussions.

Warning 

I learned not to waste too much time with laggards and cynics. So if you classify your boss like that, just spend enough time to make sure she does not pull others and the organization to old behavioral patterns. 

Or better, quit your job!

What the hell is a Sprint Review?

This is the last post before New Year’s Eve: so it is time to “review” the year which is going to give us the gift of enjoying the last days in its last month. That’s why I decided to spend few lines about Sprint Review.

2013 has been for this blog quite an interesting journey of 22 articles: I learned a lot by publishing them and I hope the 9000 readers (R)Evolutionary Agility had in the last 2 years have learned something as well. I wish you all an exciting and joyful 2014!

Some weeks ago I delivered a 3-days course for Scrum Masters. I usually visualize the agenda as a backlog of subjects we prioritize together throughout the training.

During a coffee break a guy approached me and asked: “I recognize the different ceremonies in the agenda, but I never heard about Sprint Review. We normally do a Sprint Demo: is it the same thing?”

“It depends on what you do in your Sprint Demo. Can you tell me more?”, I answered.

“Well, at the end of the iteration our Program Manager calls for a Demo meeting. All Scrum Masters are attending and reporting what we have been doing during the past 3 weeks”.

“So what are you demoing then?, I asked.

“We’re presenting a powerpoint slide set, showing a detailed report of the different activities during the Sprint, who was doing what and how much time was spent given the people allocation”.

Again? Yet another manipulated buzzword!?

And yet another empirical evidence of how an organization can produce so powerful antibodies to resist and protect itself from cultural change bacteria.

So let’s see if we manage to inject some virus of learning and growing mindset: these are usually quite effective in spreading willingness for improvement.

Let’s start from some why: why is a Sprint Review important? What is the purpose it is meant to serve?

Scrum is grounded in empirical process control theory and therefore uses an iterative and incremental approach to optimize the path towards a certain business goal by means of fast feedback loops. 

As any other implementation of empirical process control, it is based on 3 pillars:

1. Transparency

All information necessary to handle the process must be available to those handling the process

2. Inspection

The different aspects of the work must be inspected frequently enough so that unacceptable variances can be detected. Of course the skill and diligence of the people inspecting the work resul matter.

3. Adaptation

If the inspector determines from the inspection that one or more aspects of the process and the resulting product are unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Sprint Review meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint.

The Sprint Review is then an important learning point and a fundamental step in the empirical process control applied by Scrum. That’s why calling it just “demo” is mislabel, since this word does not capture the real intent of this ceremony. Let’s analyze what might be the learning points for the main actors:

• The Product Owner and key stake-holders learn what is going on with the product, what are the results of the Sprint and check whether those results are able to bring the whole Scrum Team closer to the Product Vision. The Sprint result will have anyway impact on the Product Backlog for the next Sprint Planning: new stories might be added, changed or removed and prioritization might change.

• The Development Team learns what is going on with the Product Owner and the market. They also learn whether the Sprint Result validated the assumptions they made during the Sprint Planning. For that reason it might be useful to review the estimates, to check whether they got confirmed after the story was actually built: in this way the team know how to estimate better and build a better baseline to relate further estimations. They’d better review also the different team metrics and the Sprint Burndown Chart to gather interesting data for the coming Sprint Retrospective. Review of Team Working Agreements and Definition of Done will indicate the team whether what they learned during the Sprint can affect the team’s rules or their quality criteria.

For these reasons, the most important element of the Review is the conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth.

It is a public ceremony: the Product Owner, Team members, the ScrumMaster, plus customers, stakeholders, experts, managers and anyone else interested is allowed to attend and anyone present is free to ask questions and give input. The Scrum Master will work to maximize the learning of all participants.

Even though calling the Review just “demo” doesn’t really make the point, the demo is anyway an important part of it. But what does it make sense to demo?

Let’s have a look at some of the Principles in the Agile Manifesto:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

7) Working software is the primary measure of progress.

It doesn’t mention powerpoint slides, right? J

So the only demo which makes sense is showing an installation of an integrated potentially shippable product increment. BTW, the Product is the only language which everybody, from business to developers will understand the same way.

Remind: spend as little time as possible on preparing for the demo. If you need to spend a lot of time there must be something wrong somewhere.

If you read and liked this article, I have a question for you: 

How will you change your next Sprint Review?

An Agile Conference in the Heart of Europe

Last week I went to Agile Prague 2013 conference.

The conference was great and again I would like to share with you the most interesting take-aways I brought home from the sessions I attended.

1. The first one is from Scott Barber’s keynote.

He had a point that, regardless the fact that we talk about SW engineering, we are not very much learning from other more “classic” engineering fields. For instance in SW industry many still doubt about the value vs. cost of testing and there’s a spread tendency of considering SW development like manufacturing instead of R&D. That’s different in Classic Engineering, which is by the way a far more mature industry:

- No one questions the value of testing: how could you put a bridge in production without producing a prototype and testing it thoroughly?

- The Team is both responsible and legally accountable for quality/safety

- “Go Live” decisions are (relatively) easy

So we would be well served to study “other” fields of Engineering, consider real R&D practices for new software development and forget titles, but be responsible and accountable as a Team.

2. The second great insight was from Kevlin Henney’s keynote.

He started from the consideration that you’d better concentrate on what you can complete, because you learn by finishing things (as btw we are all taught by the Lean SW principle “Deliver as fast as possible”). So he introduced a theory from 1990, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention.

And yet we have not learnt this lesson in 2013!

The theory claims that it is far better to have an under-featured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.

This is all at the heart of Agile SW development, in contrast with the classical “The right thing” design philosophy and the failing ambition to define everything from the beginning. Ralph Jonson said: “Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other”. An empirical process control is what works best in SW development: properly gaining control of the design process tends to feel like one is losing control of the design process.

3. David Hussman in his provocative talk “Renaissance, Reformation and NonBan” urged the need for a Renaissance and Reformation of Agile back to its original spirit and practices from what sometimes now became only yet another process. We should learn again from masters like Ward Cunningham, Alan Cooper or Jeff Patton. What’s old is new again and very much necessary: storytelling, pairing, test driven. We need for instance better discussions, not better documents. What other reforms are needed today? He proposed NonBan: the least amount of process adopted by very skilled persons with the most real and measurable value. Interesting perspective, isn’t it?

4. Finally I found inspiring Andrea Provaglio talking about Dreams. He presented an organizational model based on 3 pillars: Dream, Order and Action. The Dream is about intent or vision, Order is about rules, functions and procedures, while Action is about production and skills. He mapped very nicely this model into Scrum: the Dream is the Product backlog, the Order are the Scrum ceremonies, while the Action is the Sprint, where a Dream-bit (a User Story) is actually transformed in a potentially shippable product increment. As counterpart of Dreams there are Needs, stuff that we need to do, like defects to fix. They fall into the backlog as well and it would be interesting to measure the Dreambits/Needs ration in our Product Backlog.

I gave my contribution to the Conference by delivering a session called “12 ingredients for a successful Agile transformation” which had quite a big audience and which is based on a series of posts I published on this blog (see Part 1, Part 2 and Part 3).

You can find all presentations stored at this link.

Videos from all sessions will be soon available at this link.

If you like to get info on the progress, follow @Agileprague on Twitter.

After my presentation I got an interesting question: "Do you think that signatories of the Agile Manifesto had foreseen that all in 2001?"
I answered: " I do not know if they had envisioned this when signing the Agile Manifesto, but I challenge anyone to demonstrate me that you can really implement Agile values and principles without all that is needed to transform the paradigma of an organization".

Does anyone feel like accepting the challenge? :)
What's your opinion?