Pragmatic agile LESS 2013


Published on

How to pragmatically scale agile in oder to gain benefits

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Pragmatic agile LESS 2013

  1. 1. Pragmatic Agile! Maarit Laanti, 04-Dec-2013!
  2. 2. Outline! 1.  2.  3.  4.  Background! What was done?! How does it work in practice?! Benefits measured by customer!
  3. 3. Background! •  Although there exists some reports how agile methods have been used to improve quality as number of lower amount of errors produced, or how adoption of certain agile practice, such as TDD, has improved quality, research is still lacking reports on radical improvements and how those were made.! •  I was working as researcher with co-operation a team that took over not-so-successful agile adoption, i.e. Water-Scrum-Fall problem! Water Image © Graphics! Scrum Fall
  4. 4. Why I was interested in doing this research?! Feedback! -  How do we know if agile really improves?! -  How can we apply that in practice?! !
  5. 5. And although there exists known ways to overcome water-scrum-fall problem…! Scaled  Agile  Framework™  Big  Picture We have experience reports, but lacking research reports! •  How practically applied in different environments! •  What is the outcome, or impact?!
  6. 6. WHAT WAS DONE?!
  7. 7. What is this so-called Pragmatic Agile?! •  A set of known, working agile tools for developing business IT-solutions! !
  8. 8. You need to look the whole chain, not just Scrum in development team! •  Focus  on  quick  Return  of  Investment  (ROI)     •  Without  raising  total  cost  of  ownership  (TCO)  
  9. 9. Research context!     Challenges Solution under test How  this  is  supposed  to   help Project  is  large  and   complex   Specifying  the  concepts  in   a  dedicated  design  and   prototyping  cycle   Early  feedback  helps  to   figure  out  which  of  the   proposed  soluJons  are   feasible   Making a delivery estimate for a complex large project Delivery in increments Future estimates are based on earlier deliveries Time-­‐to  market  pressure   Self-­‐organizing,   empowered  teams   Eliminate  the  waste  of   waiJng  and  not  taking   acJon   Agile  methodology   adopJon  failed   Introduce  concrete   Ensure  guidance,  best   PragmaJc  Agile  Toolbox  for   pracJces,  and   the  teams   accountability        
  10. 10. The Pragmatic Agile Model that was taken under test! !
  12. 12. New kind of development contract and agreement! •  Built on TRUST between developer and customer! •  Frame agreement with small agile provider, which offers the whole solution from business concepting to deployment! •  The agreement specifies only qualitative metrics ! –  In difference to normal time + material-based contracts! •  Customer’s and provider’s development teams working jointly as one team! •  The contract is renewed every three months (quartile-based), optimizing the roles and responsibilities needed for the kind of development work due!
  13. 13. What was promised?! •  The team follows real agile way-of-working, i.e. the priorities can change based on business needs! •  Empowered and self-directing hero team as development team! •  New kind of visibility and predictability into the progress! •  Use of automation where-ever and when ever feasible! •  Advance the quality into a completely new level! •  High sense of responsibility and the right attitude! •  Control over the total cost of ownership!
  14. 14. Pragmatic model! IT   Needs  &     Requirements   Resources   Infrastructure   Technology   Solu&on   design   Architecture   Releases   Scrum   Quality  &   deployment   Enterprise   Architecture   Architecture   ProducJon   Business  
  15. 15. CAPO = Concepting, Architecting, Prototyping, Operative model ! BUSINESS! Design! UI! Proto! Concept! Web dev! CMS dev! Testing! Architecture! Operational Process! Content! BUSINESS! CAPO! DEVELOPMENT! CONTENT! TESTING & UAT!
  16. 16. The Guiding Principles of Hero-team approach! 1.  Modeling solutions and architecture simultaneously: ! –  Hero team has strong competences in solution creation and architecture co-located, in same team and same premises. It clarifies the business needs and prepares technical solutions, which are then put to product backlog for implementation. It optimizes the solutions as part of the solution creation process. ! 2.  From prototype to implementation: ! –  HTML5-apprearance, CSS-style quides, Javascripts, and graphics are created in CAPO pre-sprint. Hero Team turns prototype implementation to real system implementation.! 3.  Features implemented: ! –  Hero Team implements directly deployable features from business requirements (Java-implementation + CMSintegration) with common responsibilities, and common tools. !
  17. 17. The Guiding Principles of Hero-team approach! ! à  Seamless cycles: ! –  from solution concepting via prototypes to operatively optimized ready system ! à Seamless functional quality:! –  Concept designer is co-responsible with the developer for the product end-quality (sign-off before acceptance testing). ! –  Hero Team is responsible for test automation and code reviews. !
  18. 18. Less people but bigger roles ! •  When people are working in small but dedicated team means they can take larger areas of responsibility – narrow but specialized roles promote the use of experts in multiple areas, and thus larger teams ! •  When people are given larger areas of responsibility they can more easily build a holistic understanding – this removes the need of defining accurate authority limits! •  The smaller the team is the fewer the interfaces are thus reducing the overhead of conversation – this ensures communication is easy and co-operation is seamless!
  19. 19. How the promise was kept?! •  Customer is fully integrated into the process! •  Concepting, architecture and prototyping in pre-sprint, that is seamlessly feeding development sprint! •  Empowered, self-directing feature teams s development teams (Hero-teams)! •  Test-first development from concepting to development! •  The use of heavy automation in concepting, deployment and testing! BUSINESS   CAPO   DEVELOPMENT   CONTENT   TESTING  &  UAT  
  21. 21. End status! 1.  Ability to develop bigger items with smaller group faster and with better quality (see Figure 5)! 2.  End-result is fully testable and design-debt is minimized (note – compare to traditional understanding of agile methods) ! 3.  More even velocity and more accurate estimations ! 4.  Business guidance of agile development is full-functional: business requirements in and working functionalities out! 5.  What is measured is visible to everybody via information radiators!
  22. 22. 1. Team size to 1/4th of original, with more delivered functionality ! •  Although the number of people in the project is only 1/3 of what is was before, the teams are capable of producing more functionality than before! !
  23. 23. Time allocated to development per person has increased! •  Time that development team can contribute to sprint has increased 15%! !
  24. 24. Time used by developer per backlog item! •  Development team that works partly with Hero-team spend 60% less time with business case implementation than before; the size of items are of same range as before ! ! !
  25. 25. Technical improvements! •  Build and automatic test time is one tenth of what before! •  Enabling “build on commit”! •  Largely manual environment was automated! !
  26. 26. Visibility! •  What gets measured is visible to everyone!
  27. 27. Summary! •  The end-product is dependent on the input received to development cycle – seamless co-operation ensures efficiency and quality! •  Clear responsibilities with well-defined Definitions-of-done and seamless handoffs ensure that the development team is focusing on right things and their work is not interrupted in the middle of the sprint cycle! •  The customers no longer need to buy large projects with several but narrow roles but can focus on generalists-type of persons with many competences who then can together create a working system from business requirements efficiently!
  28. 28. ☐ Clearly defined product owner (PO) ☐ PO is dedicated to the project and easily available to the team ☐ PO is empowered and has knowledge to prioritize ☐ PO has direct contact with team ☐ PO has direct contact with stakeholders Pragmatic Agile check list ☐ PO maintains a product backlog (PBL) ☐ PBL is prioritized by business value ☐ PBL is visible to the team ☐ Daily scrum (max 15 minutes) takes places daily at the same time ☐ Whole team participates ☐ Impediments surface and are dealt with ☐ Top PBL items are well understood and ready for development ☐ Grooming takes place before sprint planning ☐ Bizcases have been approved ☐ Architectural implications to other systems have been agreed ☐ Prototyping for new feature have been done an verified ☐ Items have been estimated by the team ☐ Items are small enough to fit in a sprint ☐ Clearly defined scrum master (SCM) who is not PO ☐ Team knows top impediments ☐ SCM works actively to solve impediments ☐ Escalated to mgmt. when team cannot solve ☐ Team understands architecture and goals of surrounding systems ☐ Team receives architectural guidance when needed ☐ Team can bring up architectural issues and proposals ☐ Issues and proposals are managed transparently ☐ Team has sprint planning meetings ☐ PO brings an up-to-date PBL with well-understood items ☐ Whole team and PO participates ☐ Meeting is not longer than 4 hours ☐ Team decides what fits into the sprint ☐ Team has a visible sprint backlog and a burndown chart ☐ All code is automatically tested ☐ Continuous integration is used ☐ Unit tests are written and test coverage is followed ☐ Acceptance tests are automated and created based on user stories ☐ Demos are held after each sprint before the next one starts ☐ PO and the required stakeholders participate ☐ Useful feedback is received ☐ Retrospective takes place after each sprint ☐ The entire team including the PO participates ☐ Results in improvement proposals and some get implemented ☐ Team has a release burndown chart ☐ Teams estimate in story points rather than hours ☐ Team velocity is measured and used for release planning ☐ Sprints of max 4 weeks ☐ Thee sprints always end on time ☐ Team usually finished most items ☐ Team is not disrupted by other tasks ☐ Team possesses all skills required for completing items THIS IS WHAT COUNTS: POSITIVE INDICATORS: ☐ Team delivers working, tested software after each iteration ☐ Team delivers what the business needs most ☐ Team is continuously improving its practices ☐ Team is having fun and is being trusted by stakeholders ☐ Work generally takes place within the limits of normal working hours ☐ The atmosphere is open for discussing, experimenting and criticizing