Agile/Scrum blog

Onderwerp: Scrum Teams

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?

Childish motivation

Martijn Dehing Door: Martijn Dehing,  11-02-2015
Onderwerp: Agile Management   Agile Teams  Culture  High Performing Teams  Scrum Teams  zelfsturende teams  

Many of my friends are already or soon-to-be parents. Watching their children learn new things in a pace so fast that even Usain Bolt seems slow caught my attention. All of them are really quick in using their dad’s smartphone, the family iPad. Even the SmartTV gets wizzed through as if it has always been there. When you give them your old family photo album they expect to slide through it, just like an iPad. Even for me it is sometimes hard to follow, let alone their grandparents. The learnings that don’t come naturally, so it seems, are the things that they have to do by school, their parents or life itself.

So what are the intrinsic motivators to cater for this fast pace of learning? Could these be used as well in an adult environment, say e.g. a Scrum Team?

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!

The seven habits of highly effective Teams

Emiel van den Berg Door: Emiel van den Berg,  24-06-2014
Onderwerp: Agile Principles  Habits  Agile Teams  High Performing Teams  Scrum Teams  

I recently started working for Prowareness, during the application period I was asked to give a presentation about myself. Now, this is one of those moments to sit back and think about yourself. How do I present myself in one or two slides. What is really typical me? What do I believe in? What am I passionate about? One of the slides I made depicted my personal bookshelf because I believe that the books you read (and like!) tell a lot about you.

Groups & Scrum: How to stop a team?

Stephan van Rooden Door: Stephan van Rooden,  25-03-2014
Onderwerp: Groups  Retrospectives  Scrum Teams  Agile Coaches  

This is the fourth post in a series of blogs on groups and scrum. In the first three posts, I focused primarily on explaining the benefits of groups from a social psychological view. This post will take a more practical point of view.  So based on what I described in the previous posts it shouldn’t come as a surprise that this collection of individuals which we call a team, eventually becomes a real team! Hurray! But what if the team has to stop?

Groups & Scrum: Knowledge Sharing

Stephan van Rooden Door: Stephan van Rooden,  20-03-2014
Onderwerp: Groups  Motivatie  zelfsturende teams  Scrum Teams  

This is the third post in the blog series on groups and Scrum. In previous posts we determined what a group is [link].  and what the benefits can be. We also looked into one of the biggest disadvantages and risks of working in groups and how to overcome these [link]. This post will cover one of the main purposes of having groups: Sharing Knowledge! Knowledge sharing has been around for centuries. For example, parents transferring knowledge to their children, or workers exchanging best practices. In traditional models of education, copying the knowledge and experience of a fellow classmate was generally considered a bad thing. However, nowadays in the ‘new economy’, the re-use of a colleague’s knowledge and experience is considered necessary in order to survive.

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.

Backlog refinement

Henk Jan Huizer Door: Henk Jan Huizer,  16-09-2013
Onderwerp: Agile Coaches  Scrum Teams  

Bij de introductie van Scrum krijg ik steevast de vraag waar de ontwerpfase in Scrum terug is te vinden. Dat is een begrijpelijke vraag, omdat we aangeleerd hebben om vooraf goed na te denken, alternatieve oplossingen naast elkaar te zetten, en de keuzes vast te leggen op papier voordat we gaan programmeren. Bij de introductie van een iteratieve aanpak verdwijnt deze fasering en worden de activiteiten uit alle fasen in elke iteratie tegelijk uitgevoerd. Het ontwerp gebeurt dus incrementeel, gelijktijdig met de realisatie. Goed invulling geven aan incrementeel design is best lastig en in de praktijk zie ik teams in twee uitersten terecht komen.

Teveel voorwerk

Aan de ene kant zie ik teams vasthouden aan het paradigma dat alle ontwerpkeuzes vooraf gemaakt zijn. Pas als alle details zijn ingevuld dan mag er gebouwd gaan worden. Deze teams werken vaak met een Product Owner of analisten die vooraf gedetailleerde documentatie opstellen. Voordat de sprint begint wordt het resultaat van dit denkwerk overdragen aan de bouwers en testers. Op het moment dat dan tijdens de bouw er ondanks alle voorbereiding toch nog onverwachte keuzes gemaakt moeten worden is de reactie: volgende keer nog meer tijd stoppen in de werkvoorbereiding. De onderliggende denkfout hier is hoe kunnen we voortschrijdend inzicht voorkomen.

Scrum Guide versie 2013 – Wat is er veranderd?

Stephan van Rooden Door: Stephan van Rooden,  05-08-2013
Onderwerp: Scrum Teams  

Het klinkt best logisch dat een framework wat transparantie, inspectie en aanpassing op veranderende omstandigheden nastreeft, eens in de zoveel tijd zelf ook een grondige inspectie ondergaat. En zie daar, de nieuwste versie van de Scrum Guide! Hieronder een kort overzicht van de grootste en meest interessante aanpassingen.

Hoe begin je met Scrum - Een Agile Starterskit

Rini van Solingen Door: Rini van Solingen,  26-06-2013
Onderwerp: leiding geven  scrum teams  Scrum in Sales en Marketing  

Starten met Scrum
Inmiddels hebben we vanuit Prowareness al een kleine 100 bedrijven geholpen met het oppakken van Agile; meestal door het invoeren van Scrum. Onze aanpak begint met samen in een workshop te  bepalen wat nodig is en daarmee maken we  een specifiek plan. We noemen dat; de ‘Agile Deployment Backlog. Dit is een lijst van uit te voeren werk. Daarmee laten we dan ook meteen aan het management zien hoe je deze Agile olifant ‘hapje voor hapje’ kunt opeten. Scrum invoeren is, namelijk, een complexe verandering en het succes van de verandering hangt nauw samen met de omgeving. Een dergelijke maatoplossing maken via een Agile Deployment Backlog is op zich een prima idee. Een maatpak zit nu eenmaal het best.

Waarom is een starterskit dan nodig?

Een veel gehoorde vraag in al deze trajecten is de vraag naar een starterspakket. Dat lijkt niet heel erg Agile, want het denken in ‘one-size-fits-all’ en het denken in ‘blauwdrukken’, is niet heel erg Agile. Daartegenover staat dat vrijwel elke Manager of Directeur die we ontmoeten hulp nodig heeft bij het starten met Scrum. Ze vragen letterlijk om een plan van aanpak, een nieuw organisatieschema, een blauwdruk, of zelfs om een Gantt-chart. Ze vragen hulp en houvast voor deze transitie. En die vraag is natuurlijk volstrekt legitiem.

Management Zonder Zweepje

Paul Weghorst Door: Paul Weghorst,  25-04-2013
Onderwerp: scrum teams  

Tijdens onze Agile+ Market van 28 maart j.l. kwamen veel mensen af op het onderdeel dat ik de prikkelende titel "Management Zonder Zweepje" had meegegeven. Hoe word je erkend en herkend als succesvol Scrum Team in een omgeving die van oudsher is ingericht op Command & Control?

Zelforganisatie en telkens beter worden staan hoog in het vaandel bij teams die werken met Scrum. Zelf je planning bewaken, ruimte geven aan voortschrijdend inzicht (ook van de gebruikers!), communicatie intensiveren in plaats van je verschuilen achter geschreven ontwerpen: allemaal ingrediënten die zorgen voor het vergroten van succes van zowel gebruikersorganisaties als ontwikkelteams. Maar......binnen veel organisaties die zich hebben gestandaardiseerd op Prince2 worden uitgewerkte ontwerpen verwacht met dito planningen.

‘Volg je passie’

Stephanie Kea Door: Stephanie Kea,  29-03-2013
Onderwerp: scrum teams  

‘Volg je passie’, het motto op mijn visitekaartje. Het klink wellicht cliché, toch ben ik er van overtuigd dat men dit moet doen.
Wat heeft dat dan met Recruitment te maken? Alles! Als Recruiter ben je er namelijk verantwoordelijk voor dat de werknemers doen wat zij écht leuk vinden én dat je nieuwe teamleden met passie voor het vak aanneemt!

Recruiters horen in deze tijd regelmatig argumentaties als ‘ik zoek gewoon werk, ik wil aan de slag, er moet brood op de plank komen, etc. Aan de ene kant heel open en eerlijk, maar toch niet wat je wilt horen als iemand solliciteert voor de functie die jij hebt openstaan. Voor jouw organisatie niet, maar ook niet voor de werknemer. Het is belangrijk dat er echt een fit is tussen de functie en de werknemer. Waarom is dat zo?

Wil je bij het “JA” woord al plannen maken voor je scheiding?

Jennifer Sonke Door: Jennifer Sonke,  13-03-2013
Onderwerp: scrum teams  agile contracting  

Stel, je hebt net besloten om met elkaar te gaan samenwerken. Hoe komt het dat er dan al veel gesproken wordt over wat te doen als het mis gaat? Contractonderhandelingen gaan vaak voor een beperkt deel over de toegevoegde waarde van samenwerking. Tegelijkertijd gaat er veel aandacht op aan de risico’s en scenario’s voordat het mis gaat. Hoewel het contract de risico’s voor beide partijen moet afdekken, blijft het verbazingwekkend dat we bij het “JA” woord al plannen klaar willen hebben liggen voor de scheiding.

Measuring the Return-on-Investment of Agile transformations

Rini van Solingen Door: Rini van Solingen,  08-03-2013
Onderwerp: scrum teams  

As Prowareness helps companies in corporate Agile transformations, a fair question is: “What is the Return-on-Investment of our efforts?”. When adopting Scrum to the fullest, what will it bring? How much money does a company gain and at which cost? In this blog post, we investigate solutions for RoI measurement for Agile transitions, give an idea of how we think to approach these questions, and we ask for help to review if our ideas are useful.

While many companies invest in transforming to an Agile organization, there is still little quantitative data to come to valid Return-on-Investment calculations. David Rico reports [1] that Agile methods have a RoI that is four times as much as traditional methods, however, his data is based on modeling and combining cross-company snapshots. To the max, Rico’s data is of an indicative nature. Standish does report that they measure that Agile projects are three times more successful than traditional (waterfall) approaches, and that the chances for failing projects is three time lower for Agile projects [2]. Standish even goes so far to state that “The agile process is the universal remedy for software development project failure”. However, this does not provide a measurable RoI number. Furthermore, Standish’ figures have been part of debates on their validity [3].

7 qualities of a great product owner

Door: Anand Gothe,  27-02-2013
Onderwerp: High Performing Teams  Scrum Teams  

Being a good product owner is not easy. It is one of the single point of failures in agile enterprises. Being a prodcut owner in a distributed setting has some extra challenges. On the other side they do exist. We have put down the qualites we have valued in the product owners we are working with and have thus created a picture of a great product owner. Being a great product owner in a distributed setting means that you should be:


  1. Available and approachable: it should be easy for the team to reach the po when needed. Usually, pos have other responsibilities too within the organization. He should make sure that he has enough time available for the team.

  2. Knowledgeable about the product: a po must have a good knowledge about the product/project that the team is working on. He should be able to answer most of team’s questions instantly without having to ask someone else. He should also be able to judge what the customers want and prioritize the features accordingly. He should be a hands on person, so that he can give timely feedback to team about the things developed. At times, the po should also inspire the team with his vision about the product.

  3. Knowledgeable about the organization structure and ability to manage the internal stakeholders: the po should know his organization well. He should know who to approach for solving different kinds of impediments. This is vital for the team because, it relies on the po to guide them through the organization structure and to manage stake holders. It helps if the po also has a degree of authority, so that he can make certain decisions that can help the team/project.

Meesterschap in Scrum - Retrospectives

Rob van Lanen Door: Rob van Lanen,  27-02-2013
Onderwerp: scrum teams  

Scrum is een relatief eenvoudig raamwerk om software ontwikkeling te organiseren. De implementatie daarvan is echter geen sinecure. Organisatieverandering is intensief en in de praktijk loop je tegen allerlei uitdagingen aan. Het is dan ook niet raar dat juist bij de toepassing vragen ontstaan waarop het antwoord niet altijd eenduidig is. Daarom heeft Prowareness ‘Meesterschap in Scrum’ ontwikkeld. Tijdens iedere sessie wordt een onderwerp sterk uitgediept met een groep van maximaal 20 Scrum Professionals. Samen bespreken we veel praktijkcases en ervaringen waarbij wij van, met en door elkaar Scrum beter leren toepassen. Ook al gaat alleen soms sneller, samen bereik je uiteindelijk meer! Op 14 februari was het onderwerp ‘Retrospectives’.

A crucial step in becoming a High Performing team: Have a goal framework

Vikram Kapoor Door: Vikram Kapoor,  13-02-2013
Onderwerp: scrum teams  high performing teams  

Goals are developed to clearly communicate what you want to achieve as a team. They give everybody a clear sense of direction, which generates momentum that leads to better performance. How do you develop goals that people want to pursue?

Spend Time Together Offline

Vikram Kapoor Door: Vikram Kapoor,  08-02-2013
Onderwerp: Scrum Teams  

When you want to work as a team, you need to get to know each other beyond the work relationship. It's important to understand each other's personal qualities, passion, strenghts and weaknesses. It is then only that you get to know the human being behind the team member. This shared familiarity increases the social cohesion of the group, which contributes to peer dynamics. You have to go offline. To do that, we advise spending time with each other outside of work.

Become a Team!

vikram kapoor Door: vikram kapoor,  29-01-2013
Onderwerp: Scrum Teams  

A real team is much more than a group of people working together. Our definition of a high-performing team is a group of individuals who:

1.        Focus on the team and not the individuals
2.        Stand in for each other, thus are flexible in their roles
3.        Work together on deliverables
4.        Share leadership
5.        Work toward collective targets and rewards
6.        Are collectively and individually accountable
7.        Are accountable to each other and the organization
8.        Motivate each other
9.        Have a high cohesion  and support structure
10.        Recruit new team members

A practical combination of Scrum and Kanban

Rob van Lanen Door: Rob van Lanen,  23-01-2013
Onderwerp: Scrum Teams  

This short videolog describes how a practical combination of Scrum and Kanban was implemented at a client. Enjoy!



Summary: Every two weeks in sprint planning, the product owner “buys” time from the team for solving production issues. The helpdesk then orders the issues the developers work on during the sprint by ordering the “Next” column on the Kanban Board. Whenever a user story is done on the Sprint Board, we pull the highest priority issue from the “Next” column on the Kanban Board. This makes sure the developers can finish stories with minimal disturbances. By doing this, this process helps to A) fight fire if needed and B) keep improving to serve the customers!

8 signs that you are working in a low trust environment

Vikram Kapoor Door: Vikram Kapoor,  21-01-2013
Onderwerp: High Performing Teams  Scrum Teams  

High performance is highly coupled to high trust environments. No high performance in Low trust environment unless your name is superman. What are the signs that you are working in a Low trust environment?

1.        The rule is document as much as possible. This is the only protection against somebody accusing you of wrongdoing. The documentation becomes a goal on its own and not a means to an end.

2.        Plans are made in concreet. They are cannot be changed to a changed reality. Changing a plan needs lot of discussion as the there is a lack of common value system and common ground. Better not change plans or you can get into a quicksand kind discussions.

3.        You need a signature/permission for everything. If you do anything without a signature your rear end is on the line. That is the reason that people do not show their entrepreneurial side in low trust environment. I have heard leaders complain that their people do not show entrepreneurial behavior, whilst these leaders were not in the process of creating a high trust environment which fosters entrepreneurial streaks.

Van Agile Development naar the Agile Company

Paul Weghorst Door: Paul Weghorst,  07-12-2012
Onderwerp: leiding geven  Scrum Teams  

Het ontwikkelen van software met Agile/Scrum is inmiddels doorgevoerd bij veel software-ontwikkelteams. Organisaties plukken dagelijks de vruchten van de grote voordelen van deze aanpak: elke paar weken werkende software, altijd het belangrijkste eerst en de focus op continu leren.
Veel organisaties maken nu de stap om de voordelen van Agile werken door te trekken naar de andere afdelingen van de organisatie. Om te beginnen langs de as van de software-keten: klant -> sales -> ontwikkeling -> beheer.

Organisaties die verder gaan hebben alle processen met Agile-principes ingericht. Prowareness is een goed voorbeeld: coaching, consulting, software development, sales, marketing en finance hanteren sprints, standups, reviews en retrospectives als tweede natuur.
Dat is geen sinecure voor grote organisaties met een traditionele plan/do/check/act-besturingsfilosofie. Hoe 'unfreeze' je een dergelijke organisatie op een beheerste manier?

How to Conduct a Large Retrospective

Rob van Lanen Door: Rob van Lanen,  02-11-2012
Onderwerp: Scrum Master  Scrum Teams  

A well-structured retrospective that generates change is vital to improve and grow as a team. When you facilitate a retrospective with multiple teams, you have a challenge to face. Do you have ineffective large meetings? Are these meetings slow, one-way, chaotic and not changing anything? Have you been thinking about conducting a large retrospective? After reading this blog, you will have a practical reference for facilitating effective retrospectives with a large crowd. You will have this post as a sample format to customize to the needs at hand in your situation.

It is wise to discuss the vision for such a session with your client beforehand. You could argue to organize several retrospectives when you have a big crowd. You could proceed by organizing a retrospective of retrospectives with a fraction of the crowd, however this would diminish the value of everybody’s participation in the retrospective. This post therefore describes how to do a retrospective with a large(r) crowd. With my client, we agreed on the following:

De meest gemaakte fout tijdens de Sprint Review/Demo

Rini van Solingen Door: Rini van Solingen,  02-11-2012
Onderwerp: Coaches  Scrum Teams  zelfsturende teams  

Veel Scrum teams maken de fout om de Sprint Review te gebruiken voor feedback van de Product Owner naar het development team. De Sprint Review meeting is echter helemaal geen acceptatiemoment voor de Product Owner, maar moet vooral een bijeenkomst zijn waarin feedback van belanghebbenden wordt gevraagd over het product én de product backlog.

Aan het einde van een Sprint laat een Scrum team werkende en geteste software zien aan de mensen die deze software gebruiken. Daardoor krijgen ze vroege feedback en de gelegenheid het product nog waardevoller te laten zijn. Om deze feedback op gang te brengen reserveert Scrum daar tijd voor. Elke sprint weer. Deze gebeurtenis heet: de Sprint Review meeting. In veel bedrijven hoor je ook wel spreken over ‘de demo’, waarmee ze eigenlijk de Sprint Review bedoelen. De meeting is een toets of je het hebt begrepen of dat je nog dingen niet begrijpt of bent vergeten. Een demo van de werkende software is een prima trigger voor dergelijke feedback. Het is voor eindgebruikers namelijk hartstikke moeilijk zich in te leven in software via een document, maar inleven via werkende software is dat een stuk eenvoudiger. In andere woorden: je krijgt het pas door als je het ziet.

Hoe bepaal je de kwaliteit van een Scrum team?

Sander van Prooijen Door: Sander van Prooijen,  23-07-2012
Onderwerp: Scrum Teams  

De afgelopen jaren  is “een Scrum team” is een veel voorkomend begrip geworden in software ontwikkelland. Het is de laatste jaren steeds meer duidelijk geworden dat alle bedrijven richting de Agile methodologie overgaan. Hierdoor kunnen ze een bepaalde kwaliteit producten opleveren of  in gebruik nemen. Snelle veranderingen in de markt alsmede veelal mislukte waterval projecten voeren deze verandering steeds meer aan.

Once upon a time…

Rob van Lanen Door: Rob van Lanen,  10-04-2012
Onderwerp: Scrum Teams  

… there was a team I was coaching. In a retrospective, the team created the following improvement goal for the upcoming sprint (two weeks): “As a team member, I want more insight in the sprint so we can make our deadlines”. My natural tendency is to inflict help by providing practical solutions, in this case lecture them on the correct use of a burndown chart. But I remained silent. The ideas were: “Give a user story a deadline date within the sprint”. “Create a story timeline for the next sprint”. “Make one developer responsible for finishing the story before the deadline”. So, we tried it out the next sprint. You can see the picture of the story timeline below. Note: there is one timeline per product (X and F).

Een echt Agile team is als Barcelona in het voetbal.

Sander van Prooijen Door: Sander van Prooijen,  02-03-2012
Onderwerp: Scrum Teams  

Barcelona is een van de teams die altijd attractief voetbal speelt, zij hebben een productieve houding en zijn als team goed op elkaar ingespeeld. Voetbal en Agile/Scrum zijn prima met elkaar te vergelijken. Het gehele Agile Manifesto blijkt zelfs raakvlakken te hebben met het voetbalspel. In deze blog wordt besproken hoe het Scrum proces van de voorbereiding tot na de wedstrijd wordt toegepast.  

Van Agile offshoring naar distributed teams

Rini van Solingen Door: Rini van Solingen,  02-03-2012
Onderwerp: Scrum Teams  zelfsturende teams  

Vorige week was ik te gast bij Effectory. Sinds een aantal sprints werken ze daar namelijk via distributed teams en daar hebben we samen een filmpje over gemaakt. Het filmpje wordt nog ge-edit, maar zodra het uit is zal ik het in dit blog includen. Distributed teams zitten op twee locaties: de ene helft dicht op de probleemeigenaar, de andere helft meestal op een locatie waar het makkelijk schalen en groeien is. Met behulp van dergelijke distributed teams worden een aantal communicatieproblemen opgelost die zich traditioneel in offshoring manifesteren.

When not to take NO for an answer and challenge your team!

Vikram Kapoor Door: Vikram Kapoor,  22-02-2012
Onderwerp: Scrum Teams  

Sometime you want your team to take up a task and they come back with a "Not possible" answer. Mostly you have to accept and thus bite your tongue. But when can you challenge them? I would say under the following circumstances:

  1. When you know that more is possible form experience.
  2. When your gut feeling tells you so! It is well known that Steve Jobs did so all the time sometimes to the despair of the team I am sure. The question is would we have the great Apple products without him challenging his team?
  3. If you notice that the team has developed limiting attitudes and assumptions. This could be anything like "we can not sell our products, it is recession" or "you need more time to produce good code". In that case it is time to expose the limiting belief and challenge it!

It is not easy to know when to cross the line and when not to in order to challenge the team/ believes. Can you have a clear golden rule?I think not! This means that it is perhaps better to try and apologize later if you are out of line

Team workshop: the Knowledge Matrix

Ronald de Leeuw van Weenen Door: Ronald de Leeuw van Weenen,  25-01-2012
Onderwerp: Scrum Teams  

Recently, I have been coaching teams that consisted of several specialists. These specialists have certain knowledge that is not shared with other team members. This is a risk to the team, since:

  • Absence of the specialist can keep the team from reaching the sprint goal
  • A specialist can easily be overloaded with work in one sprint while the rest of the team is not fully utilized, or the other way around
  • The company can be at risk when the specialist has key knowledge on mission-critical applications

 This had been identified already during the first retrospective, and we found a way to easily identify these areas of specialization and improvement opportunities to resolve them: the Knowledge Matrix.

How To Improve Your Retrospective

Rob van Lanen Door: Rob van Lanen,  25-01-2012
Onderwerp: Scrum Teams  

Are you conducting retrospectives without effects? Are you coping with finding the correct structure, format and variation in your retrospectives? How great would it be if your team would have more fun, invested in their relationships, build trust, and ultimately --  reach a higher productivity so your company can delight its customers? After trying out the solutions in this post, you  know how to structure a retrospective and where to focus on.  You have an invaluable tool in your toolbox: a well executed Retrospective to improve the performance and effectiveness of the team.