Future-Proofing Your Agile Transformation
Five points to consider in building a robust practice
This article is the second post in my series on Scrum, tools, and other things Agile.
“How can your previous experience as an [insert job title] help you build a lasting and effective Agile practice here?”
The candidate blinked. It was the second time he was interviewing for the role of a Scrum master, and the second time he’d heard that question. The first time around, it had been at a Fortune 500 technology company recruiter who had looked him up on LinkedIn. This time, it was a smaller service-based “startup-but-not-a-startup,”—but the question remained the same:
How can you effect change in our company—and make it so the effects will last for years to come?
Many organizations are making the switch to the much-touted Agile methodology or have already done so. (And interestingly, more and more teams that are turning to these practices are not software teams.) Teams are getting savvier talking in buzzwords, and trying to create smoother processes for themselves. Project management tools are catching on, too, bringing forward more reporting capabilities and custom workflows to keep up with these Agile practices.
Amidst this pursuit of agility, teams are also becoming more aware that implementing an out-of-the-box Agile practice is a blatant misinterpretation of what “Agile” actually means. I like to think that every team is unique, with its own blend of personalities, control systems, and protocols. Agile, by definition, is about the ability to adapt to changes and keep moving at a rapid clip.
This brings me back to the candidate. If I were him, I would ask the recruiter to consider the following points.
- “Identify your core motivation for this change, then write it in stone.”
Managers get excited when talking about “transformations.” The implication is that a lot of changes are going to happen, from processes to behavior, leading to measurable, hopefully positive changes.
Fundamental to this line of thinking, however, is the why.
Why is your company looking to change its methodologies? Is it primarily related to the bottom line (revenue, profits)? Are your developers consistently spending ungodly hours at their desks, putting in nights and weekends like nobody’s business? Do those developers constantly have trouble identifying what their priorities are?
While all the reasons above are legitimate concerns, they are symptoms of a deeper issue, and addressing that issue should be the team’s core motivation. A change in methodology should not happen to appease a few symptoms directly — the team should identify the reason behind those symptoms, then make addressing that reason their core motivation.
It is imperative to realize that symptoms will change as time goes on. Maybe you get better at estimating your developers’ effort but realize that you have always tried to work at 120 percent of your team’s ideal velocity. Maybe your team starts leaving earlier than 7 p.m. for a change, but your profits are taking a hit. In all of these cases, however, your core motivation will remain the same: addressing the reason behind the symptoms.
2. “Track small wins to begin with — but keep an eye on long-term goals.”
As any change management coach will tell you, the key to an effort over an extended period of time is to get a few victories up front, and make sure the team is motivated early. For the purpose of bringing more of an Agile approach to an enterprise, it may help to identify a couple of processes or projects that will have a quick turnaround in terms of results. Identify metrics that will verify that this change helps deliver quality product, stabilize velocity, help manage expectations, and improve the team’s morale.
A business stakeholder will look at any long-term goal as a dollars-to-effort metric. It is important to get them to buy in as well — and early wins are a good way to do that. However, the team must not lose sight of the long-term objectives here — that the new process must be robust, scalable, and adherent to the industry’s best practices.
3. “Expect change — in the process, in your team, and in the industry.”
One of the most important facets of being agile is being receptive to change, and adapting accordingly. This lets teams play with processes and tools that work and identify ones that hinder their progress. A practical process is one that is nimble — it should have a short ramp-up time and allow enough scope to make quick changes. To make this process consistent, it needs to be easy to implement, and to allow both current employees and new hires to adapt to it quickly.
Maybe your organization is a startup that will be adding clients faster than it can hire and train individuals. Or maybe you’re an established player in the market but have suddenly seen a downturn in demand for your services. Or maybe one of your team members has fallen ill for several days, and this is affecting your deliverables. Expect and embrace these changes!
4. “Be open to experimentation — responsibly.”
Following point #3, teams should be willing to alter the course of any change early on. Experimentation is a good thing, but must be done responsibly — too many changes, or too few, is a recipe for disaster, one that can lead to teams that are confused about what is expected of them, whom to report to, and whether they should even trust the process.
Also important is the frequency of these changes. The underlying concept that should guide any Agile effort is clarity — clarity of Agile principles, clarity in the scope of work, and clarity in the day-to-day. While change should be expected and welcomed, clarity helps reduce redundancies, improve communication, and increase productivity.
For example, let’s say an organization wants to implement a custom Scrum-style methodology that is unique to their business. Understanding which meetings to hold, who drives those meetings, and what the agendas are, is crucial to the team’s success. If the implementation team feels like some of the meetings are redundant or not as effective as they should be, or that some people may need to be included (or excluded) from some of these meetings, they can experiment early and find a sweet spot.
5. “Agile is about the people, not the process — so gather feedback often.”
Becoming an Agile organization requires people who are willing to drive change — not just react to it. Too often, companies simply get lost in the weeds — they worry too much about implementing a framework just right, or tracking a change to a dot. While crossing the t’s and dotting the i’s is important, companies need to put more emphasis on the most important factor to an Agile team’s success — the people!
Gathering feedback often, and utilizing that data to inform changes (and understand how the team is perceiving the ongoing transformation) is a great way to stay nimble. Maybe a document that your team takes for granted actually offers great insight into your release schedule. Maybe that seating conflict is driving a deeper wedge into your team than you originally assumed.
There you have it: five great interview answers. The candidate adeptly highlighted how to build the right process, get the whole team on board, and help everyone move toward a smoother workflow. Give him the job already!
About the Author
Varun Kuppili is accountable for the Agile practices at Rocket Code.
