Starting the Agile Journey
I’ve been using the first few of these articles to talk about the workplace and your career. I’m going to change gears this month and talk about Agile software development. You’ve probably heard of it. Specifically, I’m going to share my experiences from three different projects that recently started their Agile journeys. If your organization is doing any kind of software development and you haven’t already transitioned to Agile, maybe you’ll find this helpful. If you’ve already transitioned to Agile, maybe this will sound familiar, but you might have different experiences you can share in the comments.
Before I dive in, a couple notes about my background. First, I had been doing traditional waterfall, or spiral waterfall, software development for almost 30 years before my first attempt at Agile. I'm evidence that old dogs can learn new tricks. Teaching “old teams” new tricks can be tougher as you’ll see in one of my scenarios below. Second, Agile is a mindset, not a methodology. There are key values and principles outlined in the Agile Manifesto. It is not a step-by-step process that’s written down in a few work instructions that you can just toss at a team. It’s flexible. It’s meant to be. The team needs to be committed to discovering the best way for them to “do” Agile given their situation.
Project 1 - Small Team. Self-Motivated to Change.
This was a small team at a young company. There were almost no software processes in place. Individual developers were mostly focused on their specific projects. I joined as one of the more senior developers, and probably the one with the most passion for continuous learning and continuous improvement - of both software products and software processes. Management gave us the freedom to use whatever methodology we wanted to as long as the work got done. None of us had any real Agile training. We just jumped in and started creating stories, building up backlogs, estimating work, and making deliveries. Did we get it all right? Probably not. Was it better than what we were doing before Agile? Absolutely. The team was more aware of what everybody else was doing. We shared ideas, problems and solutions. We innovated. We responded to change. Even small teams can benefit from an Agile mindset.
Project 2 - Medium Size Team. Directed to Change.
After working as an Agile developer and as a SAFe (Scaled Agile Framework) Product Manager on two different projects, I moved into a Software Manager role for a team that had largely been isolated from the rest of the organization when it came to process improvement. It was a slightly larger, very senior team that had been using many of the same processes and tools for the last 20 years or more. I was tasked to help lead the adoption of Agile principles. The company provided a lot of resources and training. We had access to Agile Coaches. We had a dedicated Release Train Engineer. But we also had very little commitment to the transition from the development team. Most of the team had very little awareness of Agile principles or benefits before we started our journey. Did we get it all right? Certainly not. We probably should have treated pure development and the handling trouble reports from customers slightly differently. Was it better than what we were doing before Agile? I believe so. The groundwork was laid for better communication and cross-training, as well as better awareness of product goals and insight into progress. There was still more work to be done when I moved on to another assignment, but I felt good that the team was headed in the right direction. Getting a team of senior developers who have worked together for a number of years to adopt a new mindset and see the long-term advantages can be challenging, but I believe it’s worth it.
Project 3 - Medium Size Team. Motivated to Innovate.
领英推荐
I recently joined a team that had started using Agile tools and methodologies a few months prior. I’m not sure we’ve fully adopted an Agile mindset as a team or as individuals. We do have a backlog. We execute in two-week sprints. There is a Product Owner. But I feel like there is room for improvement. The team recently decided to estimate stories in days because using story points was “too hard” to understand. On the other hand, the team is pushing the boundaries of adopting leading edge tools, processes and methodologies within the company. The standard software development environment is in a Docker container. We’re establishing a modern DevSecOps software factory and defining GitLab pipelines. Automated testing is a key goal. Do we have it all right? Not yet. Not ever. The Agile mindset requires continuous learning and continuous improvement through ongoing inspect and adapt exercises. Is it better than before the team adopted Agile? I don’t have enough history to say for sure, but I can say the team is very agile (small 'a'). We constantly adapt to new priorities and changes in direction. It's evidence that we’ve started the journey.
So, there it is. Three very different experiences with Agile. Yours will be different still, and it probably won’t be easy. Cultural change and mindset shifts do not happen overnight. Remote and distributed teams can add to the challenge of adopting Agile. In the end, it’s a mindset and the specifics will be hashed out by the team as they start down that winding road. At its core, I believe Agile is the most effective way to do software development that we have today. Enjoy your journey!
I’d love to hear your thoughts in the comments below. I’d also encourage you to share this post on your own feed. The more discussion, the better.
________________________
Banner Photo by?Mitchell Luo?from?Pexels
Ninja Photo by Gratisography from Pexels
Scrum Photo by Ollie Craig from Pexels
________________________
I should probably come up with a more legal sounding disclaimer, but for now, I’ll go with this. The views and opinions expressed in this newsletter are solely my own and do not necessarily reflect the opinions of LinkedIn, my current or former employers, my alma mater, my church, or my family.