Quality practices for Agile projects, a different perspective

Almost everything has evolved, reshaped and been taken to a different level in software development. It’s highly likely that we are no more approaching the product development/software development the same way that we would have been 10 years back. A lot of enterprises embraced the Agile movement that guided and emphasized the left over right.

At a high level, we are developing in short cycles, adding value in continuously, demonstrating value addition to the stakeholders, being receptive to their candid feedback.

That being the drive at high level, internal engineering practices went thru vivid changes notably

Silo functional team members vs cross functional team members

Managers planning vs whole team planning games

Weekly status reports vs daily standups

PUSH vs PUSH work units

Large big bang release vs shorter incremental releases and supporting practices

UAT testing at the end vs continuous usability testing

One Performance at the end vs continuous performance testing

and so on..

Plenty of changes have been forced at the engineering level, these are not mere changes in terminologies and ceremonies but require significant shift in mindset.

While there are plenty of motivation to transform the teams and help adopt Agile practices, most of them tend to be focusing on developer practices such as Whole team planning, Test Driven Development, Simple design, Pair programming, Continuous Integration, Continuous delivery etc, where do the Quality engineering practices fit in? no more specialist testers, testers learn to develop code, do developers learn those needed testing skills? What do we do to prevent bugs, detect bugs early in the cycle and how do we transform those traditional quality engineering practices into Agile, what would be the role of a tester in an Agile team..many more questions..

If you have questions somewhere along the lines, please read Agile Testing by Janet Gregory. They talk about a lot of good practices can be adopted by Agile teams to build quality in.

Amongst many great thoughts, one of the most interesting factor is that Quality != Testing

They remind the Underlined goal that ultimately we need to make sure our implementation meets our intention which meets the business need on a continuous basis.

Q

This is a wonderful goal, how do we accomplish that..looks like we need 360 degree check on everything we do? How can we do this with every sprint?

Further reading on that book will guide us towards achieving this goal. However, some highlights that I like

Quality is about making sure that the team shares common understanding about the problem space. Team collaboration, ask right questions to the PO and understands before committing. This is something not new, what quality has to do here? Correct question but the emphasis here is to think beyond a story during planning, think like an eco-system and how this little story could affect the eco system, think like this little story is part of the bigger puzzle board and the importance of making it right, think about chain reactions that this little change could trigger and try to identify those end-user workflows that this story contributes or affects and hence derive those testing scenarios. So at the end of the planning meeting, the entire team would have talked about the story, especially, beyond design and coding, understood how an end-user’s action could cross this functionality, what an end-user would do before and after and essentially help the whole team to understand the problem space. When time comes, it’s highly likely that someone will write code and someone else might write tests but towards the same goal. Potentially, tests can be designed, written even before the code is ready. Upfront Test design and test case development could potentially help the developer and prevent bugs. Chances of finishing the story with desired quality within the sprint is high rather than deferring the test automation to the subsequent sprint. Of course, Automation plays a role here but Automation with appropriate intend plays a greater role.

These are partly my takes from that book from Quadrant 2. There are other Quadrants

Quad 3 – talks more about the importance of applying quality practices from Customer/end-user perspective and asking hard questions to your product

Quad 4 – talks about how Tools and technologies helps to apply quality practices from customer/end-user perspective

We started practicing Quadrant 2 in some of our projects and seeing great value..

Advertisements

One thought on “Quality practices for Agile projects, a different perspective

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s