My Experience with Agile Processes
I’ve been doing software development for many years, mostly in Microsoft-centric technologies. For the first several years of my career, I was basically just writing code with companies who had very few processes or were more Waterfall-based. It wasn’t until 2012, when I had my first taste of Agile Scrum and why it was a preferred method.
Instead of having to gather requirements, analyze the system, doing software development, test the software for bugs and interface with customers, I became more specialized in what I enjoy doing, software development. It was very efficient. I could learn more about coding while being more productive with getting development tasks done, while having the other tasks left to those who were specialized in those tasks.
When I was involved in Waterfall, or really no processes at all (basically dubbed “Cowboy”), I found it rather cumbersome the myriad of tasks I would have to do and couldn’t be as efficient as a software developer as it took away time from learning the software and being a more efficient and proficient software developer. The goal of software development was to develop features or perform bug fixes in a timely manner delivered to the customer, internal or external.
Agile is More Than Just a Daily Standup
Over the last half of my career, I found many people who think of Agile as just a daily standup ceremony. Other teams would just go through the ceremonies, such as a Retrospective, and totally miss the purpose of this meeting. I’ve seen many teams fail to follow through on the key points to improve upon as a result of the Retrospective. Then, I’ve seen Retrospectives cancelled due to a lack of maturity dealing with constructive criticism during the Agile sprint. I’ve seen a huge lack of management support and accountability. People blamed Agile for why the process didn’t go well.
I’ve seen firsthand when Agile Scrum is implemented effectively, teams work nearly harmoniously, customers know approximately when software is released and software releases are iterative and successful. It was also a fun experience for many of us. We had many people supporting the software development process, such as: business analysts, product owners, product managers, project managers, software architects, technical leads, QA leads, quality assurance engineers, release managers, database engineers and software developers. Everyone worked together to release quality software.
Agile Manifesto
For those interested in learning more about Agile, I would start with reading the Agile Manifesto. Many of the people involved are well known people in the software industry, like Robert “Uncle Bob” Martin and Martin Fowler, who are both well-known authors of numerous books on clean coding, architecture and agile.
Lean Agile, Agile Scrum & Scaled Agile Framework (SAFe)
A couple of years after my first foray into the Agile Scrum methodology, I found a company building onto what I had already learned about Agile Scrum. Lean Agile was the talk there along with getting certified in the Capability Maturity Model. We had to read a book, “Lean Startup” by Eric Reís. This helped us with the vision of our leadership team.
The gist of Lean, whether is it Lean Agile or Lean Six Sigma, is basically “trimming the fat” off of business or software development processes. It is about reducing waste to enable delivering software features in a more timely manner. Software releases should be iterative and the Agile Manifesto mentions as much.
The Scaled Agile Framework, or SAFe, provides a framework for Agile Scrum to release better quality software with more efficiency and better outcomes for the project and budget.
The Capability Maturity Model is a way to assess the software development processes. One company I worked for started and achieved CMM Level I, which is the entry into certification.
The various roles in the software development process is key. Many companies the last several years have been reducing the support staff or even eliminating roles like the most important Scrum Master role. This puts much more stress on the others on the team to deliver quality software effectively and in a timely fashion. Here’s a good site HERE discussing the various roles and their importance.
Summary
I hope this brief article helps people understand some of the processes for creating better software. While I briefly touched base on the Agile Scrum and related processes, there will be more articles in the future discussing how effective Agile Scrum processes can be very effective in creating better software and outcomes.
Leave a Reply