One of the key pillars of Agile is to drive effective interactions between the right individuals. We want to structure teams that are able to deliver value in a complex environment. Since we believe face-to-face interaction amongst co-located individuals is the best medium of communication, we strive to create co-located teams in which all participants are delivering value, especially for our tough features/initiatives, if not all of our work.
We believe in focusing development teams on “Working Software” or preferably “Working Tested Software” or even “Working Tested and Quality Software”. We show developers and testers the economic sense of maximizing testing during the build cycle.
This is all very rational. People should be convinced and take action. So how come it is so rare to see real, continuously evolving “Working Tested and Quality Software” developed by high-performance collaborative teams of developers and testers out there?
…Because behavior change is hard. As the Heath brothers write in their best-selling book Switch – behavior change comes from the emotional mind, not from the rational mind. They equate our emotional mind to an elephant and the rational mind to a rider trying to direct that elephant down a path. Not a trivial task. With this picture in mind, nobody should be surprised to see Scrum “teams” which look more like a collection of individuals forced together and trying to do things the old-fashioned way while displaying some compatibility with the new Scrum language. This is where flawed situations evolve: developers take on stories for which there’s simply no capacity to test during the sprint; teams plan tasks because planning end-to-end stories is too tough for them; or limited testing is done during the sprint but most of the real testing feedback arrives much later.
In order to help developers and testers collaborate within and between Agile teams, we need to find techniques that “shape the path” – nudge people towards a more collaborative plan and execution mode and build that as a habit. Kanban practitioners will tell you that limiting Work in Progress is such a technique. Telling a team to limit the amount of work they can have in progress at any point in time will signal to the team, “Enough. We have too much on our plate. Let’s pause while we finish processing what we have”. This gets team members thinking about how they can help each other finish something before they, as a team, have the capacity to start the next thing.
I’m often invited to talk about Kanban with Scrum practitioners. And I ask them which of the Scrum practices achieve a similar goal. Most of the time, they don’t have a clue what I’m talking about. And then I describe the Scrum Sprint/Iteration Planning as a work in progress limit aimed at exactly the same intent – collaboration towards a small but solid increment of “Working Quality Software”.
You see – Sprint Planning is about figuring out your focus as a team for the next sprint, not just what you are committing to and bringing into your Sprint Backlog, but also what you are NOT bringing into your Sprint Backlog. Once the Sprint Backlog is established, it should be where everybody in the team pulls work from during the sprint. And if you’re done with your natural/easy contribution for the Sprint Backlog – e.g. you’re an iOS developer and you finished the iOS-side tasks for the stories in the Sprint Backlog – you should look for ways to contribute to whatever’s still not completed in the Sprint Backlog, even if it challenges your comfort zone. Even if it means doing some work to help others which would be less efficient than taking on a new iOS task related to some work that’s deeper in the Product Backlog.
Done correctly, Sprint Planning will surface capacity mismatches, bottlenecks and other painful scenarios. A good Scrum Master will guide the team through the process of figuring out how to create a plan that maximizes value delivered. A great Scrum Master will help the team improve in the future through addressing the bottleneck identified during planning.
The same thinking applies at a larger scale. When several teams are working together on a project/product/solution (think an “Agile Release Train” if using the language of the Scaled Agile Framework) they will have a similar struggle to come up with a “Release Plan” or “Program Increment Plan”. With some help, they will channel this struggle in identifying and dealing with their program-level bottlenecks.
Employing “Agile Testing” techniques, such as figuring out the Test Automation Pyramid strategy, trying out Test-First (ATDD/BDD) and Continuous Integration should be the next move. As this is a tough stage for both developers and testers, one that will challenge their comfort zone, the role of leaders is to clear up the new path. An example – make sure teams have tools that are both dev AND tester friendly. Tools that people are keen to master. Tools they will be proud to put on their CV/LinkedIn skills list. (Good luck with trying to get a Java developer to write automation in a record & play tool with a scripting tool that a VB developer would call primitive…). Speaking of tools, download my latest whitepaper for an in-depth analysis on how to Expand Quality into your Build Cycle
The painful experience of struggling to agree on a balanced and effective Sprint/Program Increment Backlog can be the spark for a real pivot in the performance of the team, program, or organization. Could even be the “One ring that binds them”