State of Scrum 2017-2018: the future is Agile!

At the beginning of new year, Scrum Alliance, the largest certifying body in the Agile community, released State of Scrum 2017-2018, an annual report which summarizes Scrum and Agile practices and predictions around the world.

More than 2,000 Scrum professionals responded to the survey, representing 91 countries and 27 industries and the report this year shows Agile transformation firmly on the horizon for organizations all over the world.

Approximately half of respondents – 53 percent – report current involvement in an Agile transformation, and of those not currently involved in an organization-wide Agile transformation, 56 percent anticipate one in the future, which is not surprising.

Other key findings from the 2017-2018 report include:

• 97 percent will continue to use Scrum in the future. 
• 85 percent say Scrum continues to improve quality of work life.
• ScrumMaster is the most popular certification, selected by 84 percent of respondents.
• 78 percent use “Scrum and Other” approaches to Agile, and the diversity of frameworks increased from the previous year. 

Active senior management sponsorship and support is the number one motivator to undertake an Agile transformation, and enterprises look to executive leadership to spearhead Agile initiatives.

While many respondents anticipate change to come and suggest it is necessary to reach business goals including improved satisfaction with products delivered, better time to market, better quality and improved staff morale, 57 percent say organizational design and culture is what holds Agile transformation back.

This definitely resonates with my personal experience in coaching and transitioning enterprise departments: company culture can make or break an agile transition.
Yet few transitioning organizations do anything much to purposefully change their culture.
Culture is seen as fluffy and intangible, and changing it is risky. Having dozens of Scrum teams is very tangible and an easy KPI, but distributing authority to teams is a bit scary and also difficult to measure.
My experience tells me that this perspective is due to a lack of knowledge about:

1. what culture is
2. the strong impact it has on behavior
3. how you make it visible 
4. how you change it.

For instance most leaders say that their biggest problem is knowing and understanding what is happening on the factory floor. Yet very few leaders and few companies spend effort on actually observing people and their interactions.

If you want to talk and learn more about any of these four topics, I will be happy to help.

To learn more about Scrum Alliance and the State of Scrum, please visit http://info.scrumalliance.org/State-of-Scrum-2017-18.html

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 :)

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?

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?

Scrum and XP: reconciliating Agile with its roots

I really encourage you to have a look at this awesome session from Robert C. Martin, called The land that Scrum forgot. 

Besides the usual pleasure to listen to Uncle Bob, it is an impressive overview of the history of Agile, admirably told by an eyewitness and one of the main actors: you can really see in action the giants (on whose shoulders we're all standing) and feel them like closer friends, more than myths.
Among the different enlightning reflections, Bob Martin draws a clear and interesting perpective of the last decade (and more) about why Agile is somehow  not completely fulfilling the original expectations: Agile was originated by developers (all Agile signatories were basically developers), then it got conquered by project managers and lost part of its original intent.
Scrum unintentionally contributed to this, being seemingly so simple to be understood from managers, but so generic about how to build a potentially shippable product increment every sprint to be incredibly hard to adopt. Thus Scrum was actually the way people with project management background used to enter the Agile world either with good intent or opportunism.
On the other side XP was THE Agile method of developers.

I will try to analyze and compare Scrum and XP here to show how they're aiming at the same purpose and how both effective Scrum and effective XP embody the same genuine Agile principles and values.

Scrum and XP have actually a lot in common, more than one might think. 

They are both based on iterations and have some practices in common:

• the Planning Game in XP overlaps with the Sprint Planning in Scrum
• both produce a working SW increment of the most valuable functionalities at the end of each iteration
• the team is self-organized and decide how to build a certain function
• business and developers work together on daily basis
• the system metaphor in XP overlaps with the concept of User Story which is basically used in every Scrum Team I know, even though it is not explicitly requested by Scrum which basically only mention generically a backlog item as input to the Sprint
• both encourage similar values, and actually share two values: Courage and Respect

One might also claim they have some slight differences:

• Scrum prescribes Sprints which can be 1 to 4 weeks long, while the length of an iteration in XP is 1-3 weeks long
• the customer works together with developers in XP, while Scrum proposes the role of Product Owner as customer representative to suit the cases where the customer cannot physically work with the team (btw that’s one of the reasons why Scrum scales and XP doesn’t)
• strictly speaking, Scrum teams do not allow changes to their Sprint Backlog. XP teams instead can allow changes within their iterations: as long as the team hasn’t started working on a particular feature, a new feature of equivalent size can enter the iteration in exchange for the not yet started feature (however many times I teach the same approach to the Scrum teams I coach, especially when the environment allows and it does not become the norm).

However the biggest difference between Scrum and XP is that Scrum is basically focusing on how to organize the work, but it does not say anything about how to do the work, XP instead is more focusing on practices to develop high quality software effectively.

At the same time I learned (and thus agree with Dave Rooney) that Scrum is not enough to sustain an effective Agile SW development. Scrum is a great starting point if you want to learn how to be Agile, but I saw many Scrum teams, getting more mature with Scrum and not improving their performance overtime without using proper technical practices, because they accumulated a too big technical debt. Instead they have to learn to build the product in a different way.

Scrum explicitly avoids prescribing technical practices, but a Scrum team will hardly succeed without using certain XP engineering practices, like Test Driven Development, Continuous Integration, Pair Programming, Collective Ownership, Coding standards and Refactoring.

Effective Scrum and XP together can really unleash the full potential of a team, allow delivering effectively high quality products that customers love and stay true to the original spirit of the Agile manifesto.

Scrum is Lean

I believe that Scrum is the most Lean among all Agile methods. 

scrum by David / CC BY 2.0

And not only because the word "scrum" was first used in 1986 by two professors at Hitotsubashi Univeristy in Japan, Hirotaka Takehuchi and Ikujiro Nonaka, in their famous HBR-published article             "The new new product development game".

In 2003 Mary and Tom Poppendieck coined the term Lean Software Development by publishing a book with the same name and proposing a translation of Lean thinking and practices to the software development domain. Lean Sofware development is based on 7 principles, which may be implemented by means of a number of tools:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

If you want to know more, Mary and Tom published two more books:

• Implementing Lean Software Development: From Concept to Cash
• Leading Lean Software Development: Results Are not the Point

Now, even though Scrum and Lean Sofware development might seem to have formally nothing in common (different principles and different practices),  I will try to explain why and how I think the seven Lean SW Development principles are somehow mapped (or at least found) in Scrum.

1. Eliminate waste

The book reports seven wastes in SW development: partially done work, extra features, extra processes, task switching, waiting, motion, defects.

I think that the Scrum framework as such contributes to eliminate those sources of waste:

- the iteration-based approach, through the use of the Sprint Backlog, and the focus on doing whatever it takes to get things done and transform the items in the Sprint Backlog into a Potentially Shippable Product Increment, contributes the eliminate partially done work

- the Product Backlog handling, by building first the features which are more valuable for the customer and not spend too much time on the ones that are coming later, contributes to minimize partially done work and not needed features

- self-organized teams, who have the best knowledge, who are empowered to decide how to do the work and who continuously adjust their process through Sprint retrospectives, contributes to remove extra processes

- teams focusing on the Sprint goal minimize task switching

- cross-functional development teams working together side by side and daily with the Product Owner can remove waiting and handover of work items

- high skilled development teams, feeling responsibility for product quality, minimize defects

2. Amplify learning

Scrum is all about seeing SW development as a learning process. The Sprint will help create knowledge both on the product and on the process: the Sprint Review and the Sprint Retrospective are the main points in time where the knowledge on the product and the process are built respectively via feedback loops. The Daily Scrum also creates knowledge about how far the team is from the Sprint goal

Cross-functional teams learn continuously from each other skills and share knowledge inside the team and between different teams.

3. Decide as late as possible

A Product Backlog which is more fine grained on the top and more coarse on the bottom and “just enough just in time” planning via a Sprint based approach, allow a Scrum Team to reduce complexity and defer decisions which are not necessary at a certain point in time.

They can keep instead options open up to the last responsible moment: they can use time to collect more information and learn more about the product and the context in order to take better decision later, based on facts. They will of course learn fast by means of quick feedback loops provided by the Sprints.

This allows a Scrum team to be more flexible to react to the changes that will surely happen in the market and in the technology: they can truly embrace change inside their process of developing SW.

4. Deliver as fast as possible

Short delivery cycles represented by Sprints allow deliver quickly to maximize return on investment, get feedback from real customers and users and reduce risk that you won’t deliver a product that meets customers’ needs, due to misunderstanding or any changes in markets and technology.

A team focusing only on delivering the Sprint backlog will produce potentially shippable SW increments faster.

5. Empower the team

Scrum is all about empowering self-organized teams to find the best way to accomplish work. Self-organized teams can leverage all members’ talents and intelligence in the best possible way to achieve their goal as fast as possible.

Real empowerment is achieved by having the Product Owner to decide the “What” and the “Why” and explicit it by means of Product Backlog items in the form of User Stories: the development team will then decide the “How” and find the fastest possible way to get a User Story done.

6. Build integrity in

In a waterfall approach, piling up code without testing often result in a very expensive re-factoring effort, due to bugs, but especially to requirement change or misinterpretation.

Quality in a complex environment like SW development can be built only via iterative and fast feedback loops. A Sprint provides the main feedback loop mechanism in Scrum. Inside the Sprint there might be other even quicker feedback loops:

- the Product Owner (customer representative) works together with development: they are part of the same Scrum teams and work daily together: they collaborate on the Product Backlog and the real Product and this ensures a continuous feedback loop on requirements and system behavior

- Scrum teams adopting XP practices perform continuous refactoring, continuous testing, and continuous integration, which are Agile ways to build quality in.

7. See the whole

End-to-end Product Backlog items (slicing the product end-to-end vertically and explaining why) and cross-functional teams allow looking at the whole system: they can adapt the work items and the process to maximize the value delivered and achieve the Product Vision in the fastest possible way.

An empowered and self-organized team, working closely and daily with a customer representative (the Product Owner), 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 which typically, in traditional environments, try to optimize some small part of the system, which may not help the whole system.

If you want to implement a Lean thinking in your organization, try to practice effective Scrum first and you will get an extraordinary teacher. Scrum is Agile and Lean.

What do you think? 

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!