Why I was interested in doing this research?!
- How do we know if agile really
- How can we apply that in
And although there exists known ways to overcome
Scaled Agile Framework™ Big Picture
We have experience reports,
but lacking research reports!
• How practically applied in
• What is the outcome, or
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
Solution under test
Making a delivery
a complex large project
Delivery in increments
Future estimates are
on earlier deliveries
The Pragmatic Agile Model that was taken under test!
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 speciﬁes only qualitative metrics !
– In difference to normal time + material-based contracts!
• Customer’s and provider’s development teams working jointly as
• 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!
CAPO = Concepting, Architecting, Prototyping,
Operative model !
Web dev! CMS dev! Testing!
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
clariﬁes 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: !
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. !
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
deﬁning 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
• Test-ﬁrst development from concepting to development!
• The use of heavy automation in concepting, deployment and testing!
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
• 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
Time allocated to development per person has
• Time that development team can contribute to sprint has increased
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 !
• Build and automatic test time is one tenth of what before!
• Enabling “build on commit”!
• Largely manual environment was automated!
• What gets measured is visible to everyone!
• The end-product is dependent on the input received to development
cycle – seamless co-operation ensures efﬁciency and quality!
• Clear responsibilities with well-deﬁned Deﬁnitions-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
• 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 efﬁciently!
☐ 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:
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