The Open Secret of Agile Success

People move to Agile, go through the required training, and start working on projects. After a period of time, if you ask any team member, “What exactly is Agile?” he or she will start talking about Scrum ceremonies, embracing change, shorter feedback cycles, etc. Even after implementing all these aspects, you’ll find issues in that project.

Why?

One of the most basic issue remains – people still continue to work in silos, even in Agile teams. You may find close collaboration within the developer or tester community, but if you ask how exactly developers and testers are collaborating together, you may find that people are clueless.

Some teams still work in a mini-waterfall fashion and term it Agile. For example, consider a typical team whose members follow all the Scrum practices. However, the developers work during the first part of the week on the user-stories and then hand them over to the testers by end of week. From Monday onwards, the testers perform testing while the developers wait for bugs and fix them as and when they are raised.

If you check all these anti-patterns, one thing is obviously common – team is not collaborating together for Sprint success. They still work in a siloed fashion and have a “developer vs. testers” mindset.

I personally feel very strongly against it. Irrespective of the ceremonies followed or the flavour of Agile, more than half the battle is won if a team believes in the idea of “How can I help you?” and then help each other in reaching a Sprint goal.

You may say, “This is good in theory, but in practice, how can team members really collaborate?”

Here are some ways in which testers and developers can help each other:

• The most basic way that developers can help testers is by writing tests. Any application without automated tests is an application with lots of technical debt. Then those regression tests have to be manual, which compounds the workload of testers.
• A developer and tester should pair up to define the test cases for the user-story together. While discussing those test cases, it’s important to focus on the basic idea of test pyramid (i.e., 80% of tests should be covered with unit and integration tests). Only 10% of tests should be covered with functional tests, and the remaining 10% of tests can be manual.
• At this time of pairing, developers can suggest what all test cases can be implemented through automated unit and integration tests. The remaining 10% of tests can be automated functional tests.
• A developer should perform the checking part of testing (i.e., developed user-story meets the functional acceptance criteria). So when the developer says “I am done developing the functionality,” it should mean that the developed functionality meets all the test cases discussed at the beginning. The tester can then focus on the exploratory part of testing.
• While doing that task, the developer should write the required automated tests as well.
• When a developer says, “I am done with the development of the user-story,” the tester can log onto the developer’s machine and check if there are any glaring mistakes or bugs in the functionality. If there are bugs, then the developer can go back and start fixing those issues instead of getting into a cycle full of waste (i.e., developer pushes the code to repository, then CI build runs, which creates executable and deploys it on the test environment; the tester does the required data setup, identify bugs, logs bugs into bug tracking system; then repeat over and over again as and when the developer fixes the defects)

Developers can help the testers technically by setting up the required testing frameworks and infrastructure.

These are some of the fundamental ways in which developers and testers can help each other. But again, it’s just a small list. If you believe in the philosophy of “How can I help you,” then you’ll find ways to help each other.

I find that collaboration and helping each other is the basic mantra of success for any Agile team. Obviously there are other ways in which Agile teams can be successful, but this one is implicit. This is fundamental tenet of working in Agile.