US Task forcePlanning
The team decides that several people work on the same US in order to meet all the DoD criteria in the time of the Sprint
The concept of US Task Force in Agile teams
Usually, Teams are organized as follow:
- during the running of the Sprint, a Developer grabs a User Story (US) from the Sprint Backlog and starts implementing it
- at Daily Scrum Meeting (DSM) time, each Developer share about his situation and concerns
While DSM is widely and easily adopted [Stray 2017], when attending the DSM, everyone is waiting for his turn to speak and listens patiently about other’s situation without being concerned since most of the time the US are “INVEST”, thus “Isolated” from other US.
This results in:
- a poor collaboration
- a parcel knowledge of the domain and what others are doing
- Information shared is not perceived as relevant, particularly due to diversity in roles, tasks and seniority [Stray 2018]
- simple individual reporting [Sutherland 2014]
Even if nowadays, the talking stick is eventually replaced with a ball or a mascot to make it more fun [Ratcliffe 2012] [van Vliet 2016], having fun turns boring...In a genuine rugby scrum, there is that much confusion that a talking stick, usually involved in group discussions to regulate sharing [Priestley 2015], is necessary to let everyone equal opportunity to talk [Linders 2016].
What has happened to this rugby spirit? People are desperately trying to energize it with tips & tricks [Sutherland 2014] [Yip 2016][Ratcliffe 2012] [van Vliet 2016] but nothing happens: less than 45% of DSM attendees find it positive [Stray 2017].
One of the causes lay certainly in the roots of Scrum [Sutherland 2011][Sutherland 2014] that are described in [Takeuchi 1986]: building everything at the same time with organization like type C.
As a reminder, the Scrum guide tells the team are empowered to set their organization up [Schwaber 2020] but it appears
- Developers have a tendency to work alone behind their screen and don’t go to the field where End Users are
- Quality is mainly focused on functional suitability while Non Functional Requirements (NFR) are neglected most of the time
- Documentation is not always updated
- End-to-end Testing is left to someone else once the whole product increment is available
- Test automation is limited to unit testing (eventually in TDD mode) while ATDD could be done
There are many other antipatterns Teams may adopt unwittingly that would worsen the situation, some of them are systemic (e.g. Component Teams)
This situation leads to increased WIP (Work In Progress) because once the code is delivered, all those tasks are still left to do. In the best case, from an End User point of view, defects will be raised and rework will have to be done. This impacts the First Pass Yield, it also generates fixing costs that are much bigger expenses since NFR often embed some Architecturally Significant Requirements (ASR) [Chen 2013] [Moustier 2019-1] that usually require deep refactoring. Moreover, this also leads to a type A organization which is precisely the Waterfall model!
To avoid the “Done” fallacy, a proper Definition of Done (DoD) should be defined. This DoD should then embed such criteria that can be partially embraced with the “Four Quadrants of Testing” [Marick 2003][Bach 2014][Crispin 2021] in order to have a Product Increment “potentially deliverable to the Customers” [Schwaber 2020].
Unfortunately, this generates a lot of workload that makes too much for a single person during one Sprint. Here begins the right question: how can a deliverable US be done under those constraints?
Google’s SRE provides a first option: limiting development of new features to 50% and letting Developers work on Ops matters, such as the items listed above, the rest of the time [Beyer 2016]. This option puts a lot of required skills on the person that would build the US, but it poorly fixes the DSM issue.
Another option is to gather several people on a single US and let the Team actually organize about the US. Again, this type of organization would focus on the flow (which benefits the WIP!) and not a 100% resource utilization paradigm [Kniberg 2014]. Under those circumstances, the Team builds a US Task Force and Mob Programming combined with Living Documentation, ATDD and TDD could also be an option.
When a whole Team manages to work on a mission, alerts from raised issues become most visible and Andons interrupt part of the Team to enable fast resolution. Those Andon may be raised at any time and eventually raised at DSM time to share the concern at a higher level. In this configuration, it is easy to figure out that the Team is able to share a quick standpoint on the running mission and not just some individual report on isolated matters that are not significant for another Dev.
If the current US would mobilize not every Team member at 100%, instead of being idle, they could do some background tasks. This benefits both sustainability and technical debt with activities such as 5S on existing tests, code or documentation. These “background guys” would eventually prepare the next Sprint in Sprint Refinements.
Impact of US Task Force on the testing maturity
Undoubtedly, if the Team is able to run multiple kinds of tests on a US thanks to the task force, then both testing maturity and product quality are inevitably improved.
To help this 360 degree on testing, the Team should set a “3 Amigos” workshop in refinement with eventually more than three chaps to make sure the US have been “fully” grabbed. The US refinement should then be completed with the Testing Quadrants; involved people will then propose activities that should address the four parts [Crispin 2021].
Moreover, if the documentation update is part of the development activity, then it reduces the chance to have discrepancies with the code and therefore improve the overall quality of the product.
If the US embeds too much for a Sprint, then a US splitting should be performed [Larman 2010][Lawrence 2012] [Le Lan 2018][Moustier 2020]. The splitting must be consistent with tests to be handled, reviewing a document whose update is postponed to another US doesn’t make sense at all! Eventually, if the split leads to an uncompleted US, the delivered artifact will be deployed in Dark Launch mode.
Agilitest’s standpoint on US Task Force
When it comes to test script automation, if a whole Team is involved on a US then the scripts can be part of the US within the Sprint. The delivered scripts can then be executed from the CI Toolchain onto which Agilitest can be easily plugged.
To ease testing and make it type C as per the scrum spirit, it is most useful to use practices that enable building everything at the same time. Specification by Example and ATDD are among those. Agilitest encourages this kind of practice since it will help to
- understand what should be done
- what should be tested
- what is OK
- where regressions would appear
- reduce the WIP and Cost of Delays [Reinertsen 2009]
To discover the whole set of practices, click here.
To go further
- [Beyer 2016] : Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy - « Site Reliability Engineering: How Google Runs Production Systems » - O’Reilly Media - 2016 - ISBN-13 : 978-1491929124 - https://landing.google.com/sre/sre-book/toc/index.html
- [Chen 2013] : Lianping Chen & Muhammad Ali Babar & Bashar Nuseibeh - FEB 2013 - “Characterizing Architecturally Significant Requirements” - https://www.researchgate.net/publication/255569055_Characterizing_Architecturally_Significant_Requirements
- [Crispin 2021] : Lisa Crispin & Janet Gregory - JAN 2021 - “Applying the Agile Testing Quadrants to Continuous Delivery and DevOps Culture – Part 2 of 2“ - https://agiletester.ca/applying-the-agile-testing-quadrants-to-continuous-delivery-and-devops-culture-part-2-of-2/
- [Kniberg 2014] : Henrik Kniberg - 2014 - “The resource utilization trap“ - https://www.youtube.com/watch?v=CostXs2p6r0
- [Larman 2010] : Craig Larman, Bas Vodde - « Practices for Scaling Lean & Agile Development - Large, Multisite, and Offshore Product Development with Large-Scale Scrum » - Addison-Wesley - 2010 - ISBN-13: 978-0-321-63640-9
- [Le Lan 2018] : Olivier Le Lan - MAR/2018 - « SPLIT POKER : Un Jeu de cartes pour les Product Owners et équipes agiles ! » - https://www.soat.fr/publications/split-poker-soat
- [Linders 2016] : Ben Linders - NOV 2016 - “Non-verbal Exercises for Agile Retrospectives” - https://www.benlinders.com/2016/non-verbal-exercises-agile-retrospectives/
- [Marick 2003] : Brian Marick - « Agile testing directions : tests and examples » - 22/AOU/2003 - http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
- [Moustier 2019-1] : Christophe Moustier – JUN 2019 – « Le test en mode agile » - ISBN 978-2-409-01943-2
- [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7[Bach 2014] : James Bach - « The Real Agile Testing Quadrant » - SEP/2014 - http://www.developsense.com/presentations/2014-06-Dublin-RSTAgileTesting.pdf
- [Priestley 2015] : David Priestley - JAN 2015 - “Talking Stick” - https://ventureteambuilding.co.uk/talking-stick/#.YQkFSkCxXIU
- [Ratcliffe 2012] : Lindsay Ratcliffe & Marc McNeill - “Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous” - isbn:9780321804815
- [Reinertsen 2009] : Donald G. Reinertsen – 2009 - « The principles of product development flow: second generation lean product development » - ISBN 978-1-935401-00-1
- [Schwaber 2020] : Ken Schwaber et Jeff Sutherland - « The Scrum Guide : The Definitive Guide to Scrum: The Rules of the Game » - NOV 2020 - https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf or https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
- [Stray 2017] : Viktoria Gulliksen Stray & Nils Brede Moe & Gunnar R. Bergersen - APR 2017 - “Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams” - https://www.researchgate.net/publication/316114233_Are_Daily_Stand-up_Meetings_Valuable_A_Survey_of_Developers_in_Software_Teams
- [Stray 2018] : Viktoria Gulliksen Stray & Nils Brede Moe & Dag I.K. Sjøberg - OCT 2018 - “Daily Stand-Up Meetings - Start Breaking the Rules” - doi:10.1109/MS.2018.2875988 or https://arxiv.org/ftp/arxiv/papers/1808/1808.07650.pdf
- [Sutherland 2011] : Jeff Sutherland - 2011 - “Takeuchi and Nonaka: The Roots of Scrum” - https://www.scruminc.com/takeuchi-and-nonaka-roots-of-scrum/
- [Sutherland 2014] : Jeff Sutherland - SEP 2014 - “Scrum: The Art of Doing Twice the Work in Half the Time” - isbn:9780385346467
- [Sutherland 2015] : Jeff Sutherland - 2015 - “The Origin of The Daily Stand-up” - https://www.linkedin.com/pulse/20140926150354-136414-the-origin-of-the-daily-stand-up/
- [Takeuchi 1986] : Hirotaka Takeuchi et Ikujiro Nonaka - JAN 1986 - “The New New Product Development Game “ - https://hbr.org/1986/01/the-new-new-product-development-game
- [van Vliet 2016] : Matthijs van Vliet - JUN 2016 - “How to improve the Daily Scrum?” - https://agilecockpit.com/blog/improving-daily-scrum/
- [Yip 2016] : Jason Yip - FEB 2016 - “It's Not Just Standing Up: Patterns for Daily Standup Meetings” - https://martinfowler.com/articles/itsNotJustStandingUp.html