Transitioning to agile – a journey worth taking

Like many testers in our industry, I was dragged kicking and screaming into Agile. I had heard horror stories of how it does not work. There are no specs to follow, development is done by the seat of your pants and everything is done all willy-nilly.

Our R&D organization went through a major re-orging period. It was decided that we would restructure ourselves after the Spotify model. We would now have tribes, squads, chapters, and we would have everyone become specialists in their particular domain and technology areas. Needless to say this transition was scary, confusing, difficult, worrisome and most of all unknown.

We were now going to become Agile.

agile manifesto

Agile eh? Less focus on process and tools? But we have so much of that!  Less focus on documentation?  But we do so much of that and what we create is awesome! Less stringent focus on contracts and plans but but…

Our R&D organization was the epitome of what a waterfall development environment was. We were the Niagara Falls or the Victoria Falls. We were the poster child.

niagara_falls

We worked in gates, each stage (gate) of the SDLC was performed, signed off on, and then transitioning to the next stage with a very heavy testing phase as one of the last gates in our process. How could we change? We were very successful, delivered high quality products, were rapidly growing and establishing ourselves as the world leader in our field. What were we thinking?

From a testing perspective, the thought of becoming absorbed in cross-functional teams, potentially losing managers, wearing many hats, changing the way we work and think, and having doubts about what our roles were going forward, created doubt and reluctance.

The change has been a positive one and was one of the best moves our company has made. It is not without it’s challenges however. Read on as I extrapolate my views and thoughts of the transition. I will highlight the goods and the bads and give an overall summary of my thoughts and experiences.

The Goods!

Specialization

Instead of employees spreading themselves too thin and being jacks of all trades but masters of none, specialization helps you truly understand your products (your ability to design, develop, test, release and support them). Prior to our switch, we often found ourselves having to develop and test products using tools and technologies that we had little expertise with. Specializing, allows us to dig deeper, develop better and more importantly, understand the products, the users and of course – test better!

Freedom to change process

Along with the change came autonomy. We now were the masters of our own domain (Seinfeld anyone?). We were no longer bogged down by company-wide imposed processes that may or may not fit what you are doing. If something doesn’t work or is not a fit, then scrap it and do something else. These kinds of change were impossible before. Context is key in testing. This allows strong, professional, thinking testers to adapt to the context of what they are testing and use the appropriate methods, tools, frameworks and the like to test better!

Sense of accomplishment

dogWithBigBone

I have two dogs and I know the feeling of excitement they get whenever they get a bone or a treat. Work is no different. If you want happy, engaged, enthusiastic testers, you need to throw them a bone every once in a while. I’m not only talking about more money, I’m talking about… sense of accomplishment. Agile gets testers engaged! They are there from the beginning, contributing and making a difference. They help shape the design, development, the testing strategies, analyze and manage risk, help keep everyone on task, and working on things they may not normally work on or contribute to. In traditional waterfall, you are drones, working in isolation, segregated in many respects from decision-making and shaping of products.

The testers in our organization are clearly happier now. They feel more valuable and most importantly, feel like they are integral pieces in the successes that we continue to have!

Varied work

Can anyone say less boredom? Agile allows you more freedom to explore new technologies and ways of doing things, allows you to work with different people, allows you to take on challenges and see projects through from beginning to end and beyond. You work in a smaller more iterative nature. If you raise a bug, it gets fixed right away. It doesn’t go off into never never land to maybe get looked at one day. One day you may be writing, the next day exploratory testing, the next day doing automation, the next day project planning, the next day… who knows? I’ve always been a big proponent of ‘test what makes sense today’. Agile allows you to do this, and not get bogged down by process or wasteful tasks.

The Bads!

Unfortunately, we can’t always view everything through rose colored glasses:

Awesome tune, but of course with everything, there are challenges. The following are issues I’ve found that we are working through:

Silos

Along with smaller, dedicated teams, comes restrictive vision. “We are building our little piece of the puzzle and that is all that matters”. Actually, no it is not! We need to continually interact with other groups, share information, and think as one company with the same vision. Moving from large groups to small groups enables this disconnect. It is up to everyone to keep those lines of communication open!

Not my problem it’s yours

Along with becoming more siloed, comes behaviors like ‘Sorry, that’s not my area’ or ‘I don’t have time to help you, I’m too busy doing what I’m doing’. Prior to the re-organization, ALL testing was everyone’s responsibility. Everyone had their own work to do, but also worked in a shared pool of activities when needed. The ability to shift focus was much easier before. Now, everyone is busy in their own worlds, and it is human nature to occasionally shuffle off responsibilities or challenges to others. Particularly if it is not your area of responsibility.

This is certainly something we need to get better with. Open communication, helping a friend out, keeping your eye on the whole company vision, and mostly, thinking of the quality of all products and features, as a whole team approach.

Wearing Many Hats

Sometimes we look good when we wear hats (women), sometimes we look silly (men). Depends on the context and just how silly the hat really looks. The idea of everyone in a small cross-functional team being able to do any job or task is idealistic. But is it reality? To a certain extent sure. Anyone can do almost anything in life. It is how well you do it, and how long it would take you that matters. I could climb a mountain, knit a sweater, fix a car, chug a beer, write a software program, write technical documents, etc. The question is how well and timely can I do them.

The answer to all of those in today’s speak would be ‘Meh’! Although, after all this time, you’d think I would be good at chugging a beer!?

We all have our specializations and strengths. We’ve gotten these through school, work, and personal life experiences. Let us continue to utilize our unique skills and let those better capable of doing the rest – do the rest! If at all possible.

Summary

I feel it has been successful move. We are delivering faster with higher-quality products than ever before. If we keep up with the goods and work a bit on the bads, then the sky is the limit for our potential. Quality is not just owned by testing, it is a whole-team approach.

Our whole team is owning it!