US Task force

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.

‍