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!

The User Story Workshop

User Stories in Oxford by Jacopo Romei / CC BY 2.0

What can you do when you need to write a considerable number of User Stories in a very short timeframe?

Why a User Story workshop? 

It is a useful tool to achieve the goal of writing many stories fast, especially when the development team has a lot of technical knowledge, or there is a lot of knowledge outside the team to be used to complement Product Owner’s domain knowledge.

What is a User Story workshop? 

When starting a new Release, I suggest to run a a workshop with the Product Owner, the Development Team(s) which will build the specific product and all people who can contribute, regardless of their role. 
The goal of the workshop is to come out with as many User Stories as possible, which can solve the problem(s) represented by a given number of requirements.

How to run a User Story workshop? 

Here is the structure I usually propose:

1. The Product Owner presents the goal for the next Release and the most important requirements. This normally takes about 1 hour: participants normally ask clarification questions

2. Participants are split in groups of 4-5 people and we do a number of (usually 3) 1-hour iterations structured like that:

2a. Group brainstorming to elicit as many stories as possible (30 min)

2b. Group work integration, where groups review each other work, find similarities, remove some stories, etc. (30 min)

The next iteration might continue on the same requirement or on a different requirement. Sometimes I tried other creativity techniques besides simple brainstorming, like Lateral Thinking techniques, e.g. the anti-solution.

Especially if it is a newly formed team, not so used with writing stories, I provide a pattern to follow to brainstorm stories.
 I ask the team to look at the system from outside-in and ask themselves who, what and why:

- Who is the user who will benefit from the specific function?

- What is the function which might contribute to solve a certain problem?

- Why is that function needed (to solve which problem)?

My experience

Generally speaking I found the User Story workshop very effective: it helps the team focus on the goal and make an efficient use of all brains around. You can easily write 50 User Stories of different granularity in 4 hours: sometimes more time is needed to achieve the intended goal, but I always prefer to start with no more than 4 hours and have other sessions if needed.

Learning

In order to make the US workshop effective, the people involved should have been trained in what a User Story is and how to split the work in small slices which cut the system vertically and allows building an iteratively evolving product which continuously stays shippable. 
When needed, I propose and facilitate a very effective workshop to teach how and why splitting a product in small vertical slices: the Elephant Carpaccio exercise invented by Alistair Cockburn.  
I do recommend these 2 hours of learning, engagement and fun.

What is preventing you to try it out tomorrow? 

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?

Applying Agility to training and education

You know: I strongly believe that Agile values and principles apply and work very well whenever you have a complex problem to solve, something that you have never done before.

So, if you have a vision of what to reach, but do not know where exactly you’re going and your domain is not deterministic, there’s no chance you can define your path upfront: the most sensible approach you can try is to do one step at a time and strive for fast feedback to verify your assumptions and adjust consequently.

Therefore an Agile approach suit very well many different fields, even outside IT, given that people involved in solving the problem have the right domain knowledge. 

For instance, as a trainer, I use an Agile approach for designing and delivering my Agile and Lean courses to Product Owners, Scrum Masters, Teams and managers.

Last week I got interviewed by 4 students from a Human Resources Master (a psychologist, a sociologist and two economists) about my thoughts and experience on applying agility to training and education, which is actually a complex domain. The interviewers resulted to be very passionate about the subject and it was really an interesting 3 hours long discussion about many aspects.

I will try to summarize the outcomes here by using the same pattern we followed during the session: going through the values in the Agile Manifesto and try to understand how they can be concretely implemented in the domain of training development and delivery.

1. Individuals and interactions over processes and tools

We normally use a collaborative team approach (2-4 people) when designing a new course. We try to understand the learning needs of the client and ideate possible solutions that are pulled from the backlog and implemented incrementally by leveraging on pair working as much as possible. We use a task board to visualize the work and understand the progress.

We apply pair training for delivery and try to foster a collaborative approach in the class, where the trainers are mainly facilitators of people learning using different teaching techniques.

We use tools like working agreements to set a stage of ground rules for the class. Understanding is prioritized over delivery of a pre-determined content and physical tools and face-to-face conversation are preferred over other ways like web-based training.

2. Working software over comprehensive documentation

We try to get feedback as fast as possible as we proceed with the training design, by showing concrete examples of what we have in mind (slides, activities, other material) in order to validate our assumption and verify whether they match clients’ learning needs. That’s in contrast with detailing the training contents up front in a document and hoping to get feedback on that, where clients do not have necessarily the domain competence to understand and to map it with their needs.

We also think that learning is achieved by means of a complex recipe, where magic happens during live training delivery due to a combination of good material, inspiring activities, group collaboration and teachers’ skills. That’s why we do not aim at producing documentary or even self-explanatory material, which often gets the result of having neither good training material nor good documentation. Training should inspire, provide a vocabulary, create curiosity and new questions, which can best be satisfied on the web or by reading books.

3. Customer collaboration over contract negotiation

As I said, fast feedback is crucial. For that reason you need to get your client involved in designing the training with you. That’s why we engage an early collaboration which happens face-to-face when possible or remotely (via mail, chat or phone/video calls).

When our contact person is not the primary customer of the training, we try to get in touch as soon as possible with a number of training participants (when they are available) to interview and get a better understanding of their learning needs or even help to get themselves understand their needs.

4. Responding to change over following a plan

We try to keep our options open until the last responsible moment, both during course design and delivery.

We’re open to late requirement changes as much as possible, stated that they fit the allocated timing for the training and propose other items to down prioritize if we think it adds too much to allocate in the given time frame.

We divide the course in modules and monitor the progress of the delivery by means of tools like task board or burn-down chart, so that we’re ready to adapt. We follow a time-first planning approach: we always finish on time and if the timing doesn’t go as planned, we decide which modules to cut together with the class.

Looking forward to your comments, if you’re interested or have experiences in the field of agility applied to training.

P.S. Thanks Valentina, Lydia, Patrizia and Francesco for the awesome chat and all the best for your work.

Roadmap planning

As you might know, different levels of planning apply to an Agile SW development (actually, beyond what you can see in the picture, you have also the Sprint Planning and the Daily Planning).

It’s continuous planning with the different levels influencing each other by feedback both between levels and across levels in order to respond to changes. 

It’s a Rolling Wave Planning approach, where upfront planning is reduced to the minimum indispensable, to what is “just enough, just in time”.

As one can see, despite the myth about Agile meaning “coding with no planning”, there’s probably much more planning in Agile than in a waterfall approach.

In preparing for battle, I have always found that plans are useless but planning is indispensable.         

-Dwight D. Eisenhower

Last week we experimented a new way of Roadmap planning, aiming at understanding what will probably be contained in the coming releases.

So far this kind of planning had always been done mainly by the business guys, based on their level of understanding of customer requirements, their perception of the possible solutions and partly on wishful thinking.

This time we decided to do it differently, trying to take decisions or at least draw possible scenarios based on facts as much as possible. Once again the best recipe turned out to be a collaborative approach.

The decision was to call for a 4-hours workshop (it was actually 2 slots of 2 hours each) attended by the Product Managers, the Product Owner Team and a bunch of system architects.

The Product Managers brought to the workshop a list of prioritized requirements to analyze.

We decided to dedicate no more than a defined time-box to each requirement in priority order, so that we did not spend more time than strictly necessary at this very early stage of understanding.

The time-box was divided in 3 parts:

1.      1/3^rd to explain the requirement and clarify background and business value

2.      1/3^rd to sketch possible MMFs or epics

3.      1/3^rd to estimate the MMF or epics, a relative estimation using as a baseline the actual story points spent by our teams to deliver the MMFs in the last 2 releases

Everything was done collectively. After the workshop, given the number of sprints contained in the coming releases, the PO team did a date first planning, by considering the actual velocity statistics of our organization.

Based on that, we determined scope scenarios for the coming releases, considering the worst and the best cases in our recent history.

The feedback from participants and stakeholders both on the approach and the outcome was pretty good and I must say it looks very promising to me as an Agile coach.

At least it meant providing “just enough, just in time” information (even if rough) based on the current knowledge and understanding of requirements and above all on real data coming from our actual historical performances.

How to build a big product in a collaborative way – 2

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.

How to build a big product in a collaborative way - 1

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and with a project staff, headed by an expert project manager, to coordinate everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The best architectures, requirements, and designs emerge from self-organizing teams.

What do I get out of this??

Well, first that SW development is a collaborative game by its nature: there’s no complex problem which can be solved by one person in a time which is compatible with modern business needs.

Secondly that self-organization and servant leadership are some how embedded in being Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: Scrum Master, Product Owner and Development Team.

I'm sorry: no project manager whatsoever.

Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. 

I’m rather referring to roles and their effectiveness in an Agile context, in terms of: What is the probability I might have success in an evolving reality?

Said that, what I would suggest to a Scrum organization is to setup a Product Owner Team.

Yes: a self-organized team formed by all development teams’ Product Owners collaboratively working together. And I’m suggesting that, because I’m currently coaching a PO Team and I would like to tell my experience through this and some other post I’m planning to write.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog to feed all development teams, so that the following is ensured:

1. the whole organization is focusing at any point in time on the most important items
2. the development teams are as much independent as possible so they can move fast with little need to coordinate each other
3. the overall architecture of the system is preserved 

Like any other Scrum team, a PO Team might better have a Scrum Master or Team coach (it’s just me in our case) and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

To tell you our story I will start from the beginning and that’s the team setup.

In a recent post I described how it is important for a team’s success to set the stage to high performance and that’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

And we really started from the foundation by writing together our team vision and the ground values we wanted to build our team upon, as you see in the pictures below. After few months I really recognize that this exercise had proved to be tremendously effective.

So we set the first draft of our working agreements.

Since I wanted to introduce the Scrum values in the team in an organic way, I let them decide completely how to organize in the first place and here come our ceremonies:

• Global Backlog grooming once a week
• Global Release planning once a week
• 15-min daily standup everyday
• Review of work done at least by another team member according to our Definition of Ready
• Team retrospective once a month

I will describe each of these ceremonies, make you see our awesome task board and tell you how we build our backlog starting from customer needs in a number of coming posts.

Talk to you soon!