Professional Documents
Culture Documents
Background
4 person development team was formed about 1,5 years ago. Team
members were selected based on a cv, a hourly fee, psychological tests,
and an interview. Two people knew each other from earlier project, but
everyone else were complete strangers. National Land Surveys project
team consisted of Product Owner / project manager and about 8
subject-matter experts. Product owner had no previous experience on
Scrum but he had been coached on Scrum prior to kick-o. Team chose
me to work as a Scrum Master.
We started Scrum by the book. Two week iterations, Denition of Done,
retrospectives, you name it. Some of our initial DoD agreements did not
materialize immediately but got better while team learned to know each
other. Basically steps that team went through in terms of Scrum
implementation improvements were:
Scrum by the book, velocity, definition of done
Unit testing
Swarming
Continuous integration
Automated UI tests
No Monday sprint plannings
Team member cross testing
Process waste visualization
Team does not jell immediately and this takes time. Even though I knew
all these things would be nice and even mandatory to have in place, you
should not force them on a team if it is not ready. In addition, team felt
that it had to make progress with features and team's process
improvements would have to be made in small steps. I feel that every
team will have to discover their own process and you cannot copy-paste
team culture. Therefore, rst important rule for organizations:
Group prototype
Once group starts to work together it begins to form a group prototype.
This prototype represents us and it aects teams self-image. If
prototype is energetic and responsible you are more likely to get good
results than when prototype is a sloth. This whole prototype thing is
actually really interesting as it also means that those who are
prototypically central become highly inuential. Check out this nice book
about the subject (http://www.amazon.com/Blackwell-Handbook-SocialPsychology-Processes/dp/1405106530/). In short, well functioning team is
a gem. Try not to break it.
work that had to be taken care of right away was mostly production
maintenance and occasionally some bug xing. Team (and PO) felt that it
could not wait for two weeks just to t these expedites into a sprint.
Furthermore, team began to encounter stories that were really dicult to
estimate. This could be a 1 or a 10, it depends on x. Team felt that
estimation of these tasks was waste because they had to be made
anyway. Downside of this of course was the fact that when some story
was ten times bigger than originally estimated, sprint goal was pretty
much nullied. In addition, team had challenges with work that had to be
stopped because sprint was over. This caused situations where everyone
knew that a feature needed an improvement but because there was not
enough time to do it, team decided to move improvements to next sprint.
This is somewhat wasteful because it would be nice to completely nish a
feature team is working on if everyone agrees that it lacks some key
functionality. Why move work in to the future? "Because we do not have
time right now". This lead us suggesting the use of Kanban to PO. Luckily,
he agreed.
After three months of development and 4 version later, our board looked
like this:
(/img/blog/kanban.png)
(click to enlarge)
Development team's Kanban process went like so:
Development team used the Kanban board, "project team" did not.
Product backlog was still maintained by the PO and stories were
estimated in product backlog like in Scrum. Sprint plannings were
replaced with pull planning. When selected stage had room, PO chose
next tasks on to the board. Once Analysis stage had space development
team broke user stories into tasks like in sprint planning. The dierence
was that these planning sessions were much shorter than with Scrum as
usually only one story had to be analyzed. Team had 3 implementation
lanes. When there were empty slots, story was moved onto the
"development" stage. Then, slowly tasks moved across implementation
and once everything was coded, tested and ready, story was deployed to
"staging" environment and PO was notied. Next, PO and project team
veried that everything was OK after which story was scheduled to a
release. One lane was reserved for expedites. Plain and simple! Did that
work? Well, thats a good question.
In third picture, I have created a boxplot to see how lead time varied
between releases.
Based on these images, I would say team's process was pretty stable.
Was this data usable or not? Theory is that once we know our average
lead time and standard deviation we can establish a SLA. Then
organization can order features and be somewhat condent that it will
get them when needed. Problem with this logic is that in our case
organization was not particularly interested in this stu. They were more
interested in release level information and Scrum style velocity
information was enough for them. That being said, in some other context
this could be vital information. So, what else? Benets also included the
fact that the team members were more aware about the status of a story.
Is this already deployed to test? The board told you.
Work was nicely organized as everyone in the team could see
progress on the board
Also, team's initial concern about expedite work worked out pretty well.
But does this encourage towards could you x this for me quickly type
of behavior that is the one main thing we are trying to avoid with Scrum? I
think so.
Team was very responsive to expedites. But this is not necessary a
good thing.
What's next?
If you are having thoughts on your Agile implementation we should
arrange a meeting. Check out how I can help you (/agile).
Back to blog (/blog)
Discussion
3Comments
Recommend
samuliheljocom
Share
Login
SortbyBest
Jointhediscussion
DavidMurphy 6monthsago
Onlyjustcameacrossthis,btitsaveryusefularticle,even4yearslater:)Andthanksforusing
Disqus,soonmucheasier.
Reply Share
DanLinstedt 2yearsago
Thankyouforsuchabrilliantandinsightfulpiece.Iappreciatedreadingaboutboththepositives
andnegativesofyourexperience.Iwouldlikepermissiontoquoteyourmaterialandthispost,in
mypresentations.
Reply Share
SamuliHeljo
Mod >DanLinstedt
2yearsago
Dan,Thanksforthefeedback.Youhavemypermissiontoquotemymaterial.
Reply Share
WHAT'STHIS?
ALSOONSAMULIHELJOCOM
Agilevs.LeanSixSigma
Stopusingstorypoints?
6comments2yearsago
2comments2yearsago
SamuliHeljoIfyourgoalistoworkwith
SamuliHeljoThanksforthecomment!My
softwareteamsororganizationsthatdo
softwareengineeringIwouldstartwithAgile
andthenproceedtoLean.Ifyourgoalisto
bloggingratehasindeeddeclined,projects
consumenowadaysthatmuchtimeplusItry
tokeepwritingcodeonmysparetime:/
Contact me
Copyright 2015 Samuli Heljo. All rights reserved.