"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change!" - Charles Darwin

Friday, 8 September 2017

Agile Education at a primary school in Italy

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 few 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 5th 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.


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: 9.00 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 5th 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 the coming posts!

Monday, 3 July 2017

3 signs your daily Scrum sucks (and how to cure them)

It is actually a long time I have not written an educational article on Scrum. 
I have recently found some notes from a conversation I had with a community of Scrum Masters few months ago and decided to package them into a blog post. Hope you appreciate it.

So here are three small and easy to observe signs that you need to fix your Daily Scrum.

1. People are only interested in their own tasks.
I found that this behavior is also pretty encouraged by the common way of running the Daily Scrum, i.e. the famous three questions. I found many times that people normally follow with attention until it is their turn to speak; they simply disconnect after that.
When I see this, I normally propose the team to try a different way of handling the stand-up.
One way that works is to keep the same 3 questions, but have 3 rounds instead of one, with each person answering only one question at a time. 
This usually gives two benefits. 
The first of course is to keep people actively engaged until the end, since they know they will have to speak again. 
But there’s a more important one. It serves better the real purpose of the Daily Scrum of collectively assessing where the team is compared to the Sprint goal and collaboratively deciding what the next most important task is for each team member to complete, in order to move closer to the Sprint goal.
Another way (which brings even more benefits in my experience) is to run the stand-up not focusing on people’s tasks, but on User Stories. 
The idea is that the team takes one User Story at a time from the top and discuss about how to make it “done done” as soon as possible. Then you take the next and move on, either until you covered all the opened stories or until the 15-minutes time is up. In that way team members do not focus on the individual tasks, but more directly look at the Sprint goal as a collective goal to achieve. Sometimes you do not manage to talk about lower priority stories, so people who are working on those feel a bit excluded J. That provides some social pressure to contribute to complete the highest priority stories first, instead of minding their own tasks.
2. Everybody is looking at the Scrum Master instead of at each other
Sometimes it feels more like a status report. So I use the trick to encourage them to stay in circle, closer to the task board, and I take (or ask the Scrum Master to take) a step back, pretending I’m taking notes. I avoid looking at them in the eyes, so that they feel a bit uncomfortable and they are forced to find other eyes to look into: their team mate’s eyes. It works immediately most times.
I use the same trick also when they tend to look at their manager attending the Daily Scrum: I encourage them to stay in circle, leaving all other attendees outside.
3. People tend to have long discussions, trying to fix problems during the stand-up
I know that many Scrum Masters tend to interrupt discussions or ask people to continue discussion outside the meeting. This works some times, but many times I found that a bit irritating. I try to use and teach a different approach.
I normally try to explain at the beginning very clearly to the team that the Daily Scrum is intended for the Daily Planning, so that everybody understands and buy into this . So, when I see that a discussion is going on, I leave room for a couple of minute. If it is not concluded yet, I ask a question like: How do you think this can affect today’s planning? Most times people admit that it is not strictly relevant and propose to park it.
On top of that, in order to have the team really self-organize, because it is everyone’s responsibility to keep the time of the Daily Scrum, I always use a timer (a digital one or a “pomodoro”) to visualize the time passing and signal when it is up, so that the Scrum Master does not act as the bad time-keeper guy.
Of course the three above and other dysfunctions might be just a symptom of something deeper. 
If the techniques illustrated above do not work, it can be a smell of something more important that must be addressed.

What are the dysfunctions in your Daily Scrum?

Saturday, 20 May 2017

The 21st century´s paradigm to connect people and work to be done

Few days ago I had a phone call with a friend of mine. During our conversation she shared with me one of the challenges she is facing at work and wanted to check what I might think about.
Basically they have few issues when it comes to allocating people to work on a project they sold to a customer.

The challenges are multi-faceted:     
  • Finding people with the competences which fit that specific project
  • Finding people who are available to work on that project
  • Finding people who are willing to work on that specific project

Now the sweet point would be: a reasonable amount of people with the right competences, who are available at that time and willing to take on the project.

Very hard! Almost impossible! So what is usually the second best option?
Right! Put together on the project just who is available at that moment in time and hope it will not turn out too bad until someone with the right expertise can join and save the boat.

Does it sound familiar? I am sure it does, if we live in the same world.

But I have a second question: any guess what my friend’s job is?
Well, if you are thinking about anything among Project Manager, Development Manager or SW developer, you got it wrong. 
She is an architect: not a SW architect, a “real” architect.

If the fact that an architecture office might have similar problems to any product development company sounds unexpected to you, you have not considered the fact that the nature of the work is substantially the same in both fields: solving new problems which have undefined boundaries and multiple possible solutions within a complex environment where multiple entities influence each other in unpredictable ways.
To me this is just another confirmation of a pattern that I have seen in all organizations coping with work of such a nature and trying to apply traditional patterns to solve this challenge in the current century.

Can the situation be slightly improved by applying those patterns more efficiently? Probably yes and the PMI might have few ideas around that.
However my experience tells me that the problem cannot be solved if we do not embrace the fact that a totally different paradigm is needed.


  • Customer requests are more and more unclear: they do not know what they want. Problems are wicked: there is no pre-defined answer
  • Market is becoming more volatile: new and unexpected needs are emerging which require flexibility in companies
  • Professions are more and more specialized. Too many individuals I-shaped skills, which means they have deep knowledge and experience in just one area
  • Work is done in silos: lack of holistic view by individuals, but also knowledge domain in many professions is so big that is impossible for a single person to know-it-all
  • Having parallel projects competing for human resources is not sustainable anymore in the above context
  • Having people working on multiple projects reduces their effectiveness and productivity: context switching makes people waste time and produces stress, which can reduce IQ by 20%

So what is this different paradigm all about?

  • Understand the flow of value you create and setup stable, 100% focused, self-organized teams with a shared goal around your value flow
  • Bring highest value work to teams instead of allocating (or multi-allocating) people to work
    • Having the team as the atomic element simplifies allocation very much
  • Focusing on getting the most important thing out as fast as possible instead of focusing on making people busy (flow efficiency over resource efficiency)
  • Teams must be cross-functional: they must have all the competence needed to get work done
  • The holistic view of the work is kept at team level
  • Move from I-shaped individuals to T-shaped or even X-shaped professional who can do more things, so that you can have smaller teams with all needed competences
    • This can be partly achieved through synergies in teams, but also having the expert teaching to the others, to reduce the bus factor

Dare to take the journey? Do you have enough courage to address your own problems?

*In her book “Mindset”, Carol Dweck talks about the following concept: if you take two people, one of them is a learn-it-all and the other one is a know-it-all, the learn-it-all will always trump the know-it-all in the long run. See also what Microsoft CEO Satya Nadella said in an interview last year about his effort to overhaul the company culture.

Thursday, 10 November 2016

A conversation with the CIO community

Leadership quote by photosteve01 / CC BY 2.0
Last June I had the pleasure to get my interview published on Netweek, the biggest magazine for the Greek CIO Community (the Greek IT Managers are both readers and editors). 
I am thankful to George Fetokakis, Editor-In-Chief of Netweek to make it possible and for the interesting questions.

Since I realized that the interview was only published in Greek, I decided to post it here in English and share it with a bigger community.
Trust you will find value in it.
Looking forward to your feedback and comments.

1. How did you get started in the Agile world?
Interesting enough, I actually started my Agile journey in Greece. At the end of 2009 I got the chance to be part of kicking-off the Agile transformation in a big development organization of around 2000 people. So I got to spend 3 months in Patras, together with other 18 apprentice coaches from all over the world and 9 consultants among the most knowledgeable Agile coaches and trainers at that time. Every single day of those 3 months was an incredible learning experience and that still remains the most exciting and fun period in my professional career. Which better place to start a life-changing journey than the place which gave birth to the Western culture?

2. What does success mean for you in this world? 
In my opinion success in this context for a company or an organization means: effectively leveraging on Agile values and principles to achieve your specific goal sustainably in the fast changing world we are called to live right now.
For a development team success means delighting your customer with products that actually solve their problems. For me personally success means contributing to transforming our world of work in something more meaningful for human beings.

3. What are the top skills that an effective Agile coach should have?
The two coaching skills which helped me most in my 7-year experience as Agile coach are: empathy and situational awareness. Empathy is a crucial skill for coaches and leaders.
I learned that people want to feel themselves valued and appreciate when someone is truly listening and not judgmental. This doesn´t come easy: it is a skill to practice to be able to listen for potential, namely listening to people not for what they are, but for what they can become in the future and be committed to help them become the best they can be.
With situational awareness I mean the ability to be really present, observe carefully and understand what is going on around you: the ability of “reading the room” or “smelling the room” beyond what is said.

4. How Agile (and Scrum) has changed the way that the developers think and work?
Agile and Scrum are incredibly effective change engines: they trigger a paradigm shift in everything. Not only in how we develop products and services, but in how we lead, in the way we collaborate with each other, in the way we interact with customers, in how we consider ourselves as professionals. Embracing agility means embracing continuous change, which in turn simply means embracing reality. Someone said: life is what happens while we are making other plans. Believing that things will stay still just to please our plans is the ultimately insane wishful thinking.

5. Scrum is simple but not easy.  How difficult is to make a company Agile?
Being simple is definitely one of the strengths of Scrum but also one if its pitfalls: it is so simple that many managers fall into the trap of believing it can become a magic wand for the company´s problems. A famous quote from Ken Schwaber, co-inventor of Scrum, is: “Agile development will not solve any of your problems. It will just make them so painfully visible that ignoring them is harder”.
And that´s where the tough part starts! Scrum is not plug-and-play! It´s not just a SW methodology upgrade. It changes some of the basic assumptions about how products get developed! It´s like installing an iOS 9 app on an iOS 4: it won´t work! You need to upgrade the Operating System! Only courageous leaders, who are willing to make an impact, dare to start the journey to upgrade their company´s operating system.

6. What should companies do to achieve a successful transformation in the Agile world?
The first step is about asking “Why?” What is the problem we are trying to solve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. So any successful Agile transformation implies a top-down approach, in terms of Company values, leadership culture, business goals and management support. However, there are aspects that need to emerge bottom-up, like practices to be selected by self-organized teams. It has to be a sandwich strategy! Given the importance of the top-down part in the enterprise change, one of the initial steps is to educate managers, for them to understand the why, be able to share and communicate the vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritized, if not even neglected.
Finally it is extremely important that teams are organized so that they can deliver value to customer as fast as possible, replacing functional teams organized around the system architecture. Effective teams are cross-functional and have all the competences needed to transform a backlog item in a product increment within one Sprint.

7. What words of advice would you give to people who are just getting started with Agile themselves?  
Every context is different: so simply copying from others will not work. Scrum is a good way to start, it is a great teacher: if you have never tried Agile development, Scrum can give you the framework to be able to start. At the same time, you need to know many things outside Scrum to make Scrum work effectively: having an experienced Agile coach to guide you through the first challenges can be a key differentiator between success and failure.

8. What are the biggest challenges that they have to confront, what are the biggest mistakes that they should avoid?
I have seen few recurrent failure patterns: Product Owners without authority, knowledge or time, superficial knowledge and lack of coaching on Agile practices and principles, complacency as opposite to a culture of continuous improvement. Well, avoiding these failure patterns is one of the biggest challenges to confront. One of the biggest mistakes is considering Agile as something to implement: Agile is rather something you are or can be. Agile is an adjective, not a noun.

9. What should people and teams do to make their workplaces and lives more productive with Agile and Lean?
There are few things that helped me become more productive and I have seen also helping individuals and teams I have coached:
  • When you have a question to answer, spend time in understanding the question before jumping to the answer.
  • Do not make assumptions: genuinely ask why. If you have to make assumptions, try to validate them as soon as possible.
  • Challenge how things have always been done.
  • Work on your strengths, more than your improvement areas.
  • If you wish to succeed at anything, have a clear vision of what you want to achieve and consistently take baby steps in the right direction.

10. Where do you see things going to Agile in the future? What changes are coming?
I see contrasting things. From one side I see more and more “Agile” instances which have nothing to do with agility, where people and especially managers have lost or probably never got the original meaning of Agile manifesto: where, for instance, individuals and interactions are in service of processes and tools rather than the opposite. This can be also considered a normal evolution. When an innovation reaches the hype, it starts getting late majority or even laggards in the game: they probably accept Agile just to look fashionable or to please their boss. On the bright side I see a convergence of researches, theories, methods and practices coming from really different domains (Entrepreneurship, Neuroscience, Psychology, Finance, Management, Non-profits, even Military and Government) which are collectively creating a very visible red thread. And this red thread is all about coping effectively with fast change by using an empirical approach, embracing individuals as whole human beings not as resources to exploit, being mindful, decentralizing power, and creating meaningful relationships. That´s really exciting and resonates a lot with agility. On a broader scale, our generation is experiencing a growth in our consciousness as human race (let’s take for instance social responsibility) and that´s going to create benefits not only to our industry but to the entire world. 

Tuesday, 14 June 2016

Psychology of continuous improvement

Abanico en el mar by Ollui Samall Zeld / CC BY 2.0
I am an engineer! We engineers love well-crafted solutions.

Most of us studied Operations Research: we are excited by finding the optimal solution to problems and we like to fix all at once and even design future-proof solutions.

Sounds great to feel so powerful, doesn´t it?

But why is it so difficult to solve problems when they involve human beings?
Why can’t we make things happen even when the solution and the benefits appear so obvious even without analysis?

For instance:
Why can’t people simply quit smoking?
Why don’t most of us parents manage to get their teen-ager son to clean up his room?
Or why don’t we simply manage to increase the test automation level in our team?

Don´t they look like much simpler problems than many technical issues we face every day?

When it comes to challenges involving people, the issue is that human beings are not as nice creatures or as beautiful systems as the ones addressable by mathematical sciences, such as mathematical modeling, statistical analysis, or mathematical optimization.

God could have done a much better engineering work! Too many bugs J
  • We are the least rational creature on earth: we are driven by emotions and gut feelings at least as much as by rationality, but feelings take the lead many times
  • When the rational parts takes the lead instead, we usually got stuck in analysis paralysis
  • We are reluctant to change: we like our current way of doing things
  • We are programmed to save as much energy as possible: changing our routines  requires effort
  • We are blinded by cognitive biases: we interpret the reality not for what it is, but by comparing it with the maps we have been creating in our brain since we were born
  • We are addicted to the now and not very much used to accept delayed gratifications

So how can we ever achieve anything with such a flawed baseline system?

Imagine when you have multiple individuals together forming a team or even a bigger constellation: an organization!
Still surprised that up to 70% of all change initiatives fails? Can we ever succeed?

The good news is that human beings have also great properties and very effective strengths to use as leverages.
People are able to go straight to the point if they feel that the goal is clear and within reach and can be moved by incredibly powerful intrinsic motivators if they perceive the goal as meaningful and desirable.

All successful football coaches, for instance, know the trick very well.
How many times have you heard a journalist asking about possibilities of a team to win the championship?
And what was the answer from the coach every time?  “We want to play one match at a time”.

Good coaches do not ask their team to focus on the ultimate goal, but establish goals which are within immediate reach and clear criteria for their players to know when they have fulfilled those goals: by playing and possibly winning one match at a time, they get into the habit of winning and eventually win the championship.

Cheap and Dan Heath report in their book “Switch” that psychologist Karl Weick, in a paper called "Small Wins: Redefining the Scale of Social Problems," said: A small win reduces importance ('this is no big deal') , reduces demands ('that's all that needs to be done'), and raises perceived skill levels ('I can do at least that')." All three of these factors will tend to make change easier and more self-sustaining.

That´s why the Lean concept of Continuous Improvement (or Kaizen) is so effective and resonates so much with the way we as humans are wired: consistently taking baby steps in the right directions makes big goals appear more feasible to achieve.

However, being social systems classified as Complex Adaptive Systems, usually it´s not a smooth path of small wins.  More probably it will be about taking one step forward and two steps back, then three more steps forward and then five steps to the side. 
Nevertheless, by taking the vision of what we ultimately want to achieve well defined and in sight and, by coupling Hansei with Kaizen, meaning practicing Continuous Reflection at every step, we are much more well equipped  to achieve anything.

Instead, when a task is too big, the effect on human brain is overwhelmingly scary.
The book “Switch” reports also that Alcoholics Anonymous challenges recovering alcoholics to get through "one day at a time". To an alcoholic, going a lifetime without another drink sounds impossible, but going 24 hours sounds doable.

Small targets lead to small victories, and small victories can trigger a positive spiral of behavior.

Human brain has no trouble achieving baby steps, and as it does, something else happens. 
With each step, you feel less scared and less reluctant, because things are working. 
With each step, your brain starts feeling the change. 
A journey that probably started with anxiety and skepticism evolves slowly, toward a feeling of confidence and pride. 

And at the same time the change is happening, you as a person grow.

Tuesday, 9 June 2015

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.


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? 

Sunday, 22 March 2015

Installing Scrum effectively: Upgrade your company´s Operating System!

Magic Wand by photophilde/CC BY 2.0
Scrum is simple but not easy!
I'm sure that those of you who had seriously tried Scrum can recognize what this sentence really means.
And being simple is definitely one of the strenghts of Scrum, but also one of its pitfalls: it is so straightforward to understand by managers than most fall into the trap of believing it can become a magic wand for the company problems.
Sometimes without even reflecting about what the company's problems really are!

Ken Schwaber, co-inventor of Scrum said once: “Agile development will not solve any of your problems – it will just make them so painfully visible that ignoring them is harder”.

Missing operating system_ {error message} by Karl-Ludwig Pogemann/CC BY 2.0
And that's where the tough part starts!
Scrum is not plug and play! It's not a simple upgrade of the SW methodology currently in use in the company! It changes some of the basic assumptions and thoughts about products get developed!
It's like installing an iOS 8 app on an IOS 4: it won't work! 

You need to upgrade the Operating System!

I would like to share with you what I learned to be three fundamental upgrades needed in the company´s Operating System to install Scrum effectively.

1. Cross functional teams self-organized around value delivered to customers

It is extremely important that development teams are organized so that they can deliver value to customer as fast as possible and not around technology or internal product structure.

You do not want to have unproductive teams overwhlemed by thousands of dependencies, right?
You do not want to create unnecessary coordination work and increase your overhead, do you?

So move away from micro-managed functional teams organized around your system architecture: you will heal your company!
Effective teams are cross-functional and have all the competences needed to transform a backlog item in a potentially shippable product increment within one Sprint.
They work together to remove waiting times and handovers, which represent waste of time and knowledge. 
This does not mean at all having a team of generalists. It means instead having a team of specialists with T-shaped competence, so that they can contribute in doing the work when necessary, even in knowledge areas different from the one they are specialized in. 
Cross-functional teams learn continuously from each other's skills and share knowledge inside the team and between different teams.
These teams must be self-organized: they are the ones who have the best knowledge and must be empowered to decide how to do the work and continuously adjust their process.
A cross-functional and self-organized team can have the possibility to look at the whole development process, find the weakest link or the bottleneck at hand and do whatever they see as necessary to fix it. They have enough visibility of the whole to avoid sub-optimizations typically happening in traditional environments.

2. Agile Leadership

In an environment where teams are empowered and self-organized, leaders stop taking project decisions or asking for review and status report.
They focus instead on removing impediments, aligning stakeholders, building a trust environment, coaching, providing feedback, developing people’s skills and building the capabilities of the organization: they basically create the conditions for the teams to perform at their best.
They cultivate skills of servant leadership, are empathetic and willing to help.
This is applicable with different flavors to managers, Scrum masters and Product Owners.
  • Scrum is enabled by managers who build a culture of discipline and excellence, guide on principles and values instead of giving complex rules to follow, teach people not to cut corners, challenge people to high performance and lead by example. They empower people to choose how they want to work and give room for experiment and safe/fast failure. Good Agile managers stay close to the teams and Manage By Walking Around and Listening.
  • Scrum is enabled by full time Scrum Masters who have a very good knowledge of Lean, Agile and Scrum and can coach the team to apply Agile values and principles. They teach and coach them to challenge the status quo and continuously improve, think and work as a team, collaborate and challenge each other to grow.
  • Scrum is enabled by Product Owners who clarify the Why? and the What?, but not the How? Therefore they trust the team will work at their best. At the same time they challenge and support them to continuously improve. Good Product Owners paint the big picture for the team to take responsibility of the product as a whole and actively support the team to find ways to connect with the customer. They take the responsibility to act as a unique interface to the organization for any work request towards the development team and protect them from interferences.
It is a lot about being more than doing. See also 3 necessary management mindshifts in a fast changing world.

3. Well groomed backlog

People might be arguing about what a good Product Backlog is, but here is what definitely a good Product Backlog is not (but far too often seen around): a generic list of work items which are not user centric, not split end-to-end, not estimated, not even always prioritized.
A high quality Product Backlog is an enabler for iterative and incremental delivery of high quality potentially shippable product increments, which is the core of Scrum (Garbage In-Garbage Out theory applies in this case). It helps the team focus on the right things and build them faster.
A high quality Product Backlog is a manageable size, living artifact of Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST) User Stories.
Such stories are easier to understand for the team, easier to plan and easier to work, so that the team can be more productive.
INVEST stories allow:

  • Minimize the risk that the team does not deliver anything at the end of a Sprint. 
  • Faster learning and faster development because the team gets feedback and finds problems earlier. 
  • Better prioritization and defer decision due to a shorter feedback loop. 
  • Deliver value more often and therefore can make customers happier. 
  • Teams to be more focused and more motivated, because they feel a sense of velocity and accomplishment.

Where do you think you should start first in your OS upgrade?