Even today, in the 21st century, it’s rare for CEOs to steer their companies into agile waters. Change is hard, scary and leads into the unknown and changing an entire organization compounds all these fears. But, there are subtle, yet significant, ways in which you can organize your own work to be much more agile. And, as you gain confidence and understanding, you can transfer the learnings to your team. If things go well, and you’re able to effectively communicate these successes, you might even show your entire company how to change for the better. Using the metaphor of crawling, walking, running to represent progressive improvements, here’s how I’d do it.
Steps to a more agile you (Crawling)
The primary goal in this initial step is to begin teaching yourself good practices while learning all the pitfalls and pain points your team will encounter later.
- Use a source code repository for everything
- Document your work
- Setup testing infrastructure and use it
Every line of code and configuration you write should be safely and centrally stored outside of your development environment. This is the start of your infrastructure as code initiative – what could eventually become your entire company’s single source of truth. git makes this as easy as breathing.
You probably have some ticketing system or project tool with user stories for organizing and tracking development progress. Take the time to get commit messages to show up as comments there. This is incredibly helpful for answering and understanding those “how did I (do|fix) that?” type questions weeks or months after implementation. github has a convenient post commit hook which adds the patch information to the Pivotal Tracker story as a comment.
Ok, so you’re not holier than the Pope and you don’t do test driven development. But, please, for the love of God, don’t write anti-fixes! Stop the downward spiral before it starts by providing tests with every bugfix. This means you’ll have to sacrifice some time and effort to create test harnesses for your codebase. Do it, and you’ll thank me later.
If you lack the discipline to take these important steps, there’s no way you can ask your team to tackle the next ones.
Making your team more agile (Walking)
Ok, you’re the master of your own development environment so it’s time to get control of your team’s build. After introducing them to your repositories and tests, and installing the appropriate pre-commit hooks for linking stories to patches, it’s time for integration. In our “bottom-up” approach getting your team firing on all these cyclinders will really impress the other teams (and departments) in your organization.
- Build early, build often
- Regular sprints (at least bi-monthly)
- Daily standups by the water cooler
Continuous integration (CI) is the lifeblood of any highly functioning IT team. And when I say team, I’m talking about a devops team – developers and sysadmins working together to ship code. If your build includes bootstrapping infrastructure, deploying application code and running a battery of tests, you can release with confidence. Think of the build as your factory line. Steady flow and timely feedback keeps the business running smoothly. If your build takes longer than 5 minutes, you’re doing it wrong! Parallelize tests, add servers, and tweak performance. The build server is just as important as your production boxes so don’t skimp on real engineering investment. Jenkins is pretty much the defacto open source standard for this.
The shorter the sprints, the easier your product development. If your sprints are a month long, you’ll be continuously interrupted by desperate coworkers who also have work that needed to be done yesterday. This kind of CI is absolute poison to product delivery because you can’t tell them to come back next month. So you stop your work, shift your attention to their problem and the factory line becomes clogged. A weekly sprint, on the other hand, gives just the right buffer. “Unfortunately, this week we’re working on the following stories. However, next Monday, we can fit you in.”
Hang a kanban board up by the water cooler. Every morning go down to the watering hole with your team, circle up and talk shop. Encourage team members to physically move their own story cards through the lanes. It’s an amazing tactile feel of control and passersby may actually get a little jealous. After all, when’s the last time they single handedly improved the entire company (even if just an inch or two to the right)?
WARNING: as your team begins delivering more and higher quality features, they may start going home at 5pm everyday. This will undoubtedly make for some bad blood and misconceived notions about your team’s commitment. The only way to prevent these misunderstandings are regular and vocal communications of your performance to the entire company. Ensure everybody knows what your team is achieving (and why things are going so smoothly). By the way, 50″ big screen monitors strategically placed around the office are NOT enough. You need to actively push these achievements out in emails, presentations and water cooler propaganda blitzes.
The Agile Organization (Running)
By now, other teams will be wanting to emulate your glowing successes. You might think that after having done all the nitty gritty detail work in the previous steps, this final transition is a slam-dunk. Let me disabuse you of that notion.
Think of it this way. How easy is it to change which direction you’re swimming? Pretty damn easy – just turn whatever way you want and go. What about a canoe with 3 people? Open your mouth, discuss, agree and start paddling – notice the additional communication steps in there. Now, how about the Titanic? Ok, ok – bad example. What about a cruise ship? If you’re not the captain, it’s going to take more than a few impromptu meetings to get you sailing on a new course.
Hire consultants to introduce agile to upper management and train everyone else. Trying to use “internal experts” for this bogs everyone down in political pissing matches which wastes time and resources. Instead, use a well-trained, respected and experienced team to do this and be prepared to invest good money.
Repetition is the key to successful human learning, so if all you can “afford” is one day, don’t bother. Get a minimum 3-day session with all hands on deck, interactive trainings. Schedule follow-ups after one month or one quarter, both to drill the ideas in as well as show your commitment to the process as a whole.
Once you’ve got agile everywhere, you’ll need to figure out how to keep the bigwigs up-to-date. Filtering important issues and progress upwards so that informed decisions can be made in a timely manner is crucial to effective leadership. Besides scrum-of-scrums, encourage cross-pollination of product owners among different development/delivery teams.
Imagine a company wide Kanban board, prominently placed outside the CEO’s office with the captain himself asking project managers about the progress of various Epics – very cool stuff.
3 thoughts on “Stealthily Introducing Agile from the Bottom Up”
Inspiring! But, sadly, naive. Did you see this approach work already? Or is it just wishful thinking? Let’s keep wishing together (with eyes open though).
Definitely a bit of both. I’ve always been able todo the first two steps (self and team). The third foundered on the corporate investment to Scrum. Which of these steps did you find to be just wishful thinking?