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

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?

Thursday, 11 December 2014

The top 2 skills for being an effective Agile coach (or an effective leader)

Being an Agile coach is fun and extremely rewarding, but it is a tough job. 
Like a sports coach, you're supposed to help your team and your players perform at the best they can, without playing yourself. You have to influence with no formal authority, so you'd better have a very well equipped toolbox (skills, knowledge, techniques, and experience) if you desire to be effective.
I'm not here today to create a generic list of what those tools might look like. I just want to share the two coaching skills which helped me most in my 5-years experience as an Agile coach: 
  1. Empathy 
  2. Situational awareness
rosita by schaaflicht/CC BY 2.0

1. Empathy 

Empathy is a very important skill for coaches as well as for leaders, even though I think not many people realize this. 
No coach can be effective without getting trust from clients; likewise no leader can be effective without trust from people she is supposed to achieve success with. 
I learned that one of the most effective ways to build trust is to demonstrate that you truly care about people and you are committed to their growth. 
I learned that people want to feel they are valued. People appreciate when someone is really listening to them, puts herself in their shoes, is not judgmental and really tries to understand their viewpoint. 
Then of course you have to show that you can really help them and bring some value, but being “there for them”. when talking to peopl.e is a necessary step. Otherwise they perceive you just as a sort of knowledgeable professor. 
One of the most rewarding feedback I have ever received was from a Product Owner I was coaching: “It’s really impressive - he said once -  you look like you’re truly listening when we talk, not just hearing what I’m saying!”. 
Of course it is not always easy and it doesn’t come easy for me either. 
It is a skill to practice (and deliberately practice) to reach what David Rock calls listening for potential: it means listening to people not as for what they are now, but by thinking at what they can become in the future and be committed to help them become the best they can be.

Mount Everest by NASA/CC BY 2.0

2.  Situational awareness

With situational awareness I mean the ability to be really present, observe carefully and understand what is going on around you: basically the ability of “reading the room” or “smelling the room” beyond words. 

This skill always resulted to be very useful for me in many situations, especially when I meet a team for the first time or when I deliver training. 

You can understand for instance, who is with whom or against whom; who is more senior, or who the leader is; who embraces new ideas or who is skeptical. Of course I do not use it as my only source of information, but I learned to trust this sense, which I consider a mix of “gut feeling” and experience in observing human behaviors. 

I apply this skill continuously: for instance I use it to diagnose how a team is collaborating. I observe them during the day, at Daily Scrum and in other ceremonies and I try to understand what is “really” going on to understand what to do or not to do.

What are the skills which are most effective and helpful for you?

Wednesday, 24 September 2014

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.

Monday, 8 September 2014

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:

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?