It’s Back!

It feels good to be getting back into updating the blog as it’s been 3 years since I last posted. There were a few technical issues with jekyll to get around as the framework had change in a few minor ways. Explicitly referencing some of the plugins that are used to get them to work again, along with a minor markdown change that was causing the headers to display incorrectly. Now that everything is working onto the real meat: Agile.

Agile

At my current place of work we’ve been converting our previous process of development from something that resembles a waterfall method to a more agile approach. This has manifested itself in a lot of benefits: There has been more communication between development and quality assurance (QA). We’re becoming cognizant of process problems that were previously hidden away or attributed to other causes due to just putting our heads down and ‘doing as much as possible’. We’re getting rid of unecessary processes that were taking up QA time but didn’t have any demonstrable benefit to streamline the process. The biggest thing process-wise for me has been implementation of iterations. At first we started in the once every two-week type iteration, this continued for about 3 iterations, until we felt like with the way work was being prioritized and being shifted around week-to-week we couldn’t plan out past 1-week. We’ve now moved to a 1-week iteration period and are testing to see if it will work well.

Team Throughput and Idle Time

The biggest pain that seems to be coming to the surface is that QA appears to be backlogged the majority of the time. We have 3 testers, and 4 developers. We’ve implemented a ‘no developer can pickup additional work while QA is still finishing up something with your name on it’ rule. This is to try and get QA and development into a rythm where there is the same amount of working being completed across the teams and to prevent work items becoming backlogged. This however results in developers looking for work, but not being sure what is okay to work on. Some ideas have been thrown around to try and help the team move faster as a whole are: developers doing QA, looking for places where automation can be employed to help speed things up on the QA side, or writing whole new sets of tests in newer portions of the codebase. One of our biggest challenges is that the language our ‘legacy’ system is written in doesn’t facilitate a TDD approach at all, so reducing QA fear of bugs entering the software is difficult without a considerable manual testing effort. Writing new tests in the newer portion of the codebase also doesn’t help the legacy area which is where the most time is expended already.

Iteration Prep

Another pain point has been caused on the planning side. Developers feeling like the items they are working on not being valuable as a whole because they aren’t priotized properly. Items are being put into the iteration planning even though they are blocked by outside teams and can’t be started at all. One of the ideas here was to make sure that we are having requirements meetings before a feature is put into iteration planning so we can get a better idea of how to approach the feature request or bug. This type of planning helps iron out issues and takes mostly all developer time, rather than requiring a lot of QA input. My thought is that if we are doing more planning up front that will tie up developers longer to give QA more time to work on finishing the manual testing portions while we dig into requirements for upcoming features.

Conclusion

Overall my experiences with Agile have been mostly positive, even though there’s a lot of contension going on right now it feels better to be in constant communication and people feel approachable. It feels like we’re going through a rocky patch while we try to figure out how to best make this approach fit for our team, but the benefits are also very apparent.