2. so what's this about ?
Agile management in MVNO
project - GaduAIR
During launch - January 2008 until May 2009, and
maintenance and development later on
3. who are we ?
Grzegorz Machniewski Dawid Mielnik
• Until July 2010 Telco • Until July 2010 Telco
dept. @ Gadu-Gadu dept. @ Gadu-Gadu
• Before: IBM, Outbox • Before: Citi, DRSA
• After: Voiceware S.J., • After: Voiceware S.J.,
Moberia sp. Z o.o., XEO Moberia sp. Z o.o.
Games sp. Z o.o.
7. internal departments
• "clients" • "providers"
• Business • Admins
• Marketing • Server dev
• Sales • Web dev
• Board • GG client dev
• Accounting • Mail dev
• Security • QA
9. SCRUM didn't work
Sprint planning was a
challenge
• Organisational - 5 teams with totally different
tasks
• Defining the scope with so many variables,
dependancies not controlled by the teams
10. SCRUM didn't work
Problems with deliverables
from external vendors
• Deadlines - frequent delays
• Functionality - does not work or works not
according to specs, or is unstable
11. SCRUM didn't work
Other problems with vendors
• Communication
• Long time for problem resolution
• Rotation of team members
12. SCRUM didn't work
Problems with schedules of internal
providers
• Need to fit into other schedules not fully consistent with
our
• Fight for compromises and giving higher priority to our
tasks
15. SCRUM didn't work
(additional afterthought)
Agile methodology means
less paperwork and
formalities which unfortunately
works to our disadvantage
with vendors
16. ...the outcome was:
• Sprint plannings were long and boring for most
people (the same with retrospections)
• None of the sprints were finished in time and in
some none of the backlogs were done
• Frustration - our, in our teams and internal
clients, strained relations with vendors
• Deadlines not met
17. We decided to do
something about it...
Step 1
• We stopped Sprint planning in favour of quick planning in
individual teams
• Every team had individual backlog and sprint
• We losened a little the sprint concept and everything related to it
• We started to prioritise tasks on daily bases according to what
was more urgent
• We started to define new states for tasks which waited for
something independent of the team
18. ...as it later turned out we
were approaching ScrumBan
• Breakthrough at first Agile Warsaw meeting
entitled Scrum vs. Kanban
• It turns out this is the tool which we need
• We have noticed that we started using certain
practices naturally
• Pity that we discovered Kanban so late
19. SrumBan worked much
better
Step 2 - migration to ScrumBan
• We stopped sprints and planning in favour of ad-hoc
planning and estimation on daily basis
• Limit to number of WIP tasks per person
• Highest priority for fuckups and errors
• Reorganising the teams - 3 teams: devel, telco, operations
• Individual task states for each team
23. ScrumBan - observations
• We had the pleasure of working in the new arrangement
for 2 months
• Decreased level of frustration with the process was evident
• Increase in productivity and quality of work of the teams
• Shorter time from submission to delivery of task
• ScrumBan did not solve all of our problems but it did solve
most of the problems associated with the process,
increasing the comfort of work
