Moving into an Agile environment for the first time can be quite daunting – at least for me it was. In this post, I’ll be briefly touching on my experience moving roles into a company that adopts the Agile methodology for developing software. I’ll mention some of the things that really took me by surprise and will be comparing some of the processes and workflows against what I have previously experienced in other roles.
The term ‘Agile’ is used very loosely and not all companies that claim to be Agile, are actually Agile in their approach to getting things done. There is also very little that is set in stone with regards to this methodology as it is by its very nature adaptive and ever-moving with the aim of continuous improvement. For this reason, one could read up on the subject and become either confused or cautious when considering adopting Agile or moving into an Agile environment.
This was my experience. I had done a lot of reading up on the subject before starting my most recent role and could only previously define Agile by the vague principles listed here in the Agile manifesto: https://agilemanifesto.org/principles.html
That means, when asked in interviews or speaking about Agile in public forums I would parrot buzz words or buzz phrases (is that a thing?) such as “satisfying the customer”, “working closely with the customer”, “close collaboration with stakeholders” – the thing is, these things can be done in a waterfall approach to things. So in my opinion, Although Agile contains just a few core principles, its main value becomes apparent when people adopt those principles and actually start working that way.
What I mean is that companies/people will all ‘do’ Agile differently but will all have those basic principles at their core. So to address the title of this post, moving into an Agile environment is not really something you can prepare for to a great extent because it is implemented in different ways at different places, and often employers have their own interpretation of how they should get things done.
I had always thought my previous experience in companies was quite Agile, in that we worked closely with the business analysts and clients, oh and we also had stand ups every morning! Come on, this is as Agile as you can get! … or is it?
I think Agile is quite a natural approach to software development, especially for us Testers. All those test cases produced early on, only to have the client change their mind AFTER the application or feature has been tested… the pain..
To come back to my experience in my previous role, which was totally Agile (I thought), I felt after 6 years it was time to move on and explore new opportunities and the companies that I was applying to were all saying they were looking for Testers who understand what Agile is and have experience testing in an Agile environment. All good with me. I just pulled out some buzz words from the memory bank and was able to pass the phone interview. I had no idea how much I didn’t know until I started in my recent role.
Cross-functional teams and collaboration:
At my current place of work, they are Agile to the core so my transition was quite a shock to the system. The first difference I noticed when I joined was the arrangement of the teams. In my experience I have been part of a ‘testing team’, in that we sat separate from the developers (close by, but separate desks). We also sat separate from our product owners, business analysts and project managers. The setup at my current place of work is that we have what could be called ‘Agile teams’, which are essentially groups of people of different roles, working towards one vision in relation to what they are developing/working on. So when I joined, in my team we had another Tester, 4/5 developers, a tech lead, a principal engineer, a product owner and an Agile lead. We all sit together (although, COVID has obviously prevented this – Slack and Google hangouts will just have to do in the meantime) and we all discuss openly and work closely together. Each team in the company has their specific area of focus in relation to our application so there is also a lot of collaboration with the other teams also.
Breaking work into small chunks:
So the basic setup of a team was the first initial surprise. Secondly, I noticed the work was allocated via tickets. I have had previous experience with more feature-based releases or ‘Big Bang’ releases, meaning that the client wants X feature, we go away and build it, test it, then release the feature as a whole in one big release, usually out of working hours, so testers and devs staying back after work finishes. The work in my current role is split into small chunks and is released during and over two-week cycles. Going by what I have read and speaking to other testers in the community this seems to be the standard when it comes to an Agile approach to building software, however this was my first time experiencing this. My testing habits are greatly affected already by just these first two changes in environment, because I found myself apologising a lot when asking the other devs questions – previously devs would sit separately with headphones in working away. But here, everyone is well aware we are all about collaboration so barriers are not up in that way. Yes the headphones are on at times, but everyone knows the deal here so they expect discussions to start at any second. I no longer feel I have to apologise when I want to ask a question or starts a discussion on what I am working on. Now what I will say is I am not sure if this is a direct result of a company adopting the Agile mindset or down to the great culture at the company (it could be both) but it is certainly stressed in the Agile manifesto nonetheless.
The other way my testing habits were changed is that there is more control from the team as a whole over what goes into our application. As a tester I am getting much more of a say in setting the acceptance criteria on a chunk of work that comes in, way before it is even developed. Additionally, as the work is in small chunks, the scope of testing is more focused. We focus mainly on the acceptance criteria of what is being built, and also timebox our exploratory testing around the code that is introduced – and then run some basic sanity checks on the application with the help of automation to ensure nothing else has been broken. This assurance is then doubled by the fact all other teams are using the same code base and are deploying to production numerous times throughout the day, so we are constantly conducting sanity tests when testing our work.
Additionally, as mentioned above, we are deploying numerous times to production throughout the day so delivery as a whole is completely different to what I’ve experienced. I believe the term is, “continuous integration” (CI/CD) – basically deploying to one shared code base, numerous times throughout the day. This means no staying late, organising and scheduling a team to stay back after office hours after each release to ensure the release has deployed fine. The only time some of the team have had to work out of hours was when we had won a contract with a client overseas whose weekends start on Sundays. This approach to delivery also means we can rollback super quick, as well as release things to customers more quickly and efficiently. Happy clients, happy team.
Inspecting and adapting:
The last thing I’d like to mention that really caught me by surprise, and was something I’d never had experienced before were the retrospective meetings, or ‘retros’. These are meetings with your team, led by the Agile Lead in which the team reviews the previous ‘sprint’ (usually a 2 week period in which a feature is worked on, or an agreed amount of work) and the team discuss the things they thought did not work, and the things they enjoyed and also things we should try in the next sprint! I had only attended meetings where previous work is reviewed i.e. if there had been any major bugs found – pretty much a lessons learned type of meeting. So these retros are really good if they are controlled and confined within the aims of continuous growth. In my first retro, I thought I had joined some type of post-mortem meeting where something had gone wrong because I started to hear for the first time, a team mentioning the things they were not happy with. These are very refreshing meetings if done correctly i.e. without any actions agreed on how to improve moving forward.
So to summarise, the following 4 things were very different for me and I had to adapt to them:
Team setup (different roles working together VS teamed up with others in the same role but on different projects)
Work flow (tickets in small chunks VS Big Bang feature releases)
Work flow pt.2 (collaboration throughout development VS testing when receiving the end of the build)
Continuous improvement (retro meetings, proactive approach VS reactive meetings, meeting only after issues are found)
Moving into Agile sounds like a huge change, and to be honest it is. It can be intimidating when you are actually doing it for the first time however, the results if implemented correctly are great and work better for everyone. You have to really question the principles in order to really adopt them; only when you really believe in them can you actually work towards great outcomes. I had my gripes at first but I am happy to say, my experiences with Agile so far have been great. I have a few questions myself around certain aspects of it, which I am sure there are answers to but at the end of the day, the most important thing is always improving. If another methodology pops up on the scene, and I believe it to be the best possible way to get things done, I would ditch Agile and jump in head first. This would also be something that the creators of the Agile manifesto would also welcome because that’s what they encourage. As long as it is the best way to get things done in-house and for customers then let’s do it.
This is the key takeaway I’d like a reader to walk away with; we should embrace change for the better. We should always scrutinise what we are doing and the ways we work, in the hope to find ways we can improve. If you are not doing things according to the Agile methodology, but things are working for you, then that’s great too. As long as we always scrutinise and look for ways to improve. With that said, I’d definitely say based on my experience so far, that for testers the Agile approach works so much better, for the reasons listed above and many more. I’ll be exploring the benefits of Agile VS waterfall in my next post where I also hope to scrutinise why and how things do and don’t work according to what I have come to know so far.
I hope this post has been somewhat beneficial and I have tried to reflect my experiences so far to the best of my ability. Reach out if you have any questions!
