As an experienced Agile developer, I have had the opportunity to work on a variety of projects, both in Agile and waterfall environments. I have seen first-hand the benefits and drawbacks of each approach, and I want to share my insights with developers who may be new to working in an Agile environment.
Firstly – the term developer is used because Agile was created by a bunch of software people. But remember that the people who are called developers in an Agile team will be multi-skilled – the term is a blanket one that encompasses people with testing skills, business analysis skills, and yes indeed – developer skills. For non-software teams I prefer the term “creators” rather than “developers” but because I am a software developer I will stick with that language for the rest of this blog.
When working as a developer in a Waterfall environment, you may be accustomed to clear demarcation between the developer’s role – to design the solution and build it – vs the tester role or the Requirements definition. You may also expect to be directed by a Project Manager or a senior developer. In Agile – it is different, and you need to get comfortable working differently. Having said that, a good Agile environment is a great place to improve your skills and knowledge, and to demonstrate your leadership potential.
So what are the key differences when working in an Agile environment? I think there are six priority activities that a developer must focus on to be successful:
Collaboration
Agile is all about teamwork and collaboration. Developers must work closely with all the team members, including product owners, designers, and testers, to ensure that the project is moving in the right direction. No more hiding in your cubicle, you need to engage with others.
Communication:
In an Agile environment, clear and frequent communication is key. Developers must be able to effectively communicate their progress, roadblocks, and ideas to their team members and stakeholders. We can’t rely on a Project Manager to represent what we are doing – we must ensure we are communicating clearly to stakeholders.
Flexibility:
Agile projects are constantly changing from Sprint to Sprint, and developers must be able to adapt to new requirements and changes on the fly. I find this acceptance of the change to be a refreshing improvement over the “waterfall” way when people try to sneak in changes by pretending that this is what they always wanted. I realise I’m starting to sound like a cynical developer now.
Prioritisation:
Developers must be able to prioritize their work and make sure that they are focusing on the most important tasks at hand. Sometimes we will want something done urgently, but we have to respect the Product owner’s priority call, as they are the ones who have the fullest view of customer needs.
Continuous Improvement
Agile is all about continuous improvement, and developers must be willing to learn and adapt to new processes and tools to improve their work. In the past, we would hold lessons learned exercises at the end of the project, but now we hold a retrospective meeting every three weeks at the end of the Sprint. That meeting is really useful as we try to act like a sports team who analyses each performance to see how to improve before the next game. In our case, we look over how the last Sprint has gone and what we could do to improve on the next Sprint.
Empowerment:
Agile empowers developers to make decisions and take ownership of their work. Developers must be willing to take on this responsibility and be accountable for their decisions. If one of the team is not putting the effort in, the rest of the team are the ones who have to pick up the extra workload. So we have learned to call each other out when required, and ask for help when needed.
One of the biggest differences between working on an Agile project and a waterfall project is the shared ownership. In a Waterfall project, developers often work in silos and focus on completing their individual tasks. In an Agile environment, developers must work closely with their team members and stakeholders to ensure that the project is moving in the right direction. The fact the team owns the code collectively – rather than individuals owning different modules – makes us feel far strong collective bonds of ownership.
Developers who already have experience working in Agile are obviously better equipped to navigate the challenges that come with working in this type of environment. For developers without this experience, access to a strong and experienced Agile Coach can be a game-changer. A good Agile Coach can provide guidance, mentorship, and support to help developers both understand the subtleties of the Agile framework and navigate the complexities of implementing Agile in an organization where not everybody is on the same page.
Working in an Agile environment requires a different mindset and some additional skills for developers. With the right mindset, skills, and guidance, developers can thrive in an Agile environment, deliver successful projects and gain a huge amount of learning from the experience.
Conor O'Dwyer - Technical Architect
Conor is a Senior Technology Professional. He has over 20 years experience architecting and implementing multimedia software systems including interactive kiosks, digital signage and music systems. Conor is an expert level experience working with the Microsoft .Net technology stack.
