Agile/Scrum blog

Onderwerp: scrum

A P.O. Perspective on the Definition of Scrum

Sjoerd Kranendonk Door: Sjoerd Kranendonk,  24-04-2017
Onderwerp: Scrum  

In this series I aim to put a Product Owner perspective to the elements of the Scrum Guide. Where else can we start then at the definition? We’ll discover the most important elements for a Product Owner and what they mean in practice.

Scrum in a nutshell

Cleo Kampschuur Door: Cleo Kampschuur,  28-03-2017
Onderwerp: scrum  

Een organisatie gaat of is aan het Scrummen. Een hoop begrippen komen voorbij die kunnen zorgen voor verwarring. Wat houdt deze manier van werken nu precies in? In deze blog wordt de basis naar voren gebracht over het gedachtegoed Agile en het framework Scrum, geïnspireerd door de Scrum Guide.

Values matter… a lot

Matthijs de Booij Door: Matthijs de Booij,  15-12-2016
Onderwerp: Value  Scrum  

When I’m working with teams and organizations I always emphasize the importance of values that contribute to minimizing time to market and the ability to quickly respond to changing needs. In this post I will explain why I think understanding and applying these working values are critical for business success in general.

Needs of High Performing Teams

Alex van der Star Door: Alex van der Star,  20-05-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

The needs that High Performing Teams have

In my previous blogpost, I wrote about the characteristics of High Performing Teams. To come to these characteristics I did a small literature review. For this part, I will establish the needs that need to be filled in in order to enable teams to become high performing.

Remember, I am still talking about a team of knowledge workers developing and maintaining a software product.

Characteristics of High Performing Teams

Alex van der Star Door: Alex van der Star,  14-04-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

How to create high performing teams

This is the first blogpost in a mini-series of three in which I explore actions that Agile coaches or Agile managers can take to create high performing teams. I focus on high performing teams that consist of knowledge workers creating a software product.

It looks like we are in the middle of a social revolution equal to the scale of the Industrial Revolution of the 18th and 19th century. We’re seeing more and more self-organizing teams that make their own decisions within boundaries set by organisational direction, strategy and/or vision. The benefits seem clear, teams that take ownership simply perform better. But what is exactly the mechanism behind this? Is setting a certain corporate direction and giving freedom to self-organising teams enough to end up with high performing teams?

The Box of Transparency

Barry Overeem Door: Barry Overeem,  29-09-2015
Onderwerp: Scrum  values  

This blog post is about a little box. A little transparent box. The box contained only one sticky note. A sticky note with a milestone. The milestone belonged to a a large project that concerned a comprehensive organizational change with multiple Scrum teams.

This milestone was special, because it was a milestone the team failed to achieve.

Today we had the first review with all the different teams that are involved with the organizational change. The review had the structure of a "marketplace". No PowerPoint slides. Every team prepared a flip-over & market stall with the most important deliverables, ups & downs off the previous period and deliverables for the upcoming sprints. With short demo's of 12 minutes every team presented & discussed their progress with the other teams and stakeholders.

On itself the review was already great, this little box of one of the teams however made it awesome!

Daily Scrum - Tips & Tactics

Barry Overeem Door: Barry Overeem,  28-09-2015
Onderwerp: Scrum  

Although the Daily Scrum seems to be a simple and straightforward event, I still encounter a lot of teams struggling with it. In this blog post I'll share my tips & tactics. You can use it as a checklist for you own Daily Scrum, and hopefully it helps you ensure the event to become (or stay) effective, fun and inspiring.

Purpose and Outcome

The purpose of the Daily Scrum is to inspect and synchronize the team's progress towards the Sprint Goal, discuss if anything impedes the team and re-plan the team's work to achieve the Sprint Goal.

The outcome of the Daily Scrum should be:

  • An updated Sprint Backlog
  • An updated Sprint plan to achieve the Sprint Goal.

Afterwards every team member should have a clear plan for the day ahead. Possible impediments that limit them from achieving the Sprint Goal should have been identified. After the Daily Scrum the team can spent some time to discuss the impediments in more detail and find a solution.

The members of the Development Team are the primary participants of the Daily Scrum. The Scrum Master (as a facilitator) and the Product Owner (providing clarity about Product Backlog Items) can join, but their attendance isn't mandatory.

Is Your Scrum Team a Set of Pawns or Players?

Barry Overeem Door: Barry Overeem,  23-09-2015
Onderwerp: Scrum  Values  Leadership  

Update 23-9: my colleague Wiger Middelkamp gave me some feedback, this resulted in adding the third lesson learned. 

Previous week I used the Spotify Squad Health Check model to assess a teams situation and condition. One of the cards the game contained caused quite a lot of discussing during the retrospective and also gave me some thoughts afterwards, namely:

Pawns or Players

Is Your Team a Set of Players?
We are in control of our own destiny! We decide what to build and how to build it.

Or is Your Team a Set of Pawns?
We are just pawns in a game of chess with no influence over what we build or how we build it.

Most of the teams I work with want to be a 'player', but how do you become such a team? In this blog post I've shared the three most important lessons I've learned. The team I have in mind is a Scrum team. This includes the Scrum Master, Product Owner and the Development Team.

A Common Pitfall With User Stories

Barry Overeem Door: Barry Overeem,  16-09-2015
Onderwerp: Scrum  User Stories  

The concept of user stories is a well-known tool for describing requirements. In a simple format it captures the ‘who’, ‘what’ and ‘why’ of a requirement. User stories have their roots in Extreme Programming (XP) and is an often used tactic within Scrum. In 2001, Ron Jeffries proposed the Three C’s formula as a guide to capture the essence of user stories: Card, Conversation, and Confirmation.

  • card is a physical token giving tangible and durable form to what would otherwise only be an abstraction;
  • conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation;
  • The confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally[1].

The concept of user stories can be very powerful when the Three C’s formula is respected. Especially within a complex environment it’s crucial to understand the idea behind user stories and use it properly. The problem however is, that quite often this isn’t the case.

Een Retrospective is net een goed diner

Henk Jan Huizer Door: Henk Jan Huizer,  09-09-2015
Onderwerp: retrospective  agile  scrum  

Veel teams zien de Sprint Retrospective als een saaie en zinloze meeting. Het hoort erbij, maar levert weinig nieuws op. En dat kost de deelnemers veel energie. Erg jammer natuurlijk want voor startende teams is de retrospective vaak een van de meest vernieuwende en waardevolle onderdelen van Scrum. In deze blog een aantal tips voor de scrum master om, net als bij het dagelijkse diner, toch elke keer wat nieuws op tafel te zetten.  


Voorbereiding is alles

Als je helemaal aan einde van de dag de koelkast induikt om zo snel mogelijk iets op tafel te zetten, is de kans niet groot dat je diner wat bijzonders gaat worden. Dit geld ook voor de Retrospective, als je als scrum master 5 minuten vooraf begint aan de voorbereiding ben je te laat. Wat je vooraf zoal moet doen als voorbereiding? Dat vind je in de volgende tips!

The Scrum Master as a Manager

Barry Overeem Door: Barry Overeem,  23-07-2015
Onderwerp: Scrum  Scrum Master  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a manager. I'll describe the different between management and the manager, horizontal and vertical management, and the responsibilities of the Scrum Master as a manager.

Characteristics of a Great Scrum Master

Barry Overeem Door: Barry Overeem,  19-06-2015
Onderwerp: Scrum  Scrum Master  

This week I wrote two articles about the characteristics of a great Product Owner and a great Development Team. This is the third article and it's about the Scrum Master. Similar to the previous two articles, I'll describe the characteristics, skills and conditions. I haven't ordered them on priority; it only follows the inconceivable logic of my mind...

Characteristics of a Great Development Team

Barry Overeem Door: Barry Overeem,  19-06-2015
Onderwerp: scrum  development  

This week I wrote an article about the characteristics of a great Product Owner. It gave me the idea to do the same for the Development Team and Scrum Master. This blog post focuses on the Development Team; I'll describe the characteristics, skills and conditions.

Characteristics of a Great Product Owner

Barry Overeem Door: Barry Overeem,  19-06-2015
Onderwerp: Scrum  Product Owner  

During a recent Product Owner training I gave the participants the assignment to complete the sentence "A great Product Owner..." The result was a nice overview of characteristics, skills and conditions necessary to fulfill this role in a great manner. In this blog post I'll share the result, completed with a short explanation and some more ideas of my own.

The Scrum Master as a Mentor

Barry Overeem Door: Barry Overeem,  31-05-2015
Onderwerp: Scrum  Scrummaster  Coaching  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a mentor. I'll describe the definition of a mentor, coaching versus mentoring and the Shu-Ha-Ri way of thinking.

The Scrum Master as a Teacher

Barry Overeem Door: Barry Overeem,  14-05-2015
Onderwerp: Scrum  agile  scrum master  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a teacher. I'll describe the definition of a teacher, the theoretical viewpoint and some practical examples of the Scrum Master as a teacher.

The Scrum Master as a Facilitator

Barry Overeem Door: Barry Overeem,  29-04-2015
Onderwerp: Scrum  Scrum Master  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a facilitator. The Scrum Master serves as a facilitator for both the Product Owner and the Development Team. In this blog post I'll describe the definition of a facilitator, the misunderstanding and the characteristics of a great facilitator.

The Scrum Master as a Coach

Barry Overeem Door: Barry Overeem,  29-04-2015
Onderwerp: Scrum  Scrum Master  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a coach. The Scrum Master is often considered a coach for the team, helping the team do the best work they can to reach the sprint goal.

Prototyping & Productizing

Door: Martijn Dehing & Stephan van Rooden,  21-04-2015
Onderwerp: Scrum  

In the old days we had a factory floor where assembly line workers assemble the parts into a product which before has been designed by clever researchers wearing white lab coats. There is a thin line between experimentation and actually producing something.

We frequently run into situations within organisations where the development department is adopting Scrum, enabling teams to conduct small experiments and test assumptions. However, elsewhere in the organization, separate teams have been doing this for years usually in an research and development departments. What we see is two worlds colliding and putting pressure on the entire organisation.  

The Scrum Master as a Servant Leader

Barry Overeem Door: Barry Overeem,  06-04-2015
Onderwerp: Scrum  Servant-Leadership  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a servant-leader. Servant-leadership is fully in line with the Scrum values of courage, openness, respect, focus and commitment.  It's the backbone of the Scrum Master role and therefore the most obvious one to describe as first.

Watch left, watch right, and watch that bus!

Martijn Dehing Door: Martijn Dehing,  30-03-2015
Onderwerp: scrum  team  knowledge  sharing  single source  bus factor  

At the last Sprint Review meeting the Scrum team presented their latest product. Some features were not ready so the Development Team, together with the Product Owner, decided not to show these to the stakeholders. “What is the reason that new report we were so desperately longing for is not in?” Patricia from sales asked. “Well, the feature was not finished so we decided to leave it out” replied Neil, one of the developers. “Ok, it was the most important feature of the sprint! Was there any specific reason why it is not finished?” “Simon had some family-related issues so he was not in half of the sprint, and because he has the knowledge we were unable to finish it on time. But hey, we delivered something else instead!” Neil replied.

In traditional organizations people are pushed more to become specialists and to have focus, alone and heroically, on one tough topic. Everyone wants to feel special, and these local hero’s certainly get a lot of attention, questions and are asked for that meeting where those important decisions are made! Is this what it feels to be Superman? Is this what the organization needs?

Five Fundamental Questions to Assess your Agile Process

Barry Overeem Door: Barry Overeem,  25-03-2015
Onderwerp: Scrum  Agile  

Recently I read Mike Sutton's article in which he describes the misuse of the Scrum framework. He addresses a few relevant topics and practices that I've unfortunately also witnessed applied wrong quite often. Examples are Scrum being used as a methodology instead as a framework and all the elements of Scrum are practiced mechanically without really questioning its true purpose.

However, my intention with this post wasn't starting an in-depth discussing about the misuse of Scrum. It's the questions Mike presents to assess the quality of an organization's way of working that triggered me.

How to Build a Scrum Team with Contractors?

Barry Overeem Door: Barry Overeem,  23-03-2015
Onderwerp: Scrum  Agile  

Within companies that use Scrum properly the organization is built around fixed, cross-functional, self-organizing teams who are given the freedom and responsibility to think of a strategy they believe will result in the best product. Everyone around the development team is focused on supporting and facilitating the teams in building the desired product. In consultation with the Product Owner, the development team themself decides what to work on and how much they can handle during a sprint. This results in a clear focus and the opportunity to obtain a sustainable pace of continuous delivery.

So far so good.

The fact is that a large part of nowadays organizations consists of contractors. They have got a core of employees, and around it a flexible layer of contractors they can easily up- or downscale. In this turbulent age with rapid changing business- and market conditions, organizations are almost obliged to have this flexibility. Next to this, an increasing amount of people with specific knowledge and skills also choose to be independent. They are not willing to work for companies for years in a row but want the freedom to switch assignments and engage in new challenges and environments continuously.

As mentioned before, Scrum is based on fixed, cross-functional, self-organizing teams. The best teams have a stable composition for a longer period and hereby have the opportunity to really become a strong team instead of a group of individuals. They've experienced ups & downs together and thoroughly know each other’s qualities and personality. But how do you build such a strong team, when a large part of the team consists of contractors? Is it actually possible to build a true team when contractors are part of it?

The Team Consultant

Barry Overeem Door: Barry Overeem,  01-03-2015
Onderwerp: Scrum  Agile  

Currently I'm reading 'The Scrum Field Guide' written by Mitch Lacey. So far it's an excellent book that offers me some interesting, practical insights. One of them is the concept of the team consultant. This idea suits a matter I've encountered quite often. In this blog post I'll share some of the thoughts of Mitch Lacey on this topic and complement it with my own personal view and experiences.

The best team sizes are between five and nine people, all of whom are fully dedicated to a project for the duration of the project, and who work together in a cross-functional way to deliver working software at the end of every sprint.

Many organizations struggle to create teams that live up to these conditions, for example:

  • Some specialized knowledge might be thus scarcely available and highly wanted, that the people having this knowledge can't be allocated to just one team;
  • Some people have such highly specialized skills that a Scrum team can't offer them enough relevant and suitable tasks;
  • Some people don't have the personality to be the ideal Scrum team member. Ilan Goldstein wrote an excellent article in which he makes the distinction between 'rock stars' and 'studio musicians'.

So how can you compose a team that is dedicated to building the desired product, respects the fundamentals of teamwork but also takes the given realities as described above into account?

A Projects Nightmare

Barry Overeem Door: Barry Overeem,  16-02-2015
Onderwerp: Scrum  Agile  

When developing a product, the given constraints and boundaries aren't always easy to handle. But as long as they are realistic and used wisely it shouldn't interfere in building a great product. The most common constraints are set on scope, budget, schedule or quality.

In traditional plan driven projects, the features are described and estimated up front. The time and cost necessary to deliver these features should be clear at the beginning of the project. After the requirement analyses phase the scope, schedule and budget get frozen and the phases of design, implementation and testing start. Everything with the big-bang deadline in mind at which everything must come together magically.

Scrum projects are value driven. Given the complexity and unpredictability of software development an up front fixed scope isn't possible. Therefore the budget and schedule are often fixed, but the scope isn't. Because Scrum always focuses on the features with the highest value, the features that aren't done at the end date are the ones with the lowest priority.

Another variety is one that can occur in both traditional and Scrum projects but for sure is a recipe for disaster. And I know, it may sound like a Product Owners dream, but in my experience it's a nightmare for a project:

A customer with an apparently unlimited budget.

The Reading List for Agile Newbies

Barry Overeem Door: Barry Overeem,  05-02-2015
Onderwerp: Agile  Scrum  

Recently I got asked a few times to give some advice on the best books to study when you're a novice in Agile & Scrum. This resulted in me checking my Kindle library and giving some custom made advice. Of course this is a small effort, but it gave me the idea to bundle it in a blog post, which makes it easier to send around whenever anyone asks me. The result is some kind of personal Agile reading list for newbies; I hope it's useful for anyone entering the awesome world of Agile software development.

My original plan was to focus on Scrum, but when you're a novice in the world of Agile software development, I find it more useful to study multiple practices & tools and select the one that suits you best. Therefore I've added some books and articles of the most common Agile practices. This list is based purely on my personal preference. Probably a lot of obvious books for a novice might be missing, if so, feel free to suggest them.

Magic Estimation

Barry Overeem Door: Barry Overeem,  02-02-2015
Onderwerp: Scrum  Agile  

Being an Agile Coach & Trainer for Prowareness, I use different types of games, tools and practices every week during meetings, workshops and trainings. Some of these I've invented myself, but most already existed and have only been changed slightly to a format that suits me best. The upcoming period I want to share some of these games, tools and practices. I will share the what-why-how-when and what worked well and what didn't. By sharing my experiences I hope to inspire you to give these tools and practices a try for yourself, improve it and hopefully share the perfected version in return.

What is 'Magic Estimation' about?
It's an exercise for the Scrum team to estimate an entire product backlog with story points in a reasonable short amount of time. It's a useful format to get some insights of the size of a backlog. Is it one month, 3 months or 6 months of work we're talking about?

Scrum: A Five-Headed Meeting Monster?

Barry Overeem Door: Barry Overeem,  25-01-2015
Onderwerp: Scrum  Culture  

When Scrum is introduced in a company, most of the time, the development team embraces it with lots of enthusiasm. Scrum embodies self-organizing, autonomous, multidisciplinary teams that acknowledges individual qualities and reinforces the strengths of the team as a whole. Who doesn't want to be part of a Scrum team?

Quite often however, after the Scrum honeymoon period, I start to hear comments like:

  • "Since the introduction of Scrum, all I do is attend meetings. I didn't become a developer to attend meetings all day long."
  • "With Scrum I hoped we would get a team culture, but instead it feels more like a meeting culture."
  • "I thought Scrum meetings we're time boxed, but for example our daily Scrum takes at least 30 minutes and afterwards we still don't have a solid plan as a team."

Making optimal use of JIRA Agile

Bas van Lieshout Door: Bas van Lieshout,  21-01-2015
Onderwerp: Scrum  Backlog Management  Tooling  

Many organizations choose to use an online tool to support their Agile development. The advantages are clear: it can be accessed from everywhere, and it can link many pieces of relevant information, from the origin of an idea to the committed code and the tests. Monitors on the wall can easily make the status of the sprint transparent, displaying burndown charts or the sprint board.

I do agree with the Agile value to favor "individuals and interactions" over "processes and tools". But a good configuration of your tools can be very beneficial to your effectiveness. 

Team Culture over Project Culture?

Barry Overeem Door: Barry Overeem,  19-01-2015
Onderwerp: Scrum  Culture  Team  

Recently I read the book 'The People's Scrum' by Tobias Mayer. In this book he spends a chapter on describing the differences between project culture and team culture. To me, the given examples of both types of culture are highly recognizable and I can easily extend and complement the list of examples with my own experiences. And this is basically what this blog post is all about, my view on the project- and team culture.

Commitment versus Forecast

Barry Overeem Door: Barry Overeem,  09-01-2015
Onderwerp: Scrum  

In my previous blog post 'The Smell of the Place' I described the difference between the terms commitment and forecast. This resulted in an intriguing discussion that triggered me to elaborate some more on this topic and share the highlights of this conversation.

Lessons Learned as an Agile Coach

Barry Overeem Door: Barry Overeem,  05-12-2014
Onderwerp: agile  Scrum  

After working a couple of years as a Scrum Master for the web agency Enrise I made the switch to Prowareness at the beginning of 2014. At Prowareness, a company that helps organizations meet their challenges in the field of software development, I fulfill the role of Agile Coach / Trainer. In this role I help individuals create great teams by applying host leadership, and learn organizations to adapt and respond to a constantly evolving world.

This is quite a challenge. Not only because working in the field of software development means working with complex products in complex environments. But mostly because creating a truly lasting change is difficult. Not only implement some best practices, but really build awesome teams and create responsive organizations. 

The toolkit of an Agile Coach should therefore contain more than a few skills, competences and best practices. Gathering them will require training, hands-on experience and most important: the willingness to constantly improve yourself. For me personally it helps to continuously reflect my daily practices and translate it to a list of 'lessons learned'. This list grows on weekly basis, with this blog I want to share the most important ones I've learned since I started working for Prowareness. And for sure, there might be some very obvious lessons, but often these are the ones you're not always aware of. Note: not all of these lessons are related to the role of an Agile Coach. But fulfilling this role, they've proven to be valuable for me.

10 Best Practices for Managing the Product Backlog

Barry Overeem Door: Barry Overeem,  20-11-2014
Onderwerp: Scrum  

Recently I facilitated a workshop between multiple Scrum teams in which we discussed the area of backlog management. The main purpose was to gather some best practices for managing the product backlog. With this blog post I will share the outcome of the session, hopefully they are useful to you, otherwise I gladly receive other best practices you might know.

Is Scrum an Asperger’s Friend or Foe?

Barry Overeem Door: Barry Overeem,  22-10-2014
Onderwerp: scrum  

The subject of this blog post might seem unusual. But having worked with multiple development teams, I've gained some experience with team members having (symptoms) of Asperger's. I mostly contributed to the team as a Scrum Master or Agile Coach. The combination of Scrum and Asperger's hereby always had my interest. With this blog post I want to share some of my thoughts. But beware: I'm certainly no expert in Asperger's and haven't got any in-depth knowledge about it. See this blog post as an invitation for conversation where my findings can be used as a starting point.

The Daily Goal

Barry Overeem Door: Barry Overeem,  14-07-2014
Onderwerp: Agile Teams  Craftsmanship  High Performing Teams  Scrum  Scrum Teams  

The daily scrum is the most used scrum meeting. This sounds obvious because it occurs every day. But it's also the first practice organisations and teams apply when starting with scrum. 

Although the daily scrum is a very straightforward meeting with a clear structure and can be practiced daily, many teams fail to extract the potential value it offers. It is used merely as a status update meeting, performed mechanically and resulting in incoherent and ambiguous individual plans. 

This is a shame, because a well-performed daily scrum should be energizing, inspiring and result in a shared refined daily plan that is created and supported by the entire team.

If your daily scrum has become unfocused, practiced mechanically and is an energy-drainer; using the best practice of a daily goal is a great solution!

Groups & Scrum: Productive teams

Stephan van Rooden Door: Stephan van Rooden,  03-06-2014
Onderwerp: Agile Teams  Groups  High Performing Teams  Scrum  

In the previous blog, I talked about the importance of setting goals and what to focus on when trying to reach goals. How is setting goals related to productivity? When you stroll across the web on the topic of Scrum you will most likely run into the term ‘Hyper Productive Scrum Teams’. This sounds really nice and would most likely appeal to most people who consider adopting the Scrum framework. However, a hyper productive team can deliver no value at all ….but at hyper speed. And that’s where goals come into play.

Start with Done

Jeroen van Menen Door: Jeroen van Menen,  27-05-2014
Onderwerp: Sprint board  scrum  agile  Scrum Master  sprint  Value   

I am a big fan of the “Start at the End” way of thinking. When I apply this way of thinking to a situation or problem, it most of the times gives me a completely different perspective on things. And with that comes a completely new way of thinking about what is needed to reach the envisioned end result.

This “Start at the End” way of looking at things is applied in many areas, for instance in Solution Focused coaching. Good examples are the “Miracle Question” and “Future Backwards” session. In the Netherlands Berthold Gunster is promoting this way of thinking. He even came up with a word for it “omdenken” which maybe translates into “turn your thoughts around”.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.

Setting the stage

When I was preparing for my training course in getting the most value out of your retrospectives, I stumbled across something very interesting that opened my eyes. When talking about Sprint Retrospectives there is one book you cannot ignore. Agile Retrospectives? Making Good Teams Great by Esther Derby and Diana Larsen [Link].

Their book resolves around a model for running effective retrospectives. This model, or framework for retrospectives consists of five stage

  1. Set the stage
  2. Gather Data
  3. Generate Insights
  4. Decide what to do
  5. Close the retrospective

A very powerful framework from my perspectives that have helped me run plenty of very effective retrospectives. But I always missed the rationale behind these stages. Only after I started reading some old study books on social psychology, it struck me that this framework makes perfect sense. Here’s why…

Group decision making

There is no better feeling than being part of a group that is able (or at least feel they are) to solve every problem that is thrown at them. Our society now is so complex that one individual can no longer possess all the knowledge, he cannot oversee the entire picture. The necessity to organize ourselves in groups has never been higher. Scrum tries to achieve that as well. Assemble a group a individuals who together are able to win the game. To solve any problem thrown at them by the product owner. This also means that we as a group have to make decisions together as well...and that is not that easy!

Benefits of decision making in groups

Despite it’s not easy there are some major benefits for teams to make their own decision. First, the information and knowledge present in a group is more complete than in smaller groups. Two heads are better than one! However, this is should automatically the case (more on this in my next blog on knowledge sharing!)

Second, when a group comes to a decision they tend to accept the solution more often than when an individual makes a decision for the group. The last thing is hard especially nowadays where the hierarchical structure in organizations are under pressure because those lower in the hierarchy are no longer uneducated individuals but high skilled and knowledgeable. So they are less willing to blindly follow their leader (into the abyss).

This is why the book of John Kotter; ‘Our iceberg is melting’ [Link]  so popular. You have to go through great lengths to convince a group to take over your point of view. Wouldn’t it be easier to let the group themselves decide? Just give them some boundaries and they will solve the puzzle.

Third, and last, benefit of group decision making is that it increases the sense of legitimacy of the group. Making a decision as a groups gives them the confirmation that they are in fact a group! However, where there are benefits there are definitely some disadvantages to group decision making.

Groupthink and Groupshift

One of the most straight forward and most visible downside to group decision making is that is takes a lot more time. We all have been in those endless meetings where discussions go on and on for…well it feels like hours sometimes. In a Scrum Team, the Scrum Master plays a big role in facilitating the Scrum Events in such a way that they are as efficient and effective as possible.

Also when making a decision as a group, questions may arise who is responsible for the outcome of this decision. Should one person be accountable or is the entire group accountable. This is a thin line. You see this happening is sports very clearly. If a team is winning, the team is celebrated for this but when results get bad we try to shift the blame to an individual (usually the coach). In organizations you see that when a manager is held accountable he is almost obligated to take the decisions as well. This has become part of our DNA so much that we are having trouble letting this go. And when you start adopting Scrum you immediately get in trouble. I believe that if a group makes a decision, they should be accountable as a group as well. Delivering in small increments limits the impact of decisions made by a group and therefore makes this discussion less relevant.

The biggest disadvantage of group decision making is that it nourishes conformism. So people in a group tend to match their attitudes, beliefs and behavior to group norms. Two interesting sociological phenomena arise here; groupthink and groupshift

Groupthink is the phenomena where groups pressure leads to conformism so any critical, unpopular or minority interest will not be taken into consideration by a group in their decision making process. So what recently happened in a Development Team was that during a sprint planning meeting an ops-engineer made a very good point related to the monitoring of the item under discussion. However, since the rest of the team didn’t had any feeling regarding that topic the comment from the engineer was put aside and never came up again. Groupthink, a minority interest wasn’t taken into consideration by the team.

Groupshift is where members of the group exaggerated their initial toward a more extreme position. So risk averse individuals will propose an even more risk averse approach and the opposite happens with risk seeking individuals. In group decision making this will lead to decisions being made that are more extreme. So when in a group, individuals are far more willing to make riskier decisions. Shared risk makes the individual risks less.

Why we do retrospectives?

So how to deal with these two phenomena? There are two ways to improve the group decision making process and to limit the impact of groupthink and groupshift.

First is brainstorming. This has been a very popular approach in the 90’s and 00’s but the effectives of this approach is in question nowadays.

The other approach is a nominal group technique where you facilitate group decision making by doing a couple of things:

  1. Get everybody involved together
  2. Let people think for themselves first about the problem at hand
  3. Share the thoughts
  4. Discuss on how to solve the problem
  5. Order the ideas and decide

You probably connected the dots already but this technique is a nearly 100 percent fit with the approach from Derby and Larsen. So we do retrospectives to facilitate group decision making and in order to amplify the benefits of this approach structuring your retrospective as described above helps! If you look around on the web you can find plenty of ways to run your retrospectives this way. A nice example of this is the Retr-O-Mat, a retrospective generator.

Next post will address another very important aspect of Scrum related to groups. Having a cross functional, multi-disciplinary team to accelerate delivery and knowledge sharing. But sharing knowledge is extremely difficult especially in the very complex world of software development.

 

 

Groups & Scrum: A group of people does not make it a team!

Stephan van Rooden Door: Stephan van Rooden,  01-03-2014
Onderwerp: Scrum  Retrospectives  Scrum Teams  Groups  

This is the first post in a series of blogs on groups and Scrum. This first blog will look into what a group is and into what makes a group into a team. In future posts I will explain more on why we do retrospectives, knowledge sharing in a group and much more. Let’s start with the definition of what a group is.

Done, usable and potentially releasable product increment?

Melvin Nijholt Door: Melvin Nijholt,  29-11-2013
Onderwerp: improvement  Scrum  Retrospectives  

The scrum guide states that development teams should create a "Done", usable and potentially releasable product increment every sprint. But what does dit actually mean? To clear this up we have to look what "Done", usable and potentially releasable actually means in this context.

Waarom schatten in punten en niet in uren?

Rini van Solingen Door: Rini van Solingen,  19-11-2013
Onderwerp: agile  Scrum  estimation  

Scrum geeft er de voorkeur aan om niet te schatten in uren, maar te schatten in punten. Waarom zou je zeggen? Uiteindelijk komt het toch op hetzelfde neer? Je wilt toch weten wat het kost en wanneer het klaar is? Dan moet je toch weten hoeveel tijd het kost? Uren dus. Of niet?

Het zit toch net iets anders. Wij mensen zijn heel slecht in het schatten in uren. Tijd is een absolute eenheid en mensen zijn niet zo goed in het inschatten van absolute eenheden. Als voorbeeld, wij kunnen heel slecht inschatten hoeveel een auto weegt en hoeveel een scooter weegt in kilo’s. Of een ander voorbeeld: als wij twee torens zien, dan zien wij in een oogopslag dat de ene toren twee keer zo hoog is als de andere. Maar hoe hoog elke toren nu precies is in meters, dat kunnen wij heel slecht inschatten. In andere woorden: absoluut schatten kunnen wij slecht, maar relatief inschatten kunnen we weer wel goed.

Daarnaast is het vervelende aan uren dat ze ook nog gebruikt kunnen worden als eenheid van tijd en heel makkelijk tot misleidende berekeningen kan leiden. Het is heel simpel, 40 uur aan werk zorgt er voor dat een team van 5 personen in een dag klaar is, toch? Of niet? Verzetten wij wel 8 uur werk in een werkdag, of toch minder? Wij zijn vaak veel te optimistisch en houden geen rekening met verstoringen, afhankelijkheden, onzekerheden etc. Bovendien schatten we vanuit ons eigen perspectief en vergeten dan vaak het werk van anderen dat ook nog nodig is.

Kortom, het schatten in uren is

Wat is de Return-on-Investment van Scrum?

Rini van Solingen Door: Rini van Solingen,  12-11-2013
Onderwerp: agile  improvement  Scrum  

Hoewel Scrum uiterst populair is en veel organisaties ermee werken, is de hoeveelheid meetgegevens over wat het kost en wat het oplevert nog erg beperkt. Grote adviesbureaus als Gartner, Standish en McKinsey adviseren allemaal om niet meer planmatig via een waterval te werken, maar om jezelf op een Agile manier te organiseren. Gartner is heel expliciet: ‘The End of the Waterfall as We Know It[1]. Standish gaat zelfs zo ver dat ze durven te stellen dat: ‘Agile is the Universal remedy for software development project failure[2]. De poging van Rally[3] om de impact van Agile te kwantificeren leert dat bijna alle teams hun productiviteit verdubbelen, de kwaliteit van het werk toeneemt met 250% en het laag houden van de hoeveelheid onder handen werk (WiP) leidt tot een halvering van de doorlooptijd. In het Agile survey van Version One[4] wordt aangetoond dat 90% van de respondenten veel beter in staat is om mee te bewegen met veranderende prioriteiten en dat de inzichtelijkheid en transparantie sterk verbeterd wordt.

Ons nieuwe boek: Scrum voor Managers

Rini van Solingen Door: Rini van Solingen,  12-11-2013
Onderwerp: agile  Agility in de bedrijfsvoering  leiding geven  product companies  Scrum  zelfsturende teams  

Op 13 november 2013 is “Scrum voor Managers” officieel uitgekomen. Dit boek heb ik samen met Rob van Lanen geschreven. Het boek richt zich op de manager die zich afvraagt hoe hij in een Agile organisatie leiding geeft, stuurt, meet en optimaliseert. Het boek is opgebouwd rond de 50 meest gestelde vragen door managers over Scrum en Agile. Daarnaast gaat het in op de meest genoemde vooroordelen en misverstanden die wij in onze dagelijkse praktijk tegenkomen.

Scrum Guild - exercise on communication

Peter Koning Door: Peter Koning,  06-11-2013
Onderwerp: Guild  Scrum  High Performing Teams  improvement  

Did you already use Scrum Guilds to improve the skills of your ScrumMasters and ProductOwners? Letting them exercise for specific situations, will improve their craftsmanship and let improve their communication! But how can you do that easily and effectively? Guilds are used to improve the craftsmanship of a particular craft for centuries. To share knowledge. Within the transition to Agility you can use this to foster craftsmanship within your organization. You can use Guilds for lots of different crafts, like (automatic) testing, DevOps, coding, and Scrum of course.

Scrum Guild - exercise on communication

Peter Koning Door: Peter Koning,  06-11-2013
Onderwerp: Guild  Scrum  High Performing Teams  improvement  

Are you also using Scrum Guilds to improve the skills of your ScrumMasters and ProductOwners? Let them exercise on playing specific roles in specific situations, will improve their craftsmanship and communicate a lot more easily. But how can you do that easily and effectively? Guilds are for centuries used to improve the craftsmanship of a particular craft. To share knowledge. Within the transition to Agility you can use this term to foster craftsmanship within your organization. You can use Guilds for lots of different crafts, like (automatic) testing, DevOps, coding, and Scrum of course.

Sinterklaas en zijn Pieten, het beste Scrum team ooit

Door: Wiger Middelkamp en Michiel Vrasdonk,  18-10-2013
Onderwerp: Agile  Scrum  Product owner  

Er zijn veel verschillende manieren om uit te leggen hoe Scrum werkt. Vaak gaat dat gepaard met een mooi plaatje waar iets in staat over rollen, meetings, artifacts en states.
Maar hoe vertel je iemand nou het makkelijkst wat de waarde van Scrum is? Lees onderstaande en gebruik het om mensen de waarde van Scrum te kunnen uitleggen.

Six Thinking Hats

Marco Verhulst Door: Marco Verhulst,  03-10-2013
Onderwerp: Scrum  

During my visit last week to my colleagues, the ProElmo Team at Prowareness in Bangalore I introduced a new kind of retrospection. I already used it before at Fokker Elmo, the company where I work for and find it an interesting way of thinking.

The Six Thinking Hats is a book by Edward de Bono. The term Six Thinking Hats is used to describe the tool for group discussion and individual thinking. "Six Thinking Hats" and the associated idea parallel thinking provide a means for groups to plan thinking processes in a detailed and cohesive way, and in doing so to think together more effectively.

Retrospectivevinger

Peter Koning Door: Peter Koning,  09-09-2013
Onderwerp: scrum  retrospective  improvement  sprint  agilegames  velocity  

Gisteren met een van de #scrum teams die we begeleiden de #Retrospective Vinger gehouden. Was erg gezellig. De laatste #sprint retrospectives bespraken we vooral ‘wat ging er goed’ (tops) en ‘wat kan er beter’ (tips). Gisteren dus voor het eerst de Retrospective Vinger gehouden. Hoe werkt die?

Na een korte introductie krijgen de teamleden een paar minuten om de punten op te schrijven. Elke vinger van je hand staat ergens voor. Daarna krijgt teamlid voor teamlid de tijd om zijn vingers langs te lopen.

Waarom doe je Scrum?

Stephan van Rooden Door: Stephan van Rooden,  20-08-2013
Onderwerp: Scrum  

Scrum is hip en een laagdrempelige manier om de eerste stappen richting Agility te zetten. Scrum alleen is echter niet voldoende. De project manager aanwijzen als Scrum Master en een dagelijkse standup maakt je projectteam nog niet tot een Scrum Team en zal je hoogstwaarschijnlijk niet de kracht van Scrum laten ervaren.

Controle is beter dan vertrouwen… Toch?

Wiger Middelkamp Door: Wiger Middelkamp,  16-08-2013
Onderwerp: Agile  Scrum  Product Owner  

”Scrum is extreem makkelijk uit te leggen, maar extreem moeilijk om toe te passen.” Deze uitspraak komt van Jeff Sutherland, één van de geestelijk vaders van Scrum. Hoe zit dat dan precies? En klopt de uitspraak van Jeff wel? Deze blog gaat in op één van de aspecten die product ownership zo moeilijk maakt: loslaten.

Retrospective

Dave Woertman Door: Dave Woertman,  02-08-2013
Onderwerp: Retrospectives  Scrum  Agile  

Tijdens het coachen van teams heb ik veel contact met Scrum Masters. Binnen mijn huidige Agile transitie opdracht heb ik de verantwoordelijkheid over tientallen teams, waarbij ik me voornamelijk focus op het werk van de Scrum Master. Een collega van me begeeft zich meer op het vlak van de Product Owner.

Aangezien de boeken voorschrijven dat de Scrum Master verantwoordelijk is voor de retrospective meeting, krijg ik daarover de meeste vragen. Welke manier van retrospectives werkt het beste? Wat is het doel van de retrospective? Hoe versnel je het team?