Doing Agile from the bottom up as an internal team is very different then having an external coach brought in by the organization. As our Agile Journey starts it needs prioritization. Not the product backlog, the Agile implementation. Changes have to start small. They are gradual and can only impact this team. For maximum effectiveness benefits are as far-reaching and highly visible as possible. Success or failure is in full view of the organization. Knowledge, planning, passion, and teamwork will stack the deck in favor of success. Success breeds buy-in from above.
To do this alone would be nearly impossible. On a team of four developers I am the most junior. While my overall IT industry experience is on par with the rest of the team, they spent all of it in development roles. For me it has been just under half, with the non-development experience at a different company. Our project manager was let go at the beginning of the year. I was not yet in a position to take on the role and it was given to our lead BA. There was a catch. It become a dual role of lead BA and project manager. This was already a stretch role. The knowledge gained while earning my certification gave authority to my offer of help. The pending maternity leave of the other BA made the need for help painfully obvious.
I started by asking how I could help. I had already taken the daily stand-up meetings off the plate of our senior developer. It was no secret on the team that I planned to move from development to project management. It was also known that I was taking a class on Agile methodologies. Over the course of a couple of weeks and a few meetings we started a partnership to run our team via Agile methodologies. The main reason it worked is simple. I did not approach it with an attitude of being able to fix a broken team, but one of being able to help solve problems and relieve pain points for the project manager. Instead of starting with what I felt would be best, I started with what my “product owner” felt was most needed.
From there, getting the support of our director was pretty easy. It was no secret that we had been essentially a self-run team under the old project manager for a year or more. Our new project manager/lead BA has a good rapport with our director. Upper management is in no hurry to spread our efforts across the organization. Even our director is not ready to push Agile on the other teams in the group. We are on the way though. The other project manager in our group has been looking at some of what we do as they struggle to launch a new project. The director wants our process documented. In half a year we have managed to move our team along the Agile path and raise interest in the rest of our group. As more teams in the company move from maintenance and enhancement of older programs to replacement and implementation of new programs I hope to see Agile take an ever more prominent position at our company.
Getting buy in for Agile was achieved by starting with an Agile mindset. This should come as no surprise. At its heart Agile is not about following a specific set of rules. Agile is a mindset of constant willingness to adapt what does not work. Agile is moving toward an oscillating end goal that slows to a stop as we get closer. Agile is acknowledging that what we know changes as we learn, and that may affect what we need. As Agilists we need to extend the same mindset used for running a project to implementing Agile. Every organization is like another project with different roadblocks. Different methods of overcoming them are needed to reach the similar, but different, end goal of the organization running Agile.