Published on

Scrum and a mild form of Kanban at a small Swiss company in the financial sector. Reinvented as a Crystal Clear project.

Published in: Technology, Business
  • as: Hey, very nice show on the scrumban method - thank you! I liked how you were not afraid to admit you weren't entirely sure if this would work for your team, I think too many PMs are over-confident about getting going with new methods of working. Nice to see it worked in the end. I was basing my recent implementation on the info I've got from here: - we are now waiting to measure the results after first 3 months of scrumban. Fingers crossed ; ) Thanks for your perspective!!
    Are you sure you want to  Yes  No
    Your message goes here


  1. 1. Improving speed and effectiveness of in­house software development Scrum(ban)*at Zahnärztekasse AG *and Crystal Clear Jens Meydam
  2. 2. Zahnärztekasse AG? Scrum? Scrumban???    
  3. 3. Zahnärztekasse AG ● around 35 employees ● offers financial services to dentists, mainly in  connection with processing invoices ● total value of processed invoices:                  over CHF 250 million per year ● IT (obviously) plays a central role  ● more information:    
  4. 4. Scrum How many of you have been to a Scrum course   or have read a book on Scrum?    
  5. 5. Scrum – elevator pitch You have thirty seconds to convince your boss  to try Scrum.    What would you say?    
  6. 6. Scrum – elevator pitch (1) “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle, p. 82: Jeff Sutherland, VP of Engineering, went to the President of Easel Corporation, and asked him, "Have you ever seen a development team to meet a traditional project plan."      
  7. 7. Scrum – elevator pitch (2) He said, "No."      
  8. 8. Scrum – elevator pitch (3) Jeff said, "I think the only thing you can trust is working software that the team can demo. If you give the team complete freedom for 30 day Sprints, at the end of the Sprint you will see exactly where the product is, for better or worse."      
  9. 9. Scrum – elevator pitch (4) He said, "Fine, for the first time I will know where product development really stands and can make the appropriate decisions. I'm willing to take the risk of giving the team autonomy for defined periods."      
  10. 10. Scrum – roles ● Product Owner: decides on the direction of  development – what will be developed in what  order ● Scrum Master: helps the team to be successful,  in particular by removing obstacles to higher  productivity ● Team: is responsible for delivering the software  with top quality in small increments      
  11. 11. Scrum is a broad church There is more variation out there – and for good  reasons! – than some people might like    
  12. 12. Scrumban ● Scrumban = Scrum + kanban  :­) ● the name was coined by Corey Ladas in a  slightly inflammatory article:­ban/ ● here kanban = kanban system for software  development (a Lean tool)    
  13. 13. Kanban systems ● kanban systems for software development are  task/story boards on steroids ● you saw a very basic one on the first slide:     
  14. 14. Kanban systems ● there are some good introductions by well­ known members of the agile community: –  – ● on InfoQ you can find a presentation by David  Anderson, one of the leading lights of the  kanban enthusiasts: –­for­software    
  15. 15. Now you know ... ● what kind of company I work for ● how to describe Scrum in thirty seconds ● where this horrible new term “Scrumban”  comes from    
  16. 16. In­house software development ● most of our software development enables and  supports internal operations   ● most of our users are in the same building ● there is only one installation ● the senior developers have full control over the  production environment (of course, with       great power comes great responsibility!)    
  17. 17. In­house software development ● all this simplifies software development a lot      (I know ­ I used to work for a software company  with commercial products)  ● the problem of in­house software development  is that its importance tends to be underrated  (because it "just costs" money) ● it is much harder to justify the kind of budget  needed for serious development    
  18. 18. Before Scrum ● at Zahnärztekasse AG, the dominant pattern  had been to define small development projects  and to assign these projects to individual  members of the staff (who thus became "project  managers", but this was usually just one of  many tasks for them) ● this had worked reasonably well, but there were  several disadvantages:    
  19. 19. Before Scrum ● productivity suffered from multitasking (too  many projects stayed "90% complete" for too  long) ● there was too little collaboration among the  development staff, which had a negative impact  on design quality  ● there was usually not enough momentum for a  systematic improvement of the infrastructure    
  20. 20. A new project ● in the first half of 2008 a consensus emerged  that the time had come for modernizing the core  infrastructure and the user interface ● we had many ideas for improvements that  together would have a measurable positive  effect on the business     
  21. 21. A new project ● however, the project manager (myself), doubling  as architect and developer, was mostly busy  with another project ● the other core developer was also busy with  other projects and tended to prefer to work  remotely ● plus, we didn't have an expert in the GUI  technology     
  22. 22. A new project ● progress on this supposedly very important  project was predictably slow    
  23. 23. Introducing Scrum ● I had experience with a "homegrown" agile  process and automated regression tests (in a  domain where such tests are still uncommon)  ● I was determined to introduce a "real" agile  development process    
  24. 24. Introducing Scrum ● I considered Extreme Programming, but feared  that management would not see the point  ● I also feared that we would never manage to  faithfully stick to all those "extreme" practices    
  25. 25. Introducing Scrum ● Scrum is more "management­oriented" ­ there  is nothing that doesn't make sense to a good  manager ● in particular in our case, Scrum and the basic  assumptions behind Scrum were a very good fit  for the management philosophy of the CEO    
  26. 26. Introducing Scrum ● the CEO had already played a Product Owner­ like role, including shielding developers from  direct "urgent" feature requests by stakeholders  ● the CEO had already come to value progress in  small steps and the ability to rapidly react to  market opportunities    
  27. 27. Introducing Scrum ● we invited Peter Stevens to introduce the  development team and in particular the CEO    to the key concepts of Scrum, and then officially  decided to use Scrum ● in October 2008 I took a Scrum Master class  with Jeff Sutherland ● I was determined to implement Scrum properly    
  28. 28. First steps ● Product: all internally developed software,  divided into subsystems ● Product Owner: CEO ● Scrum Master: myself ● Team: development staff including myself      
  29. 29. Lack of progress on “main” project ● the first three sprints were definitely “Scrum­Butt”  (but also an exercise in the “art of the possible”) ● we continued to work more or less like before,  until it was painfully obvious that progress on the  "main" project was far too slow  ● it is one thing to know that focus and collocation  are beneficial, it is another thing to make it  happen     
  30. 30. Sprint 1    
  31. 31. Sprint 2    
  32. 32. Sprint 3    
  33. 33. Impediments get removed key decisions in February 2009:  ● the CEO as the Product Owner saw that  insufficient capacity was partly to blame and  increased the budget ● I myself in my reincarnation as a Scrum Master  insisted on the developers working together in  the same room at least most of the time    
  34. 34. Collocation ● I promised the CEO 40% higher productivity if we  work together in an adequately equipped team  room (that was Jeff Sutherland's estimate)  ● collocated development (three days per week)  started in March 2009    
  35. 35. Team room    
  36. 36. View from team room :­)    
  37. 37. Sprint 4    
  38. 38. Sprint 4 adjusting estimates is not worth the effort –  in the end I decided to always use the original  estimates for my bookkeeping purposes    
  39. 39. Sprint 5    
  40. 40. Sprint 5 some features in the Sprint backlog were  changed – this is strongly discouraged in Scrum (note that we only track features, not tasks)    
  41. 41. Sprint 6    
  42. 42. Collocation ● comparing the three Sprints before and the three  Sprints after ­ partial! ­ collocation, average  velocity has actually doubled * * based on data as of 20.05.2009    
  43. 43. Collocation ● although there is one more full­time team  member there are still only two developers who  do most of the actual work ● there has been a genuine and substantial  improvement in productivity per developer, and  this has been recognized by everybody involved ● there are more factors involved, but 40% can  safely be attributed to collocation     
  44. 44. Collocation ● having the team work together in one room,  insisting on concentrated work and keeping  distractions away is the key for improving  efficiency and quality  ● close collaboration with users is another key  ingredient for success ● if you have read about Crystal, this will sound  familiar :­)    
  45. 45. Collocation Without collocation at least most of the time, you  are likely to suffer from all of the following: ● lack of commitment ● slowdown due to inefficient communication ● lack of discussion of design issues leading to  poor design choices (software development is  essentially design work at multiple levels ­ there  are a lot of opportunities for bad decisions)     
  46. 46. Bandwidth of communication if the three    people involved  had been working  in the same room  all this would have  taken less than   ten minutes    
  47. 47. Removal of further impediments ● one developer (“MaCa”) was and is critical for  rapid progress ● the dramatic improvement in productivity is to  some extent due to the optimization of the  whole environment for this key developer    
  48. 48. Removal of further impediments    
  49. 49. Project health ● the Product Owner/sponsor is happy with our  progress, and has great expectations for the  future ● morale is high – the team takes pride in the  quality of the design and in adopting  established professional practices, in particular  test and build automation      
  50. 50. Project health ● mind you this is a domain where automated  regression tests are still not mainstream –  indeed many would think that in our case  automated tests are just too much work or even  downright impossible ● kudos to Gojco Adzic for DbFit, which has been  a godsend for us ­ I don't know what we would  have done without it!     
  51. 51. “Something old, something new, something borrowed  and something blue” ● what I have described so far is more or less  standard Scrum (or Crystal) ● now comes the kanban part    
  52. 52. Kanban board ● in the first collocated Sprint I introduced a kanban  board in order to make our whole "value stream"  visible ● as a first approximation, you may think of this  kanban board as a standard Scrum story board  that is extended to the left to include steps to  prepare backlog items for development and          to the right to include the steps coming after    development until a feature is finally in production  
  53. 53. Kanban board    
  55. 55. Kanban board ● this kanban board allows me to visually control  the flow of all of our work ­ in particular: – I want to see where work "gets stuck" – I want to see if downstream steps risk getting  starved    
  56. 56. Kanban board ● note that there is a rough space limit on the  number of items in each column ● (I've cheated a bit, actually) ●  kanban experts take this a lot further and make  an art of getting the limits right    
  57. 57. Lean ● in Lean thinking there is an emphasis on speed,  on competing on speed ● the ideal is to get "from concept to cash" in a  rapid flow ● improving quality and decreasing cost are so to  speak side effects of this quest for speed  ● ask General Motors if it works :­)    
  58. 58. Lean ● in our case, the "concepts" are small features  and feature enhancements, normally estimated  at between 1 and 8 ideal person days of effort ● small or at least uniformly sized units of work  can help to improve throughput  ● in our case, "cash" is whatever benefit is  realized by the use of the feature    
  59. 59. Inventory ● at the risk of oversimplifying a little:  In Lean,  inventory is the enemy, is "waste" ● this is an interesting idea in the context of  software development:  what is our inventory? ● our inventory is features that have been thought  about and worked on, but are not yet in  production    
  60. 60. Inventory ● in particular, preparing a month's worth of  backlog items for development – as needed for  Sprint planning – means building up inventory ● I feared this would require a lot of effort and  would distract us from development ● it would be more in the spirit of Lean to prepare  each backlog item just in time for development    
  61. 61. Before Sprint planning meeting    
  62. 62. During Sprint    
  63. 63. Inventory ● as it turns out, towards the end of the Sprint it is  usually relatively easy to see how the items at  the top of the backlog should be implemented   ● this is due to the increase of knowledge during  the development of the previous features    
  64. 64. Inventory ● this can be compared to driving a car at night –   as one drives, the headlights always show the  next part of the road    
  65. 65. Inventory ● the monthly rhythm of the review and planning  meetings with our CEO has served us well  ● since building up the Sprint planning inventory  doesn't cost us much effort and since it is  usually (almost) entirely consumed at the end of  a Sprint we don't need to be too worried about  this inventory    
  66. 66. Inventory ● in fact, the monthly planning rhythm allows us to  concentrate on development for at least three  weeks in a row ● in our case this is probably more efficient     
  67. 67. Inventory ● remember though that we only track small  features and feature enhancements, not tasks ● features are decomposed into tasks just­in­time  – a second Sprint planning meeting by the book  for four weeks' worth of work would kill us :­( ● shorter iterations are not an option – our  Product Owner is the CEO, we have to keep the  overhead for him as small as possible    
  68. 68. Inventory ● much more serious are delays and inventory  further downstream ­ features that are already  developed, but not yet in production      
  69. 69. Inventory ● every day a “done” feature is not actually used  in production the business loses a day's worth  of benefit from using the feature ● perhaps more importantly, the developers ­ and  the Product Owner! ­ don't get any feedback  from production and may make bad decisions  based on false assumptions    
  70. 70. Cumulative flow diagram ● cumulative flow diagrams are a great way to  visualize the flow in a kanban system  ● I introduced a cumulative flow diagram at the  beginning of our second collocated Sprint      
  71. 71. Kanban bookkeeping     
  72. 72. Burndown:  DEVELOPED vs. INSTALLED    
  73. 73. Cumulative flow diagram Cumulative Flow Diagram 160 140 120 100 ESTIMATED IN PROGRESS 80 DEVELOPED INSTALLED 60 BEING USED 40 20 0 01.04.2009 06.04.2009 11.04.2009 16.04.2009 21.04.2009 26.04.2009 01.05.2009 06.05.2009 11.05.2009 16.05.2009    
  74. 74. Cumulative flow diagram ● it came as a slight shock to see how slowly  features move into production ● here is certainly plenty of room for improvement ● however, in cases where a set of small features  is only relevant as a whole it is natural for the  feature set to "build up" in a staging area such  as DEVELOPED before the set as a whole  moves into production      
  75. 75. Efficiency and effectiveness ● what ultimately matters to the sponsor is not  “requirements” or “features” but whether the  changes to the system have the desired effect  on the business (effectiveness) ● if features and feature enhancements move into  production fast enough (efficiency), the sponsor  and the developers have a chance to maximize  effectiveness based on feedback       
  76. 76. Efficiency and effectiveness I would like to conclude the main part of my  talk with a passage from  Extreme Programming Explained:       Embrace Change  by Kent Beck    
  77. 77. Learning to drive (1) “Extreme Programming explained” (1st edition) by Kent Beck, p. 27+28: [...] I jerked back to attention as the car hit the gravel. My mom (her courage now amazes me) gently got the car back straight on the road.      
  78. 78. Learning to drive (2) Then she actually taught me about driving.      
  79. 79. Learning to drive (3) “Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.”      
  80. 80. Learning to drive (4) This is the paradigm of XP. [...] The driver of a software project is the customer. [...] Our job as programmers is to give the customer a steering wheel and give them feedback about where we are on the road.      
  81. 81. Bonus Material: Crystal Clear ● Crystal Clear is a minimalist methodology for  small teams extracted by Alistair Cockburn  (remember: the best frameworks are extracted) ● The result of ten years of debriefing successful  small teams – originally for IBM  ● If you are trying to implement Scrum, you have  started to deliver good results, and everybody  on the project is happy, you are probably  already using it :­)    
  82. 82. Crystal Clear – favorite quotes “This is the methodology I never knew I was  already using.  [...] illuminates why the things I've  been doing work, and also why some of the things  I was doing didn't work.” Jeff Patton “Consultants can tell you what we are.  I think the  most accurate term would be 'Crystal'.”     Chris Matts
  83. 83. Crystal Clear – roles ● sponsor (corresponds to Product Owner –  depending on how Product Owner role is  implemented) ● at least one senior designer (often also  coordinating the project) ● team of designer­programmers collaborating  with expert users    
  84. 84. Crystal Clear – targeted properties ● frequent delivery ● reflective improvement ● osmotic communication ● personal safety (a basic level of trust) ● focus ● easy access to expert users ● technical environment with automated tests,  configuration management, and frequent  integration    
  85. 85. Crystal Clear in a nutshell (1) The lead designer and two to seven other developers      
  86. 86. Crystal Clear in a nutshell (2) in a large room or adjacent rooms,      
  87. 87. Crystal Clear in a nutshell (3) using information radiators such as whiteboards and flip charts,      
  88. 88. Crystal Clear in a nutshell (4) having easy access to expert users,      
  89. 89. Crystal Clear in a nutshell (5) distractions kept away,    
  90. 90. Crystal Clear in a nutshell (6) deliver running, tested, usable code to the users every month or two (quarterly at worst),      
  91. 91. Crystal Clear in a nutshell (7) reflecting and adjusting their working conventions periodically.      
  92. 92. Reading tips Agile Software Development and               Crystal Clear* by Alistair Cockburn and       Agile Project Management by Jim Highsmith –  arguably the best books on Scrum around –  after Ken Schwaber's writings of course :­) *chapter 1 is the most lighthearted and enchanting introduction to agile software development you can   imagine  
  93. 93. Reading tips Organizational Patterns of Agile Software  Development by Jim Coplien and Neil Harrison  – based on “empirical studies of about 100  organizations”, originally for Bell Laboratories Jim Coplien is one of the true thought leaders of  the agile movement (he seems to have a high  opinion of Scrum, by the way)          
  94. 94. Reading tips Lean Software Development and Implementing  Lean Software Development by Mary and Tom  Poppendieck – guess who wrote the  forewords :­) Scrumban – Essays on Kanban Systems for  Lean Software Development by Corey Ladas –  some very clever writing questioning  mainstream agile thinking    
  95. 95. Reading tips Scaling Lean & Agile Development by Craig  Larman and Bas Vodde – a very recent (2009)  book by solid agile practitioners with a deep  understanding of Lean and the application of  systems thinking and queueing theory –  cautioning against going overboard with  isolated Lean techniques (in particular kanban)    
  96. 96. Reading tips About Face – The Essentials of Interaction  Design by Alan Cooper et al.  the ideas in this book can help a lot to make  software development more effective (as  opposed to merely efficient) also have a look at Jeff Patton's blog:     
  97. 97. Questions?