WHY SHOULD BUSINESSES CARE ABOUT BEING AGILE?
60% GREATER REVENUE GROWTH, FOR STARTERS
In this presentation, projekt202 Vice President of Technology Paul Tidwell takes a look at agile methodologies and how business leaders can benefit from their adoption into their organizations.
WATCH THE VIDEO NOW. A TRANSCRIPT ALSO FOLLOWS BELOW:
Hello, my name is Paul Tidwell, and I’m the National Practice Leader for technology here at projekt202 in Austin, Texas.
Today, I’m here to talk about genuine agility in three steps. This is not capital-A agility like a formal methodology, but true agility, the ability to respond to a changing business environment.
So, why do we care about agility? Why is it important?
The ability to test, deploy, iterate, experiment are critical to the success of companies these days. Companies who adopt these methodologies are realizing up to 60% greater revenue growth, and the ability to compete in an ever-changing environment.
Digital transformation is the hot-button term of the day, and companies who are going through digital transformations are seeking to better leverage data, analytics, feedback, and all of their digital tools to engage their customers in a more meaningful way, and drive revenue.
These three capabilities, interlinked in many ways, contribute to unlock this capability and allow your technology teams to respond to business agility, which is the ultimate goal.
Eighteen years ago, the Agile Manifesto was authored, and companies dove in pretty headlong.
Here we are, nearly two decades down the road, and only 43% of companies are leveraging it effectively.
We see tons of organizations struggling in our client base, from new and untrained product owners and lack of incremental thinking, and a host of other organizational and communication challenges.
So, driving agile adoption. The method used doesn’t really matter. It’s more about the lowercase agility, the ability to respond.
So, having a methodology and a framework in place that allows you to embrace change is really critical. So be lowercase agile, think about being responsive, think about change. Know that it’s inevitable.
Some orgs tend to not have a really strong backlog. That’s critical to have a list of all the things that you need to do, all of the things that you’ve identified as known work. Try to identify unknown work, and also account for technical debt. Have a place, have a list, keep all of those things. Keep track of them, or they’ll come back and haunt you.
Anoint a project owner. It’s a critical role, and we can talk more about why it’s so valuable, but a product owner needs to be empowered to say no, empowered to prioritize, and become a tie-breaker for all sorts of difficult conversations.
They also become the fuel for the fire that is the dev team. So if they are unable to populate a backlog and keep enough ready work items for the team, they can become a constraint.
One of the critical flaws here is defining a product owner, and not relinquishing them of their prior duties. So you have a product owner that now has two jobs, when fundamentally being the product owner itself is a full-time experience.
Another challenge, working incrementally, thinking incrementally. It’s very, very difficult. Completion of a task is not a binary thing.
There are many steps of incrementality towards creating an experience. So allowing the team to work in an incremental fashion takes time. Allowing product owners to think in an incremental fashion takes time.
You can horizontally slice work, you can vertically slice work. But as long as you’re breaking it down appropriately, tasks need to be small, achievable, you need to be able to get your arms around them fully to predict what the outcomes will be.
So this is a critical attribute of a good product owner that takes time to develop. What’s really critical is the culture of Kaizen, continuous improvement and allowing the team to continually think about better ways to do things.
Retrospectives are effective in this idea, allowing a team to be critical of itself and have very honest conversations without it being a job performance conversation. Continuous improvement requires the ability to be introspective and think about the things that you’re not doing right and be honest about them.
The second leg on the stool is modern architecture. So, service-oriented architectures are still alive, there’s a lot of ways to look at these architectures and micro-services is being thrown around a lot. But it’s really just more of a “Don’t build monoliths, don’t build tightly coupled solutions that are difficult to deploy.”
So the modern architecture’s not necessarily a micro-service’s architecture, it’s just leveraging certain patterns that allow this level of agility within the organization. The ability to change, to change the way that you’re deploying, and changes the way that you’re building.
12-factor solutions. So, stateless-scalable applications, de-coupled from their underlying hardware. This is fairly synonymous with Cloud Native and portable.
You remain agnostic from cloud providers with this type of thinking. It should be easily deployed, redeployed so you could tear down your infrastructure and redeploy it.
So you can imagine the opportunities this brings for scale, deployment flexibility, disaster recovery. All that speak to that core element of agility.
Defining effective domain model, understanding your business and coming up with a common lexicon between developers and business stakeholders. And then leveraging that to help you find service boundaries and represent your service-oriented architecture in a fairly stateless way.
Avoiding monoliths, it’s not about having the tiniest services you can, or breaking up reads and writes, it’s about not having a big service that’s difficult to maintain and deploy, that has a unnecessary dependencies within, those types of things are clearly what the last 20 years of software development has left us with, and what we’re commonly trying to move away from. And a lot of digital transformations are seeking to solve.
Loosely coupled solutions, so don’t bake in dependencies, and where you find dependencies, break them as often as possible. Think wisely about how these dependencies can suggest service boundaries, or where your dependencies are absolutely necessary for the business.
And finally, the third component is DevOps. Adopting DevOps is an organizational change, it requires role changes between people. It allows for some new flexibility, but it’s also a changing of the guard that makes some people uncomfortable. So it’s not that your traditional IT employees are no longer allowed to touch servers, it just changes the way that they’re interacting with infrastructure.
So, reducing human error, taking people out of the equation. Scripting deployment, scripting environment creation, any time you do this, not only do you save time, but it becomes less error-prone.
At some point in time, somebody will forget to flip a certain switch and disaster will incur. Or when you have people moving up into new opportunities, or new hires, scripts replace training, they replace onboarding and all the kind of nuances for how environments are evolving over time, so change management along with this can effectively remove a lot of human error out of deployments. No more long, overnight deployment cycles and costly rollbacks.
It also helps you manage scale. So as you need to add more capacity, or you find bottlenecks within your application behaviors, you can scale in a fairly granular fashion and an intelligent way. Whereas, the business becomes wildly successful, you can scale up without a tremendous amount of pain, and this is a very cost-effective way to go about guarding the business.
This enables the modern architecture, right? So these things are tightly coupled. If your service granularity grows, the number of services you have could potentially grow exponentially. As that occurs, you typically would need more people to deploy those elements. This allows scripting and an operational pipeline to manage all of that for you.
So, as that footprint grows, it doesn’t grow with a dependent human cost to manage all of that infrastructure.
It also lets the developers develop.
So developers, by building solutions that are de-coupled from their underlying infrastructure, allows them to focus on building features and building the high-value things that they’re paid to do, instead of worrying about if that server is running too hot, or if they need to scale up the database or change the way that they’re approaching some sort of infrastructure dependency.
It allows them to focus on the high-value thing. So it does a little bit of breaking out of roles into a more logical fashion.
So finally, versioning. Versioning of services, versioning of databases. The ability to run concurrent versions of a service allows you to elegantly deprecate functionality in old systems.
It allows you to test new capabilities in a limited fashion, and do limited roll outs to certain segments of your customer base, or do blue-green deployment, so this fundamentally starts to pave the way for how you can have a lot of flexibility, because you’re not running one version of one server as a single gold standard, you can have several versions that have different capabilities, and this allows a lot of flexibility in client deployment.
So, all of these things together effectively prop up this ability for a technology team to be truly agile.
As the business begins to evolve and ask for things more quickly, and understand their customer needs more quickly, and respond and experiment, now the development team can keep pace and effectively deploy solutions into the public, much to the satisfaction to the business and the user base.
