Growth through Agile

Change is Hard

"Agile isn't something new. It's been around some 20 years. It's not whether you are doing it? The question is, why aren't you doing it?" I recalled these words from the Melbourne Agile Conference back in December 2021. According to goremotely.net, 71% of companies use Agile in one way or another, with 98% of those saying it has helped them. So with such a popular software delivery framework and all the benefits over the traditional waterfall method, why can it still be so hard for some Software Development teams or individual Software Engineers to change to Agile?

I've experienced moving from a traditional waterfall method to Agile Scrum as a Software Engineer and Engineering Team Lead of a new team making the transition. I've heard the same concerns and questions from Software Engineers on both occasions.

1. "We have too many meetings, and I'm not getting as much work done."
2. "Why do I need to do item kickoff when the requirements are clear?"
3. "Why break up work into small items? It's faster if I do all of it in one item."
4. "Walkthroughs aren't needed. I did everything in the item, and it works fine."
5. "I just want to do my job as an engineer and write good code."
6. "We were doing just fine before."

I've learned that Agile can provide one or more good answers to each question. But even with all concerns responded to, I can see the change can still be frustrating. And it's frustrating for a good reason. Your job description has changed. The expectations of your software engineering role that you are accustomed to, value, and enjoy have changed.

Previously you might have spent most of your time coding and rarely needed to join meetings. You had the autonomy to analyse, design and code as you see fit. Now in Agile, you are probably only spending 70% of your time coding, with the rest taken by kickoffs, standups, reviews, retro, workshops and other meetings. And due to all the context switching, you are probably writing even less code than that. You previously had one manager who might occasionally ask you about your progress, but now you are managed daily by a set of Agile processes. You didn't sign up for this, and that is where the problem lies.

Growth as an Engineer

Both Agile and Waterfall have pros and cons, and each is better suited for specific project types. It will be debatable which is better for your project. That discussion will be left out of this article, and instead, I'll focus on one clear benefit that Agile has over traditional methods. It gives you, as an individual, lots of opportunities to grow. The daily Agile events and best practices that you find frustrating can help you build 7 valuable skills as a Software Engineer and expand your career path.

Quality Assurance Mindset

High-performing Agile teams require sound engineering principles like code reviews, automated testing, continuous integration and continuous deployment.

You should already be doing code reviews, but testing responsibilities might have been passed to the Quality Assurance (QA) team. In Agile, testing isn't a separate process done near the end of the release cycle but is a part of the team and done continuously. Engineers and QA work closely together, discussing how to best test items, sharing expertise and doing work. If you haven't yet worked on many automated tests, you'll quickly improve your testing skills and knowledge of testing frameworks and build a quality mindset.

Agile's highest priority is to satisfy the customer through early and continuous delivery of valuable software. Therefore, all modern teams will implement an automated Continuous Integration & Continuous Delivery (CICD) pipeline. This automated pipeline will build, run validation and compliance checks, and perform tests with every code change. In addition, it might also automate the release and deployment. The result is faster feedback times, faster release and better quality software.

Along with automated testing, having CI/CD knowledge is a core skill of a modern Software Engineer.

Programming Skills

In a cross-functional Agile team, completing items that deliver the sprint goals are prioritised over individual skill sets. This can lead you to work on technologies in which you aren't strong. For example, perhaps you joined a WebApp company as a React frontend engineer and are unfamiliar with the python backend. Occasionally working on some backend items, you will learn new programming languages and frameworks that can help you support each other's work and make you more valuable as a Software Engineer.

Side note. This doesn't mean you'll need to become a python expert or should be working on large critical items. Instead, start on something small that you can quickly test and debug with breakpoints. This way, you can run it multiple times to understand the flow of the code. Pairing with someone with more experience is another great way to get started. And don't feel bad if it takes you a whole day or two to complete an item where the python engineer can finish it within hours. You are still making a valuable contribution if it helps get the sprint across. And over time, you'll improve and gain confidence to complete small items on your own, which frees up the python engineers to focus on the larger and more complex work.

Agile promotes delivering features in short and frequent iterations called Sprints, and items are generally smaller. This leads to more frequent code reviews and better quality code suggestions. This is because it's much less tiring for someone to understand and properly code review a two-day item than a two-week item. In addition, there can be a disincentive to make changes after spending two-week on an item. Both engineers may feel rewriting the code puts the item at risk of not being completed in time or that it's just too much work to change and not worth the effort since it's already "working fine".

Teamwork

Teamwork is one of the core pillars of Agile, much so that all agile ceremonies and activities require collaboration or discussion to achieve their goal.

Sprint planning is a time for the team to collectively plan out the next set of work for everyone. Item estimation uses 'wisdom of the crowd' to determine the risk and size of an item. In daily standups, the group meets and discusses progress, identifies blockers, and sees who needs help. The 'sprint confident vote' gives everyone a vote on how confident they feel about progress and whether any change or refocus is needed. Kickoffs are an opportunity to make sure everyone is on the same page about the item's requirements and a chance to explore implementation approaches. Walkthroughs help demo your work and get feedback and validation from teammates. Sprint reviews are a chance to present the work to stakeholders and determine future adaptations. Finally, Retros is a time for the team to reflect on the sprint and share lessons learnt to identify activities, processes and tools to help the team work more efficiently.

These agile activities build teamwork skills where everyone knows how others are going, their strengths and abilities, how to support each other and how to self-reflect and adapt to run more efficiently.

Communication and People Skills

The Agile methodology was built on communication and is a part of several values and principles; interactions over processes, collaboration over negotiation, and daily meetings by face-to-face communication over documentation. Like teamwork skills, frequent communication in every Agile activity results in better team performance and, ultimately, a better final product for the customer.

Doing regular showcases is also a great way to improve your presentation skills. You'll learn the importance of adjusting your presentation to the target audience, as attendees can be other Engineers interested in the technology to C-level execs interested in the final product or project progress.

Giving and Receiving Feedback

One of Agile's most important activities is the sprint retrospective. This is an opportunity for the team to review the previous sprint, discuss the good and bad, and propose and implement actions to improve quality and effectiveness. These can include ideas for increasing productivity, raising software quality, developing skills, introducing tools and enhancing team happiness. Outside of code reviews, software engineers might not always have occasion to provide constructive feedback. The regular retro is an open and friendly environment to practice this difficult but essential skill of listening to others' concerns and problems. Then without calling out individual mistakes, focus on the underlying issue and discuss ways for the team to avoid the problem next time through process and training.

Project Management and Leadership

In an ideal Scrum team, the scrum leader isn't even needed. Instead, the team would manage itself. The road to achieving this is through having everyone involved in the entire software development and delivery process, from workshop and design to coding, testing and support. Every team member learns to step up and take ownership of the work, essentially being a leader or project manager.

In the workshop stage, you'll be helping to write down the problem in words and discuss what is being solved, why it's needed and how the team will accomplish it. The project will then be broken down into one or more time-constrained milestones called epics. And for each epic, you'll help break them down into individual items that team members can work on. You'll use sizing techniques to help estimate how large items are and when the epics can be delivered. You'll learn how to sequence and prioritise the items to ensure no bottlenecks and a continuous flow of work and client value is produced. Finally, you will manage risk by identifying unknowns in a "risk probability and impact" matrix and plans to mediate them.

When the project starts, you'll help schedule items into cycles called 'sprint' based on team speed, availability and skills. You'll practice reviewing the project's progress in daily standups to identify blockers, help others needing assistance and make quick decision-making. You'll be introduced to burndown/burnup charts to better understand how the sprint is going and adapt if needed. You'll learn to showcase your work to other Engineers and stakeholders to show progress and get feedback. Finally, you'll learn to reflect on your sprint to find ways to increase software quality and team effectiveness.

If the project cannot meet the deadlines, you'll learn to negotiate with stakeholders (product team, execs or customers) on what should be delivered and prioritised.

By being involved in Agile ways of working, you'll gain tremendous experience in planning, executing and delivering a large project.

Customer Focus

Agile puts the users first by asking, "what value are we creating for the customer?" If a work card doesn't answer that question, you must think carefully about why you are working on that item.

Writing a user story using "As a [persona], I [want to], [so that]." ensures you are thinking about the user's problem that is being solved instead of just implementing some feature.

Consider below two user stories. Both can implement the same feature, but the first focuses on what value is delivered for the user.

User story A: "As an investment manager, I want to perform risk compliance checks before any stock trades so that I don't accidentally overexpose my client to a particular market risk."

User story B: "Add feature to check compliance on stock trades."

Even tech-debt items can indirectly benefit the user. For example, "As an admin user, I want the fee calculation code refactored so that future features and changes are faster and cheaper to implement".

Occasionally, clients can also join the workshop with engineers and product groups. As a result, you'll get first-hand insights into clients' wants and concerns, which can better align what you are building to what clients are trying to solve.

Career Growth

Participating in Agile best practices and ceremonies will enhance your software engineering skills, build invaluable teamwork, communication, project management and leadership skills, and develop a customer-first mentality.

These skills make you more valuable as a software engineer and open up more career paths. Of course, you could continue on the technical career path to be a Senior Software Engineer or a Technical Lead. But with the leadership, people and project management skills, you could also look to jump across to Engineer Team Lead or Team Lead. Or you might find yourself interested in Agile, and with a bit of extra study and certification, you can become a Scrum Master or Agile coach.

Changing to Agile workways is hard. During the transition, you'll lose things you value and enjoy about your job, but if you can try and persevere, you'll gain much more. And in the end, the only question you'll be left with is, "why didn't we do this sooner?"