Skip to main content

Scrum rollout

Would you like to start with Scrum in your team?
These are few hints from my experience how to make this process smooth, iterative & incremental:

  1. get commitment from the management & team
  2. define reason: why would you like to do Scrum? what problems it should solve for you?
  3. start with simple Kanban in one team: it is easier, you just need to manage 3 lists: backlog (todo), work in progress and done 
  4. focus on right priorities of backlog - person who defines the priorities will be 'product owner'
  5. setup quick way how to track work in progress and indicate 'impediments' -> daily stand-up; max 15 minutes meeting every day - moderator of the meeting will be 'scrum master', he will be also responsible for solving the 'impediments'
  6. focus on dependencies between the tasks to avoid 'impediments'
  7. start to put 'discoveries' into the backlog to pre-analyze tasks; discoveries should be done by architect or analyst
  8. what is the business value of tasks in your backlog? start think about them as 'user stories'
  9. group big set of 'user stories' into 'epics' to track progress of the 'epics'
  10. try to have 'user story' doable in 1-5 days by 1 or more developers; 
  11. think about: definition of ready? when I can put 'user story' into the backlog? do I need more input or analyze?
  12. think about: definition of done? when is 'user story' really done (done-done: code committed, junits green, CI green, code reviewed, QA smoke test OK...)
  13. start to do release candidate every 2-3 weeks, use period which is feasible for you
  14. try to estimate complexity of 'user stories' in advance every week; just assign a value (1,2,3,5,8,13, ... Fibonacci)
  15. count total complexity of 'user stories' for chosen period of time
  16. after few periods compute average and this will be your 'velocity'
  17. try to time-box your backlog - this will be your 'sprint'
  18. at each end of the 'sprint' you should be able to deliver a release with all QA work done
  19. estimate and prepare one 'sprint' in advance - do 'backlog grooming' regularly every week - challenge your 'velocity'
  20. start on-boarding of the other teams and focus on coordination
  21. apply 'Sprint' shield strongly  
  22. do 'review meeting' at the end of each 'sprint' 
  23. do 'retrospective meeting'; ask questions like:  what went well?, what was a puzzle?, what we learned? what we need to improve/learn? - maintain list of improvements and plan them into the next 'sprints' 
  24. do 'planning meeting': set priorities of pre-estimated backlog and prepare the 'sprint' according the 'velocity'; take into account vacations and day-offs - calculate 'team availability' in hours
  25. do 'tasking': break 'stories' into smaller tasks and estimate them
  26. maintain 'burn-down chart' for current 'sprint' according to the 'team availability' and sum of hours for all tasks - team should maintain 'remaining work' - escalate and take appropriate action if problem
  27. do 'backlog grooming' meeting every week: estimate, think about dependencies & readiness, plan, prepare options and 'what if' scenarios
  28. do 'scrum of scrums" - coordination meeting between the teams ('scrum masters and product owners')
  29. establish regular inter-team architecture group to work on common architecture & design stuff
  30. do weekly 'bug triage' meeting between testers & product management to define 'fix in sprint' for each particular bug and discuss necessity of hot-fix
  31. quarterly do 2-3 days workshop between product/project management  & representatives of the teams to define high level 'epic' road-map for next 3 month; the road-map then will be an input for 'grooming & discovery' sessions where it will be break-down into stories and sub-tasks
  32. almost Scrum or not?  ;-) - to reach this point you probably worked 12 month
  33. check if your problems from #2 were solved
  34. work on continues improvement
NOTES: 
  • all this will need to have / to build solid Software Factory
  • if 'retrospective' is quick, just formal, people do not contribute -> lack of commitment
  • if 'grooming' is very quick -> you probably doing 'scrum-fall'
  • prefer 'fail fast' strategy
  • problems are exposed very quickly in good Scrum implementation -> do not hide them - solve them
  • do not forget that Agile development is good for Agile projects, if customer can deploy the release 1 or 2 times a year and they give you feedback in similar manner it will not be very Agile
  • if team have to do more than 20% of maintenance you would probably end up with Scrum-Ban
  • Scrum is not always 'agile' in sense that anytime customer can change anything
  • 'Velocity' is parameter of the team not performance KPI
  • Scrum is necessary combine with Extreme Programming to achieve best results

Comments

Post a Comment

Popular posts from this blog

Senior or Junior

Usually companies call young employees Juniors and more experienced Seniors. Sometimes you need to just sit and wait and it will come. Sooner or later. From my point of view it is not enough. I met a lot of old employees they call themselves Seniors but they behave like Juniors. So I defined my point of view on Seniority: professional simple understand what I am doing and understand reason why I am doing it can coach others this is very basic; who can coach others is just fine but who can coach others to became a new coaches is super not genius but have deep knowledge on some specialized parts geniality is overestimated, we do not need "magical guru", to be expert is good enough; if you are "one to go" when there is problem, it is OK big picture overview it is not probably possible to understand a whole system in details but it is necessary to have at least overview know what I know and know what I do not know to see myself in correct light is very ...
Post a Comment
Read more

Anti-Lean Quotes

Set of quotes which usually highlights Anti-Lean behavior Create waste instead of Eliminate waste ' Developer who is not working at least on 4 projects is not properly utilized ' - less is definitely more and only done-done work counts by end of the day, limited work in progress is helping to focus on right priorities ' In case of any network issues please create a ticket on the help desk system at our partner's web-page' - creating catch 22 situations by design is craziness, such a process does not make any sense 'Yes, this is what our customers really need but could we add also this small feature, just in the case?' - extra feature creates an extra complexity, it is better to stay focused on real value and make it great for the users ' I know that you are working on the top priority but I am sure that you can do also this small task till noon' - probably there will be nothing really done by noon, task switching is more expensiv...
Post a Comment
Read more

Software Engineer

Recently my company expanded the Software Engineer positions in my team. This leads me to thinking about the skills which are necessary for these positions. So I prepared a list of qualities which I think are important for a good Software Engineer. Abstract concept modelling This is essential and there is no room for discussion on this because this is what we do. Love to code It does not matter if you are 15 or 50 or if you write code 10% or 90% of your time, code writing is crucial. Team player The surgeon style teams (one genius with helpers) are obsolete, I prefer real team players who are able to work towards a common goal and share responsibilities. Communicative Silent geeks siting in the corner with a notebook on their knees are not cool any more, we need to talk to each other, we need to be able explain technical stuff to non technical managers, we need to be able to choose the right phrase at the right time. Take responsibility There is...
Post a Comment
Read more

Agile is not a religion

It is quite annoying to me when argument during discussion is like this:  it must be XY because the book says it. It is kind of: Bible is saying XY so we have to follow = end of discussion.  I am not very happy in such a case because we probably do not understand principles and just trying to blindly imitate something without deep knowledge of the matter. I prefer to admit it or show personal standpoint.
Post a Comment
Read more