Sid on Agile
Wednesday, 27 November 2019
Thursday, 8 November 2018
Effects on a team when you change it
Following
up to a discussion I had as an Agile Coach with a team, I painted a simple
graph what can be a great food for thought and discussion: what happens if you
fiddle with the team size?
In
Agile and Scrum utopia teams exists forever and have time and means to improve
themselves. They are self-steering so take care of the team as well. In
practice, that usually is not the case. Sometimes (in the consultancy project
driven world I work in) there are budgets, projects and project managers who
guard these. As an Agile coach you’re sometimes caught in the middle when “resources”
(they mean: people) are added or removed from teams due to several reasons. To
help clarify the effects of this I like to share these thoughts with you.
Startup and sustain periods
When a new team starts (e.g. when a new project
starts in the previous mentioned world) a certain “normal” pattern occurs with
the team’s velocity. The first 3 or 4 sprints or so, the velocity increases.
People get to know each other, the team is getting used to their teammates and
the subject matter becomes more known. I call this the startup period. Length
may vary depending on the team, the subject matter, the organization, the
sprint length, etc.
After
that, a period starts I like to call the sustain period. The velocity might go
up or down based on the ability to improve, but I like to look at what happens
when something is done with the people in the team.
A subject matter change
(A)
If the team starts working on something
completely different, like a new website, maybe some other technology, a lot of
knowledge collected is no longer useful. Maybe another Product Owner gets in
place and stakeholders change. This has quite a severe effect on the velocity.
Almost like the start of a new team, only the team dynamics stay in place; they
know each other and their competences, but a lot of new stuff and new
communication lines need to be discovered and installed. This is maybe unavoidable,
but one need to realise what the effect is.
A small team change (B)
A small team change can be replacing a team
member or adding but not removing a team member (see D and E for that). The
good thing here is, that the (usually unwritten) knowledge of the team remains,
the new guy learns from the team members and gets introduced into their way of
working and communicating. The impact isn’t that big (as long as the team
member leaving isn’t the team’s superhero, which a team shouldn’t have, but
that’s another subject) but still everything goes down for a bit: velocity,
predictability, the average number of stories done, the estimation accuracy and
the matter knowledge.
A big team change (C)
A big team change is usually not recommended,
you lose the knowledge of the team and it’s like a new team with a few people
who know how they did it in the old team. This brings the team back to start
and basically back into the startup period. Getting to the sustain period might
go a bit more smoothly depending on the knowledge left over in the team.
Up sizing or downsizing (D
and E)
When people are added or removed from the team,
basics like velocity and number of stories done go up or down accordingly, but predictability,
estimation accuracy and matter knowledge go down in both cases. Since there is
a new team member or a team member has left, the team needs to restore balance.
That influences predictability, because they need to find out how to estimate
in the new setting. Maybe a story point devaluates and that does not matter, because
a story point in itself has no meaning, but is a means for the team to do their
planning. They have to reestablish that. Of course some knowledge leaves with the
leaving team member and a new team member needs to acquire that knowledge, so
matter knowledge will suffer.
Conclusion
I realise that this is a quite generic approach,
but I hope it helps the discussion and the understanding people have when you
change a team or the team changes itself (that would be the best variant). For
specific teams in specific situations, this all happens (a bit) different, but
I think this is a good starting point. So I hope this helps you and please
share your experiences with me!
Friday, 13 May 2016
Why do we have this Sprint Goal?
The idea of
a Sprint Goal is to know why you are doing things. In the previous version of
the Scrum Guide, it was about completing the sprint, now it’s about meeting the
sprint goal. That’s in a lot of aspects the same thing, but for example, when
the Sprint Goal becomes absolete, there is no need to complete the sprint,
since the Sprint Goal has no value. Using a Sprint Goal helps the Scrum team to
focus on the purpose and value of what they’re doing, instead of just finishing
the sprint.
It is not
mentioned in the Scrum Guide how to document the Sprint Goal, or even if you
should do that at all. I would say that the purpose of a Sprint Goal is met
when the Scrum team has the Sprint Goal clear for everybody. Tools to help
there would be:
- Writing it on a big piece of paper and put it on the wall of the team’s location, next to / on the Scrum Board;
- Share it in a visible way digitally (helpful when not all team members are on the same location);
- Talk about it (at least in the Daily Scrum)
·
…
These are
the most important parts in the Scrum Guide (2013) about the Sprint Goal:
Topic One: What can be done this Sprint?
…
After the
Development Team forecasts the Product Backlog items it will deliver in the
Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective
that will be met within the Sprint through the implementation of the Product
Backlog, and it provides guidance to the Development Team on why it is building
the Increment.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met
through the implementation of Product Backlog. It provides guidance to the
Development Team on why it is building the Increment. It is created during the
Sprint Planning meeting. The Sprint Goal gives the Development Team some
flexibility regarding the functionality implemented within the Sprint. The
selected Product Backlog items deliver one coherent function, which can be the
Sprint Goal. The Sprint Goal can be any other coherence that causes the
Development Team to work together rather than on separate initiatives.
As the
Development Team works, it keeps the Sprint Goal in mind. In order to satisfy
the Sprint Goal, it implements the functionality and technology. If the work
turns out to be different than the Development Team expected, they collaborate
with the Product Owner to negotiate the scope of Sprint Backlog within the
Sprint.
Daily Scrum
…
The
Development Team uses the Daily Scrum to inspect progress toward the Sprint
Goal and to inspect how progress is trending toward completing the work in the
Sprint Backlog. The Daily Scrum optimizes the probability that the Development
Team will meet the Sprint Goal. Every day, the Development Team should
understand how it intends to work together as a self-organizing team to
accomplish the Sprint Goal and create the anticipated Increment by the end of
the Sprint. The Development Team or team members often meet immediately after
the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of
the Sprint’s work.
Thursday, 21 February 2013
Wil ik mijn Product Owner wel in de Retrospective? (NL)
We hebben inmiddels 13 Sprints erop zitten, en eigenlijk is alles in onze Scrum inrichting wel op zijn plaats. In een van de laatste Retrospectives kwam de vraag ter sprake of het handig zou zijn om de Product Owner (PO) deel te laten nemen in die Retrospectives?
Allereerst kun je kijken wat Scrum daar zelf over zegt. Volgens scrumalliance.org (1) moet de PO hier niet aan deelnemen. Ze zeggen dat het een meeting is tussen het Team en de Scrum Master.
Voors en tegens
Scrum Master Jack Mulunsky pleit op blog.agilebuddy.com (2) ervoor om de PO wél te laten deelnemen. Hij vindt het belangrijk dat deze betrokken is gedurende de gehele development life cycle en daarmee ook invloed heeft op het succes van het team. Hij vindt het belangrijk dat het team “leert leven” met de PO. Dit is voor mij een argument wat ook zwaar meetelt, onze PO geeft uit die motivatie onze demo’s met het team.
Scrum Master Bartek Kobilecki vraagt op pm.stackexchange.com (3) of de PO bij álle Retrospectives aanwezig moet zijn. Zijn PO staat daar zelfs op. De Scrum Master vreest dat door de aanwezigheid van de PO mensen bevooroordeeld of op zijn minst met een voorbehoud zich zullen gedragen in de Retrospective. Dat punt zie ik ook wel, op zijn minst vanuit het onderbewustzijn, aangezien de PO toch de organisatie van de opdrachtgever vertegenwoordigt en daarmee een gevoel van een hiërarchische verhouding ontstaat. Daarentegen vind ik transparantie een groot goed, en zou je moeten werken aan het wegnemen van het genoemde voorbehoud door altijd open en eerlijk te communiceren. Opmerkelijk is wel dat Kobilecki de PO “de baas van de teamleden” noemt. Ik denk dat hij zich daarmee wat beter in Scrum moet verdiepen.
Radu Davidescu reageert op de vraag van Kobilecki dat het belangrijk is dat, wanneer de PO aan de Retrospective deelneemt, er de kans bestaat dat deze een groot deel van de meeting aan het woord is (en dat het team gaat zitten luisteren, red.). Hij vindt dat de PO dan ook alleen op uitnodiging van het team aan de Retrospective mag deelnemen.
Het team
Goed, meerdere argumenten dus. Overigens ook veel discussie over of de PO deel uitmaakt van het team. Ik snap de verwarring wel, maar als je kijkt naar de 3 rollen die Scrum kent: PO, Scrum Master en Teamlid, dan zou je kunnen stellen dat vanuit de rollen dat niet zo is. Vanuit de groep mensen die bezig zijn met het product en proces, zou je kunnen zeggen dat deze 3 rollen het team vormen.
Conclusie
Mijn benadering is eigenlijk heel eenvoudig, en helemaal Agile: we gaan het proberen en kijken of het werkt. Dan komen we te weten of de voordelen opwegen tegen de nadelen. En hier raken we dan ook wel de kern: de daadwerkelijke implementatie van Scrum is altijd anders dan de droge theorie, omdat alle organisaties en mensen anders zijn en denken. Zaak is dat je trouw blijft aan het principe van Inspect and Adapt en dat je het proces continue verbetert.
Referenties
- Glossary of Scrum terms:
http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1113 - Should the Product Owner be an active member of the Scrum team:
http://blog.agilebuddy.com/2009/04/should-the-product-owner-be-an-active-member-of-the-scrum-team.html - Should Product Owner be present on all retrospectives:
http://pm.stackexchange.com/questions/5681/should-product-owner-be-present-on-all-retrospectives
Monday, 10 December 2012
De zwijgende SCRUM master (NL)
Een bekend dillema, vooral voor SCRUM masters die een technische achtergrond hebben (bijvoorbeeld als ontwikkelaar): het team staat voor een uitdaging, en jij hebt ideeen over de oplossing...
Een lastige. Ik ken het gevoel. Maar als SCRUM master is je doel om je team te ondersteunen en stimuleren vele malen belangrijker. Wanneer je meegaat in de materie, verlaat je het proces. En ik ben van mening dat je daar altijd 100% bovenop moet zitten. Het kan wel zijn dat je een inhoudelijke bijdrage kán leveren, maar wanneer het team niet meer functioneert als team, verlies je veel meer. Een opmerking als "hoe zouden we dit kunnen aanpakken?" heeft zoveel meer waarde. Je team wordt dan gestimuleert om ideeen te spuien, te delen en als team na te denken, binnen de context die zij het beste kennen.
De manier en de oplossingen waar het team mee komt, bepaalt ook de kwaliteit en uiteindelijk de velocity van dat team. Als je daar, afhankelijk van jouw incidentele kennis, input aan levert en dit tevens ten koste gaat van het proces, gaat dit ten koste van de glorie van het team.
Wanneer je als SCRUM master en coach het proces zo optimaal mogelijk weet te krijgen, investeer je daarmee in de komende 100 sprints. En als je je overal mee wilt bemoeien, had je projectmanager moeten worden...
Een lastige. Ik ken het gevoel. Maar als SCRUM master is je doel om je team te ondersteunen en stimuleren vele malen belangrijker. Wanneer je meegaat in de materie, verlaat je het proces. En ik ben van mening dat je daar altijd 100% bovenop moet zitten. Het kan wel zijn dat je een inhoudelijke bijdrage kán leveren, maar wanneer het team niet meer functioneert als team, verlies je veel meer. Een opmerking als "hoe zouden we dit kunnen aanpakken?" heeft zoveel meer waarde. Je team wordt dan gestimuleert om ideeen te spuien, te delen en als team na te denken, binnen de context die zij het beste kennen.
De manier en de oplossingen waar het team mee komt, bepaalt ook de kwaliteit en uiteindelijk de velocity van dat team. Als je daar, afhankelijk van jouw incidentele kennis, input aan levert en dit tevens ten koste gaat van het proces, gaat dit ten koste van de glorie van het team.
Wanneer je als SCRUM master en coach het proces zo optimaal mogelijk weet te krijgen, investeer je daarmee in de komende 100 sprints. En als je je overal mee wilt bemoeien, had je projectmanager moeten worden...
Tuesday, 27 March 2012
Frequent Agile Questions #1: Kan ik Agile zijn als de rest van mijn organisatie dat niet is? (NL)
Ik ben enthousiast geworden over Agile nu ik er over gelezen heb.
Collega's die ik spreek zijn onverdeeld enthousiast. Ik heb de knoop doorgehakt
en werk nu Agile en dat willen mijn klanten ook. Waarom werkt het nou toch
niet?
Wanneer je besluit om Agile te gaan werken, begin je niet alleen aan een nieuwe manier van werken, maar ook aan een nieuwe manier van denken. De redenen waarom je de dingen doet die je doet, veranderen. Je verandert vaak van efficient gedreven werken naar effectief werken. Het is goed om er meteen mee te beginnen, maar tegelijkertijd gaat je organisatie een transitie in.
Van Waterfall via WAgile naar Agile
Je zult veel energie moeten steken in het promoten van de "Agile mindset" bij iedereen waar je mee te maken krijgt. Je hebt bij je development process te maken met Business stakeholders, grafische vormgevers, testers, functioneel ontwerpers, projectleiders (!), developers voor front- en back-end, etc. Hoe meer partijen de Agile mindset delen, des te beter werkt het. Sterker nog, in je eigen clubje kun je maar beperkt successen boeken. Want na enige tijd loop je tegen deze problemen aan:
Wanneer je besluit om Agile te gaan werken, begin je niet alleen aan een nieuwe manier van werken, maar ook aan een nieuwe manier van denken. De redenen waarom je de dingen doet die je doet, veranderen. Je verandert vaak van efficient gedreven werken naar effectief werken. Het is goed om er meteen mee te beginnen, maar tegelijkertijd gaat je organisatie een transitie in.
Van Waterfall via WAgile naar Agile
Je zult veel energie moeten steken in het promoten van de "Agile mindset" bij iedereen waar je mee te maken krijgt. Je hebt bij je development process te maken met Business stakeholders, grafische vormgevers, testers, functioneel ontwerpers, projectleiders (!), developers voor front- en back-end, etc. Hoe meer partijen de Agile mindset delen, des te beter werkt het. Sterker nog, in je eigen clubje kun je maar beperkt successen boeken. Want na enige tijd loop je tegen deze problemen aan:
- De business maakt zich druk over het feit dat je ze
niet kan vertellen wat een project gaat kosten;
- De projectleider wil toch eigenlijk wel graag de scope
vastgelegd zien, en graag in het begin van het project. Hij wil meer
informatie vooraf, er moet tenslotte een PID gemaakt worden;
- De grafische vormgevers vragen zich van tevoren af wat
ze allemaal moeten ontwerpen en achteraf waarom men zich niet aan hun
design gehouden heeft;
- Developers zullen constant geneigd zijn om iets
"helemaal af" te maken en passeren het incrementele principe.
Dat zijn dan enkele voorbeelden, ik
denk dat ik er nog vele kan noemen. Maar als je aan de wieg hebt gestaan van
het Agile werken in je bedrijf, zul je mijn voorbeelden zeker herkennen.
Investeer dus tijd en moeite om dergelijke problemen te addresseren, en blijf iedereen vertellen waarom je het allemaal doet: stick to your principles. Ook en misschien juist bij tegenslagen. Vier je successen en deel ze met de anderen. Werk aan het besef dat je het allemaal doet om waarde aan de onderneming toe te voegen en niet om wilde ideeen te laat, met een overrun en verspilde energie uit te voeren.
Do the right things and do things right...
Investeer dus tijd en moeite om dergelijke problemen te addresseren, en blijf iedereen vertellen waarom je het allemaal doet: stick to your principles. Ook en misschien juist bij tegenslagen. Vier je successen en deel ze met de anderen. Werk aan het besef dat je het allemaal doet om waarde aan de onderneming toe te voegen en niet om wilde ideeen te laat, met een overrun en verspilde energie uit te voeren.
Do the right things and do things right...
Labels:
Agile,
Business Value,
management considerations,
methodology,
SCRUM,
Transition
Subscribe to:
Posts (Atom)
Labels
- Agile (10)
- SCRUM (10)
- management considerations (6)
- methodology (6)
- usability (5)
- Business Value (4)
- ria (4)
- flex (3)
- marketing (3)
- user centered design (3)
- Transition (2)
- application design (2)
- distributed SCRUM (2)
- maturity (2)
- microsoft (2)
- offline desktop applications (2)
- AIR (1)
- CSS3 (1)
- Firefox (1)
- HTML (1)
- HTML5 (1)
- International teams (1)
- PET design (1)
- Twitter (1)
- adobe (1)
- advertising (1)
- browsing (1)
- copy (1)
- customer experience (1)
- demo (1)
- design guidelines (1)
- filesystem (1)
- generations (1)
- incremental (1)
- iteration (1)
- maths (1)
- online applications (1)
- optimization (1)
- people (1)
- popularity (1)
- progress (1)
- projects (1)
- raking (1)
- ria projects (1)
- rounding (1)
- silverlight (1)
- social media (1)
- teams (1)
- time boxing (1)
- usability testing (1)
- web 2.0 (1)
- website design (1)
- website development (1)