The 8 Keys for Ensuring Agile Transformation Success
Agile development is no longer a question of if. Companies of every stripe, regardless of size, industry or geography, are leveraging this methodology every day to get applications to market more quickly with higher quality to fatten the bottom line.
While the “if” of Agile may not be in doubt, the “how” is still on the table. How does an organization plan for a transition to Agile development and execute it successfully? How does it avoid the pitfalls and challenges? In this article, we reveal 8 Keys for Ensuring Agile Transformation Success.
It Takes a Village
Every part of the organization that shares responsibility in developing applications and getting them out the door must play a role in this transition. Some will likely embrace this with more enthusiasm than others and can serve as guides for others. The four functions that are involved are:
- The Technology Executive
- The Database Professional
- The Application Developer
- The DevOps Engineer
For Technology Executives
Key 1. Remember the (Real) Big Picture
It’s tempting to focus on two of the three major application stack components: infrastructure and application code. These are, in the mind of some technology executives, the entire ball of wax. But there is one vital element that many ignore, and to their peril. The database.
The database doesn’t support the application: it is the application. Applications are nothing without the data in the database. Considering applications and development teams in Agile transformation plans but not the database and database teams is a terrific way to build in application innovation bottlenecks and inject more risk into the delivery process.
If the goal of adopting Agile development is to deliver innovation and a better customer experience faster, excluding the database team from the process will ensure this goal is not realized because of the continued impact of database deployments.
Key 2. Bring Everyone Along for the Ride
In many technology organizations, database teams see trainers, developers and QA teams go to conferences, get the newest tools, and receive the lion’s share of the praise during all-hands meetings. They, meanwhile, see themselves as masters of the all-important data, yet are largely overlooked, handle repetitive tasks manually, and for the most part, do their jobs the way they have been for years. Compounding the issue is that database professionals are trained to resist change to ensure the safety of the data platform.
They often reside in a shared services group as they support many parts of the business, so it’s vital to bring them on board and gain their buy-in for a successful Agile transition.
Key 3. Be Supportive
Without direct management support and clear messaging, Agile can simply be seen by some as the next bright shiny thing; when management does get behind it eventually, it may be more of an uphill climb than it would have been earlier on.
If an organization is serious about transitioning to Agile, it is imperative that management take ownership and clearly and continuously message the initiative. This messaging must define the benefits and action plan by department and/or group in such a way as to make plain that this is not change for its own sake; that it benefits all involved, including stakeholders and customers; and that issues such as risk have been duly considered as part of the process.
For the Database Professional
Key 4. Understand What’s Really in Play
Change is unpleasant, especially if it feels unnecessary – or worse, chancy. At first blush, Agile development can seem a risk-laden endeavor to database professionals. Speeding up database deployments is rarely the way to win the race.
But consider that the goal of Agile isn’t speed for its own sake. The point of Agile is not to abandon willy-nilly things that have worked for decades. One way of thinking about Agile is that it uses collaboration to eliminate inefficiencies intelligently. It’s not about going fast at the expense of safety.
Key 5. Don’t Boil the Ocean
Doing everything at once is never a good idea – not in life, and not in the database. As the word transformation implies, the process of moving to Agile development should not be seen as one of rip and replace, but a measured one that builds on small successes and learns from discrete, containable mistakes.
A best-practice approach begins with a documented view of the current process. This is reviewed and feedbacked with all involved: what works well? What needs improvement? What is core to operations? And so forth. This can form the basis for initial steps of the Agile transformation.
Key 6. Automation, Automation, Automation (and perhaps a little more Automation)
Many daily database processes are performed much in the same way as they have been for years – recovery and backups, installation and configuration, change deployments and ETL all still require a database professional’s time and expert eye. Unfortunately, this means that this highly skilled resource can spend less time on more strategic initiatives, like performance tuning, disaster recovery planning, capacity and continuity planning, and major upgrades.
Automating repetitive tasks as part of an Agile transition can elevate database teams from being seen as function-oriented to solution-oriented. It can demonstrate the expertise and deep organizational knowledge these teams possess as they are freed from spending time on mundane efforts to those worthier of their skill sets.
For the Application Developer
Key 7. Guide and Mentor
Agile arose within the software development community, so it is likely that an organization’s development teams are familiar with, if not already leveraging, Agile methodologies. The challenge for these teams will be to see past potential frustration at those not doing things “the right way” and help others visualize the opportunity that Agile holds.
While a database team new to Agile may have much to learn about the new methodology, its members’ possible concerns about risk and the safety of the data platform must be addressed. Understanding and resolving these and other important issues must come first. Then both teams can come together, applying lessons learned in the application build automation process to create a database release automation process that will speed time to market.
Remember, being open to changing existing processes to realize team-wide improvements demonstrates the flexibility that is the hallmark of Agile development.
For the DevOps Engineer
Key 8. Continue the Evolution
DevOps engineers reading this consider some of it old hat, but as they are that vital link between those developing the applications and the customers who need them, it’s worthwhile to reflect on a few points.
For example, consider the process of database deployments in your application release process. Is it slowing things down? In most organizations, the answer is yes. The database change process is often the biggest obstacle in terms of speed to market, as there are fewer tools to support DevOps for the database than DevOps for the application. That doesn’t mean they don’t exist: it just means that engineers must be careful in their selection process.
Agile is for Everybody
At its core, Agile is about collaboration. That means that a successful transition is based on teamwork: each department and individual contributing in a spirit of give and take, to create a process that helps the entire organization achieve its goals more efficiently.
Everyone who’s a part of the application release process – executives, database pros, developers and engineers – has their role to play as Agile continues its rise in the in the application development space. Keeping the big picture in mind while taking things step by step will move the team forward. Remember: you’re not in this alone. Learn together and from each other as the organization – and Agile – continue to evolve.