Essential Steps to Become Agile - Part 3
April 07, 2017

DEVOPSdigest asked experts across the industry — including analysts, consultants and vendors — for their opinions on the best way for a development or DevOps team to become more Agile. Part 3 provides some tips for getting started and gaining feedback.

Start with Essential Steps to Become Agile - Part 1

Start with Essential Steps to Become Agile - Part 2

THINK SMALL

The best way for a development team, DevOps team, or IT organization to become more Agile is to "think small." Smaller software components with limited but well-defined functionality are easy to create and, over time, provide a larger tool set from which newer projects and products can be created rapidly by reusing existing components. In other words, the quest for agility is a disciplined process that starts slowly but, when done right, accelerates overtime to create a winning team.
Amir Sharif
Co-Founder, Aporeto

Size is the number one thing to look at. Who's more Agile, a sumo wrestler or Usain Bolt? In traditional IT; projects, teams and releases tend to be huge, like the sumo wrestler. To become more Agile, IT organizations need to shift the paradigm toward smaller. Smaller projects, smaller teams, smaller releases, smaller changes. Think of it as putting everyone on a diet while also learning new skills, such as breaking down a project into sprints as opposed to the traditional phases. Breaking down changes into the smallest meaningful size is the starting point on the journey to Agile and DevOps.
John Jeremiah
Senior Product Marketing Manager, Hewlett Packard Enterprise

Agile transformations die of gluttony, not starvation. Attempting to make too many changes too broadly is the fastest way to fail. Set yourself up for success by starting small, with a capable group of A-players working on a mission-critical project (preferably a new one). That may sound scary, but experimenting on a mission-critical project will ensure intensity and focus are maintained until success is achieved, and limiting experimentation to a smaller group at first will help you more quickly uncover the patterns and practices that will work for the whole team later.
Pete Pickerill
VP of Products and Co-Founder, Datical

Don't try to boil the ocean. Start with a small project and thus a small team; three to four people max, including one Operations person. The key is to get used to a new way of working focused on iterative development and rapid deployment in a test-and-learn approach. To help, use cloud technologies like application Platform-as-a-Service (aPaaS) that minimize technical considerations (e.g. infrastructure, patching, configuration management, etc.), enabling the team to focus on user needs and quickly delivering business value.
Roald Kruit
Co-Founder, Mendix

In my opinion, shifting to Agile is easier than what some organizations may think. Overall, making deliveries smaller is key for a successful Agile workflow, it's easier to steer a small boat and fix its course than changing a huge ship's course which requires much more preparations and resources. The main technological challenge is to identify what pieces of technology hinder the Agile process and replace them with modern solutions. A great example from my point of view would be source code analysis. SCA used to be a long process designed purely for waterfall concepts, however, not many solutions have adapted their products to work in fast paced Agile environments so making sure your SCA solution can keep up with short development cycles is critical for your Agile development process.
Amit Ashbel
Cyber Security Evangelist, Checkmarx

THINK LEAN

Teams or IT organizations that want to become more Agile need to first develop a lean thinking mindset that fights departmentalized, traditional batch-and-queue thinking.
Mark Levy
Director of Strategy, Micro Focus

HOLISTIC VIEW OF PRODUCTION ENVIRONMENT

Becoming Agile is not just about moving faster, but combining speed with quality. No software is bug-free, so catching things early in the development and test cycle minimizes the need for re-works later, while improving the quality of releases. More often dev/test teams have very siloed access to capabilities and don't have a holistic view of the environment to fully understand and appreciate how and where their code lives and the impact it has in a production environment. Exposing them to holistic replicas of a production environment early on in the cycle can have a tremendous impact on agility, especially if it can also factor in performance, scale, reliability testing in the mix. Further, standardization of development and test processes with blueprints, self-service catalogues and snapshot mechanisms can provide portability and acceleration of processes contributing to true agility.
Shashi Kiran
CMO, Quali

MODEL VALUE STREAM UP FRONT

After initial success with Agile on smaller, less complex projects, it can be challenging to scale processes to support the organization more broadly. We frequently see organizations with Agile projects or teams that are faced with explicitly connecting their work to business objectives, to ensuring that all regulatory and compliance requirements have been considered, and to aligning every member of their large, distributed teams to a common understanding of the solution design. Organizations can optimize value, align to business objectives, and find opportunities for automation and ultimately deployment speed by modeling the entire value stream up front and making this view broadly available to all Agile team members and stakeholders.
Tony Higgins
VP Product Development, Blueprint

BUSINESS REQUIREMENTS DOCUMENT

Agile is not just a word but a way of life. One common misconception about implementing Agile is that the Business Requirements Document or "BRD" is no longer a critical artifact in the process. A business requirements document is like a blue print for a house - critical for success regardless of development methodology. Agile is about adjusting based on user feedback early and often to achieve desired objectives. Unlike a Waterfall BRD the Agile BRD provides the baseline or frame for the overarching requirements. It defines key characteristics around Reliability, Availability, Serviceability, Supportability, Scalability, and Security needed from the core business capabilities to achieve the desired business case results. The Agile BRD helps drive definition of critical elements that could impact the quality, time, and resources required to deliver a minimum viable product. It has been cited as an essential ingredient to forcing people to slow down, take the time to understand the context, content, and users, and then speed up production. Services built without a BRD is like building a house without a blueprint. You may get to the final point but it will be over time, budget, and lacking quality to make your customers happy or completely miss the mark all together like the Winchester Mystery House in San Jose.
Jeanne Morain
Author and Strategist, iSpeak Cloud

FOCUS ON PAIN POINTS

There is no magical route to making a company Agile, and managers or IT teams need to be able to look at their unique setups and goals. The first thing I would recommend is for companies to try and find the largest pain point from the outset, and improve practices regarding that pain point. So for example, if frequent technical issues persist, then teams should look to improve those practices in particular (TDD, CI, pair programming, etc). Once the team has a strong sense of the obstacles it faces, it's worthwhile to adopt a management suite focused on Business Processes, Application Lifecycle, or Project Management - whatever is most needed by that specific company.
Russell Rothstein
Founder and CEO, IT Central Station

CONTINUOUS FEEDBACK

To become Agile, everyone in your organization needs to feel like an empowered and crucial contributor. One of the most direct and productive ways of making this happen is by fostering opportunities for direct collaboration between engineers and customers in customer messaging platforms, in other transparent chats, in knowledge centers, and in community forum discussions. The feedback you collect and the knowledge of your customers you gain from this experience, keeps your organization focused on your customers and their needs. This focus transforms problem-solving and implementation, letting you quickly and efficiently release the new products and features that your customers want.
Berkay Mollamustafaoglu
CEO, OpsGenie

Agile is all about fast iterations and the continuous feedback. However, teams adopting the Agile mindset often get lost in the first half of the equation and end up focusing only on fast iterations. The downside of adopting just the iterative development is in not understanding whether or not the delivered solution is valuable and/or correct. We encourage teams to change this and start thinking about processes and tools to incorporate regular feedback from end users into their everyday work. There are many different ways of achieving this, ranging from customer surveys and surveillance to monitoring end user experience of production deployments. Understanding how end users use the applications is an eye-opener for every product manager. As a result, products will become easier to use, contain less flaws and allow the end users to accomplish their goals faster.
Ivo Mägi
Co-Founder and VP Product, Plumbr

It is important to ensure that all participants in the new Agile implementation can provide feedback. When you have input into a process, change becomes easier to understand and embrace.
Paul Mansfield
CTO, iQuate

FAST FEEDBACK LOOPS

Reduce the time between concept and cash - get that feedback loop down to a minimum to ensure you're able to react and respond to changing priorities, new technologies and new challenges. The closer you are to your end-users, the more you can learn and adapt. This is the essence of agility.
James Betteley
DevOps Evangelist, DevOpsGuys

Shortened feedback loops are at the heart of Agile software development. Finding ways to reduce friction in the delivery and support of software and infrastructure requires constant monitoring of real-time changes and adjusting accordingly. Lengthy defining, planning, developing, and operating cycles lead to wasted efforts when an immediate change in direction or focus inevitably becomes a reality. Focusing on shortening each of these phases and constantly monitoring for necessary changes at any given moment is the most effective way of becoming Agile.
Jason Hand
DevOps Evangelist, VictorOps

A key to increasing agility is getting participants in the process acclimated to faster feedback loops. Speed solves many issues indirectly by causing participants to seek out solutions to keep up the pace, deploying code sooner rather than later, and pushing out smaller features earlier rather than large batches of features in longer cycles. A curious side-effect of this is that it can actually increase reliability, because tooling and automation for software within organizations has to be continuously automated instead of infrequent manual efforts.
Eric Sigler
Head of DevOps, PagerDuty

Read Essential Steps to Become Agile - Part 4, covering DevOps technologies.

Share this