There are a number of Cinderella stories of companies that manage their entire infrastructure in the public cloud. They have a continuous deployment pipeline that goes to the production system tens or even hundreds of times per day. This is what many organizations aspire to achieve. Agility does not necessarily have to be coupled with the cloud. Many organizations use an Agile business model without being IT or software-related. At the same time, many software companies have adopted Agile in one way or another for their operational and development practices.
Not every organization can be that showcase story, however. This can be due to an on-premises infrastructure that does not scale well, or an organizational culture not yet ready for such a change in mindset. Nonetheless, there are a number of ways you can begin your journey.
Strategy for Making the Move
As we noted above, agility is not necessarily coupled with technology and a good number of the stages are people- and organizational-related.
If you put 20 developers in a room, you will have 25 different opinions. The larger the group, the harder it becomes to:
- Make quick decisionsah
- Execute them quickly
- Adapt to change
AWS has a mantra:
If your team can’t be fed on two pizzas, then cut people.
~ Jeff Bezos
The concept is pretty simple : keep your teams small. Smaller teams can work much quicker and far better together. Communication and interaction is regular and should be in close proximity. Meetings and lengthy discussions, involving many stakeholders, become infrequent, allowing your team to concentrate on what is important and complete the tasks at hand.
Clear Goals and Scoped Projects
When you have a clear goal, it becomes much easier to actually provide an outcome that is measurable. If you define the goal and scope of your project in vague terms such as “a portal to sell a website-building product to customers,” it might mean many different things to the different people it is presented to. As a result, work could become very disorganized and fuzzy because no one really knows what the deliverable should actually be.
On the other hand, if you have a goal and a high-level set of requirements and scope, like the one below, it becomes much clearer what work actually needs to be completed and what constitutes your definition of “done”.
For example, “design a website that enables our company to sell a website building product to end users.”
- Site should be written in a modern technology, such as HTML5
- Site should be mobile-friendly
- Color scheme will match our company brand
- Site should support multiple languages (initially, English and Spanish)
- Site will have an online editor to enable the following features
- Choosing from a set of five pre-defined templates
- Editing text in the body of the HTML pages
- Choosing from a palette of five colors for each template
- Creation of a subdomain for user to publish website
- User management system
- Sign up portal
- Collect user information
- Secure billing system (can use a third party)
- Integration into the company’s financial system
The points above allow you to break the project up into specific pieces, divide the work across teams, and deliver according to the scope of the requirements in each “work package.”
Using Your Existing Infrastructure
Undertaking a drastic change in your work practices is not something that should be taken lightly, and it may be extremely difficult in established and large organizations.
Most companies have some extra hardware lying around (for example, hardware scheduled for retirement or hardware that has not yet gone into production). Dormant hardware is a great opportunity for you to test a new technology.
There is nothing that a developer dislikes more than having to rely on others (and in this, case corporate IT) to provide resources for their immediate needs. This is one of the main reasons for what is known as ‘Shadow IT’. Today, it is as simple as punching in your credit card number to get a resources on a number of cloud providers.
One of the currently available technologies that offers a user experience similar to the public cloud is OpenStack. Making use of your “extra’” hardware, you can install a private cloud solution that provides your users the freedom to provision the resources they need for their work — without having to rely on IT for every single request. This frees up your development teams to actually get the work done, without having to deal with infrastructure ‘simplicities’ (such as provisioning instances, networks or storage for their day to day needs).
Containers are another great way to enable your developers to be more self-sufficient. Docker can be installed on any operating system today, and enables your engineering organization to spin up their own containers with a few simple keystrokes. The added benefit of using containers in this manner is that the same technology can be used when you complete the development work, and want to move into production.
The simple use cases are not the only ones addressed here. In fact, with tools such as Kubernetes or Docker Swarm, complex configurations can be used locally on each developer’s machine — and replicated later in the process to a production environment — with minimal or no changes needed.
One of the often overlooked and ignored key tenets of an Agile transformation is the necessity of having the full support and backing of your organization’s upper-level management.
Agile coaching is an invaluable resource for your development teams, not only for their day-to-day practices in this new agile world, but also for continuous improvement.
Allowing your teams the freedom to make the changes they need is also crucial. At first, it might be difficult to allow the teams to decide how they will provide the deliverables — from the choice of tools and technologies to the order of the pieces of the solution. The industry has numerous examples of how the move to this methodology has been a success and has decreased time to market, employee churn and burnout across the board.
It is important to note that even though the responsibility moves over to the team that is actually creating the software, this does not mean that there is no structure and this is a free for all. Using proper Agile practices will allow you to benefit from the best of both worlds. Having regular planning sessions with all levels of the organization, from product management, product owners, and the Scrum teams themselves (of course, your customers should also be involved in these planning sessions — either directly or represented by product management). In these planning sessions, the requirements, but more importantly, the priority of the required features are discussed. With appropriate preparation, the teams can divide up the work to allow the timely delivery of features.
Even the showcase companies that are all-in with cloud, fully Agile, and make numerous deployments multiple times per day, did not start that way from Day One. It was a process and a journey that brought them to where they are today.
The steps above have highlighted some of the methods you can implement today to get your company heading in the right direction to promote a more Agile way of doing things, which will definitely benefit your company and its development processes.