Pragmatic Agile!

Maarit Laanti, 04-Dec-2013!

Outline!

1.  Background!2.  What was done?!3.  How does it work in practice?!4.  Benefits measured by customer!

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 Scrum Fall Image © Graphics Factory.com!

Why I was interested in doing this research?!

Feedback!-  How do we know if agile really

improves?!-  How can we apply that in

practice?!!

And although there exists known ways to overcome water-scrum-fall problem…!

We have experience reports, but lacking research reports!•  How practically applied in

different environments!•  What is the outcome, or

impact?!

Scaled  Agile  Framework™  Big  Picture

WHAT WAS DONE?!

What is this so-called Pragmatic Agile?!

•  A set of known, working agile tools for developing business IT-solutions!

!

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)  

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  PragmaJc  Agile  Toolbox  for  the  teams  

Ensure  guidance,  best  pracJces,  and  accountability  

The Pragmatic Agile Model that was taken under test!

!

HOW DOES IT WORK IN PRACTICE?!

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!

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!

Pragmatic model!

Resources  Infrastructure  Technology  

Solu&on  design   Architecture  

Scrum   Quality  &  deployment  

Needs  &    Requirements  

Business  

Prod

ucJo

n  

IT  

Enterprise  Architecture  

Architecture  

Releases  

CAPO = Concepting, Architecting, Prototyping, Operative model !

BUSINESS! Design! UI! Concept!Architecture!

Web dev!

Operational Process!

Proto! CMS dev!

Content!

Testing!

BUSINESS! CAPO! DEVELOPMENT! CONTENT! TESTING & UAT!

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 + CMS-integration) with common responsibilities, and common tools. !

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. !

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!

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  

BENEFITS MEASURED BY CUSTOMER!

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!

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!

!

Time allocated to development per person has increased!

•  Time that development team can contribute to sprint has increased 15%!

!

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 !

!

!

Technical improvements!

•  Build and automatic test time is one tenth of what before!•  Enabling “build on commit”!•  Largely manual environment was automated!

!

Visibility!

•  What gets measured is visible to everyone!

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!

THIS IS WHAT COUNTS: ☐ Team delivers working, tested software after each iteration ☐ Team delivers what the business needs most ☐ Team is continuously improving its practices

☐ 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

☐ PO maintains a product backlog (PBL) ☐ PBL is prioritized by business value ☐ PBL is visible to the team

☐ 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

☐ 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

☐ Team has a release burndown chart ☐ Teams estimate in story points rather than hours ☐ Team velocity is measured and used for release planning

POSITIVE INDICATORS: ☐ 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

Pragmatic Agile check list

☐ Daily scrum (max 15 minutes) takes places daily at the same time ☐ Whole team participates ☐ Impediments surface and are dealt with

☐ 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

☐ 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

☐ 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