devopsy.kinsta.cloud

Category: Blogs

Multi-Speed IT versus Bimodal IT

I wanted to continue our revue of the recent IBM InterConnect conference in Las Vegas last month. We kicked off the revue with the release of our first videos from the show on Monday. Since then we just updated the YouTube playlist of videos available with a new batch. We will be adding to these in the coming days. For this article I wanted to zero in on a topic that I find interesting and have explored before, namely Multi-Speed IT versus Bimodal IT.

I know that Gartner has led the way in popularizing the term Bimodal IT. Many people have adopted the term to mean that some legacy parts of the IT organization will not be able to operate at the speed of some of the newer DevOps empowered parts of the org. can work at. So it is OK for the different parts to operate at different speeds. You have in essence more than bimodal, but almost bifurcated IT.

My problem with this scenario starts with the Bi in Bimodal. Bi signifies two, as if there were just two parts in this equation. One moves at one speed and the other moves at another speed. In real life there are more than two parts to the organization moving at different speeds. So multi-speed is much more appropriate than Bimodal.

My problem goes beyond just comparing two to many though. I have a problem with thinking legacy systems cannot benefit from DevOps, Agile, Lean, etc. As we have seen, even Big Iron mainframes can be made faster with DevOps. So while different parts of the IT organization can move at different speeds and will naturally do so, it doesn’t mean that legacy systems of record for instance cannot be speeded up using DevOps.

In my view of multi-speed IT the entire organization is more like the gears in a Swiss watch. Different gears of different sizes, moving at different speeds, but all of them orchestrated to mesh together like a fine timepiece.

This brings me back to InterConnect. I had a chance to discuss this very issue with a few people who know a thing or two about mainframes and DevOps. Below is my conversation with Hayden Lindsey, VP of DevOps for Enterprise Systems at IBM:

As you can see Hayden shares many of my views on this subject, but probably even goes a bit further than me calling the premise of Bimodal IT “snake oil”.

Hayden was not the only person I spoke to at InterConnect about this subject either. I had a great conversation with Rosalind Radcliffe, distinguished engineer, enterprise systems at IBM (and one of my favorite interview subjects). Here is what Rosalind had to say:

While this interview covered topics other than multi-speed IT, I have also interviewed Rosalind before on this subject. Rosalind and I actually did a podcast/DevOps chat on this subject as well. You can listen and read along to that one here.

The multi-speed IT versus bimodal IT isn’t just something that IBM sees though. While at InterConnect I also had a chance to sit down with Ralph Van Beek of Rabobank. A Netherlands based bank with operations throughout the world.

Ralph tells us of Rabobank’s DevOps journey in which multi-speed IT plays a big role.

If all of this multi-speed IT versus bimodal IT is not enough for you, we also did a good Google Hangout on this same issue prior to IBM InterConnect 2016. Finally, Sanjeev Sharma, author of DevOps for Dummies, wrote a good piece on this subject right here on DevOps.com that you might find very useful if you are as interested in this subject as I am.

So that should be enough on this subject to satisfy just about everyone. But if you have something to add to this topic please leave a comment or submit your own article to me here at editor@devops.com.

April 1, 2016
The Two-Month Hello World
How Project Onboarding Can Undermine DevOps Efforts at Large Organizations

A “hello world” application is the most basic program a developer, typically a beginner, will write to learn a new language. It’s a sort of “everything works”—a stack-checker app to kick off a project quickly and see its results.

The resulting hello world program is typically a message printed to your screen: “Hello world.” That’s it. No microservices, REST API or class factories, but very satisfying, nonetheless. The stack works; you built it and ran it from scratch.

The average time for a programmer to write a hello world application code is probably a few minutes, or even seconds. The average time to set up the developer’s computer or workstation and servers to be able to compile/build and run a hello world app may take a while longer, maybe a few hours to set up. And I’m thinking cloud server or container. Publishing a hello world app to Google Play, including setup, build and deployment, takes around a few hours for the first-timer. That’s not too bad. But here’s the deal: It’s a few minutes for your first program to run vs. a few hours for your first deployment.

That’s a 60:1 ratio.

Let’s raise the bar a little: Take a large corporation with an IT department of 1,200-plus employees, for example. In that environment the average time to publish a brand new hello world application increases by at least an order of magnitude—even more if the developer is not just onboarding an application but also herself or her team into the organization.

Cutting through IT red tape is a great distraction as epics, user stories and customer requirements pile up. These tasks can be simple to complex, such as setting up your code repository and development stack; identity, security, disk, network and other stack provisions; boilerplate artifacts and following testing and release policies. That’s a considerable chain of requests and wait periods—enough to make that hello world program loop around for months before it reaches production.

DevOps for the Hello World

The ability of a business to respond to market changes start by a quick new-project ramp-up. And in a microservices world that’s often the case. But that’s mostly at the architecture level. How easy is it to provision and manage the external environments beyond microservices? Or, how easy is it to provision and manage the full Dev to Ops stack at your organization, period?

A good way to tackle this is to offer a menu of automated tasks through a help desk-like setup, a configuration catalog if you may. A configuration catalog holds tasks à la carte for every need in the DevOps cycle. Call it the IT user interface for teams requesting or delivering changes to the organization.

This is nothing new. ITIL talks about it everywhere. It’s called a service desk. In a DevOps culture, however, traditional service catalogs do not cope well with continuous deployment and infrastructure-as-code approaches. And vice versa. The reason is that there are plenty of needs that tend to fall outside the common service desk and configuration management automation realms, so they end up in an issue tracker, service ticket or, worst case, plain emails, chat and phone call requests.

From Zero-to-Deploy

A catalog of configuration services can be application or project-oriented and should keep state, knowing what has been requested and delivered in the past to enable future interactions. Every task offered by the catalog has one or more rules associated with it. These rules, or recipes, do the dirty work and automate provisioning, emails, boilerplate setup and other tasks that antecede or surround most of the core DevOps delivery automation.

Think of it as your classic service desk catalog and configuration management tool set combined.

Building a configuration management front end can greatly mitigate and simplify the effort of onboarding applications. Here are some of the features and strategies to consider:
- Baseline Templates: Offer teams a set of baseline configurations, tasks and services that can be provisioned around project typologies, such as “Mobile App,” “Python-Django-Postgres” or “Java-Spring-AngularJS-Oracle DB.” That means that on Day 1 the developer only has to select the preapproved application type to get started. Push-button onboarding should include straightforward guidelines that guarantee that the project starts on the right foot, including committing boilerplate source code to the repository and directory verification.
- Incremental Services: Make the catalog offering incremental, providing development teams only the options they should have at a given time for each project at its given stage. A good configuration system will keep track of what every application has installed at a given point in each environment, so progressive options will be offered.
- Broaden Your Scope: Automate all provisioning tasks in sight. Just because your application is containerized or configuration management is automated it doesn’t mean it’s a push button from start to finish. Reasonably sized applications have many dependencies, approvals and setup steps that are don’t have a place in typical scripted recipes.
- Manual Tasks: Make the work flow by bringing every manual process into the onboarding pipeline and avoid the need for emails. Make sure to cater to non-standard requests also, as that will help keep everything in one place.
- Draft and Versioned Provisioning: Allow provisioning plans to be built along with the code, be it infrastructure-as-code or catalog requests. As new requirements come into play, revise provision drafts accordingly.
- Scale to Environment: For every new environment in the onboarding chain just reapply the previous requests and configurations, but adjust them to that particular stage. For example, a preproduction environment template will probably need to scale CPU, network and memory to closely mimic production.
- Just-in-time: Make sure provisioning happens before code is delivered. If before means just-in-time, great. Maybe it’s just a matter of putting provisioning before deployment in the automation pipeline. Or maybe it’s a non-standard request that needs human intervention and holds up a release for a short time. The closer provisioning looks like continuous deployment, the better.
The next generation of configuration management tools must tackle many different aspects of onboarding applications and services to become an effective DevOps front end. This is not just giving developers a “Request Cloud VM” button but the full how, why and where chain that assists teams with writing boilerplate application and infrastructure code, passing the first build or scaling environments correctly. And moving forward, ChatOps and machine learning are replacing the classic request workflow, adding needed insight and foresight to manage project deliveries from zero-to-deploy.

DevOps practices should start early on in the cycle and offer a great user experience all the way through. A good delivery chain needs to tackle the newcomer workflow, just like the application interfaces of today tend to target first-time users. A friendly and capable DevOps front end is what separates mature organizations from the rest, helping them smoke the from-hello-world-to-deploy test suite gracefully.

About the Author/Rodrigo González

Rodrigo Gonzalez is the CEO and co-founder of Clarive. Besides running the day-to-day operations, Rodrigo oversees the overall strategy for the company. Rodrigo, originally from Brazil, holds a B.S. in Computer Science from Texas Tech University and has nearly 20 years experience working at tech companies in the United States, Brazil and across Europe, including Lucent Technologies and CA Inc.
March 31, 2016
IT Organization: Blend, Don’t Divide
Bi-modal is the new normal, but the best way to approach this is to blend operations, not create separate groups.

There’s been much ado lately about the transition of enterprise IT from traditional, steady operations to a highly agile and services-based operation. Companies of all sizes are moving to the cloud and adopting DevOps, yet many must maintain legacy systems for years to come. Pundits and analysts such as Gartner suggest that CIOs need to split their organizations into two: the Mode 1 group (traditional, “lights on” operations) and Mode 2 (the business-innovating group). In fact, Gartner is so bullish on this idea that the research firm is predicting that 72 percent of enterprises will be operating in a bimodal structure by 2017.

Yet dividing and conquering won’t work. By creating two separate groups, with likely two different leaders, there’s bound to be tension and turf wars. Overlap of duties will happen, and higher costs may result. Regardless, the two groups will still need to work together—but may have little incentive to do so.

Let’s take a step back. Bimodal is just another name for transitions that IT organizations have been through many times in the past: analog vs. digital, mainframe vs. client/server, batch vs. interactive, native vs. web-based, on-premises vs. cloud and so on. Creating walls between existing and emerging processes and technologies doesn’t make much sense. It’s possible to manage “old” and the “new” requirements and projects in tangent.

Instead of creating walls, Mode 1 and Mode 2 processes can coexist and employees with different perspectives can help each other as the company transitions to its next phase of innovation. Over time, the entire organization will shift to the most progressive, efficient and business-aligned way of delivering IT.

IT organizations should think more holistically about building cross-functional teams made up of the best members to serve that team’s particular purpose. Those teams may have mobile app developers and DevOps managers sitting side by side with network engineers and system architects who have developed deep specialties in enterprise databases and data center infrastructure over many years. There may be Waterfall teams and DevOps teams, and individuals managing cloud providers working closely with data center managers implementing converged infrastructure. It all begins with the business requirements and designing a strategy that is inclusive of both required legacy systems and future, cloud-based initiatives.

But wait, aren’t the most progressive companies Mode 2 from top to bottom? The answer is no. Companies such as Amazon, Google, Netflix, Facebook, Apple and LinkedIn are IT innovators that also manage solid and stable internal environments.

It was only in mid-2015 that Apple announced its migration of the Siri application platform to the Apache Mesos platform. This didn’t happen overnight. The team responsible for Siri realized that it could cut costs and increase flexibility for ongoing support and development. It was an evolutionary move focused on front-end scalability and allowing a clustered approach for scale and management—arguably a very Mode 2 approach. That said, it’s also widely known that the data sources for Siri are a mix of traditional RDBMS and No-SQL—massive data repositories handling millions of transactions 24/7. These platforms require Mode 1, utility-grade availability constructs.

LinkedIn is another innovator running a distributed architecture that blends Mode 1 technologies (data layer and business engines) with Mode 2 clusters focused on presentation of new and existing initiatives.

Ways to Blend Effectively

Here are some ways to approach a blended IT organization that incorporate both Mode 1 and 2 technologies and processes without building walls:
1. Create a best-of-breed environment. Evaluate your applications and create an architecture plan. Identify existing applications that require modernization. Create a clear picture of the gap between current and desired state. Build an architecture for your applications that leverages one or more platforms that can adapt to your application architecture goals, both present and future.
2. Balance out your weakness. Most large companies in traditional industries will be heavier on the Mode 1 orientation regarding skill sets, tools and processes. To jump-start a transition toward Mode 2 operations, consider hiring people from software startups with ample experience developing, scaling and maintaining cloud-based systems under rapid time frames. These are the people whose failures bring the perspective necessary to empathize with your Mode 1 teams. They might even appreciate the Mode 1 team’s experience.
  Conversely, if your organization is already a strong Mode 2 operation, know that scaling your business will require you to embrace Mode 1 skills to maintain reliability and consistent user experience as demand grows unpredictably. Ideally, find someone with a large enterprise background that has experience delivering reliability for new, web-scale applications.
1. Don’t force new methods. DevOps, a technique for infrastructure management in support of rapid delivery of applications services that is generally considered to be well-suited for Mode 2 applications, may not retrofit to every situation. For example, one can write code to manage infrastructure systems that expand and contract with the proliferation of application containers. While well-suited for the container-based application model, many of the coding concepts associated can be too complex for scripting the deployment of a multi-tier Mode 1 application. The layers and complexities of the scripting don’t provide enough return on the time invested to justify the upfront efforts. Leveraging a purpose-built automation engine or simply deploying manually likely makes more sense today. Choose the technique that best serves the initiative, not the one that seems the newest and coolest.
Rather than getting hung up on how to reorganize IT departments, a better use of time is to determine how to blend the best of the old and the new. IT organizations today are frequently in a state of transition, given the pace of new technological developments. By merging tried-and-true tools and practices that deliver stability with the latest innovations for web-scale business models, companies can move quickly in their respective markets without sacrificing business longevity.

About the Author/Steve McDonald

Steve McDonald is Vice President of Product at StrataCloud, developer of a platform for software-defining enterprise data centers. Over the past 15-plus years, McDonald has led cross-functional teams in the delivery of innovative business initiatives, most recently at Softchoice, where he a managed a team of business development and pre-sales professionals in the United States and Canada focused on the profitable growth of the entire Cisco portfolio as well the networking category overall.
March 31, 2016
Return on Investment

— ROELBOB

March 31, 2016
Webinars: Where’s the heat: Top DevOps Use Cases in 2016
Adopting DevOps is a journey, and for many organizations the journey has just begun. What use cases are they solving first? How are they solving them? And what kind of benefits are they realizing?

Join industry analyst Amy DeMartine (Forrester) and General Manager and Vice President of Deployment Solutions Wesley Pullen (Electric Cloud) as they discuss the state of the market, and the critical capabilities organizations must have in order to accelerate their DevOps initiatives.

In this webinar you will learn about:
- Orchestrating the DevOps Toolchain
- Application Release Automation
- Compliance and Auditability
```
Recorded 3/29/16
```
Recording

Slides

[seoslides embed_id=”d410e5e551bc” script_src=”https://devopsy.kinsta.cloud/embed-script/wheres-heat-devops/14334/” overview_src=”https://devopsy.kinsta.cloud/slides/wheres-heat-devops/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Wheres the Heat in DevOps” /]
March 30, 2016
Culture Change: Metrics, Tools Make a Difference
Change is in the wind.

This time of the year, as winter weather gives way to springtime renewal, this concept isn’t a cliché but rather a concrete, visceral experience. You go outside, smell the earth defrosting and know for certain that change is happening all around you. You can feel it.

Such is the case on the current DevOps landscape. Seemingly every conversation, with everyone from end users to industry analysts, reaffirms that people are making significant progress toward greater adoption. For an increasing number of organizations, DevOps is maturing from a set of budding goals into a tangible reality.

At the center of this massive shift within the software factory is the issue of cultural change; as we know in all things DevOps, culture trumps all else. So how are organizations affecting, empowering and measuring all this seismic transition, in particular the human elements?

During the recent DevOps Virtual Summit, leading practitioners representing industries ranging from banking to travel and technology shared their views on the progress of cultural reinvention.

From management tips, to tools and even metrics useful for driving transformation, here are some of their observations:
1. What’s the most critical cultural aspect of planning?
  Kazi Whitfield, director, Quality Engineering, MUFG Union Bank, N.A.: Scalability on this is the key; if you’re doing this at a new organization, you need to understand how to scale it, and starting at some smaller level helps you get there. It also helps each individual and those components that are changing to truly understand what’s changing, and why it’s changing; I think that’s a huge part of the conversation that has to happen.
1. What’s the biggest obstacle to cultural change?
  Eric Warheit, senior manager, Environment Management, Southwest Airlines: The challenges that we’re working through are organizational in nature. It goes back to the question of localization, and people maintaining a mindset that they’ve previously had, and what we do to create the conversation around what’s possible and the key impacts that we want to have. Ultimately, it’s about being productive with quality, and creating those common values.
1. How can tools enable cultural change?
  Eugene “Bear” Lehenbauer, group manager, Information Technology, Citrix: If I have to pick one that links them all, a ring to rule them all, that’s when you have an orchestration platform that can take what individual teams are already using and plug right in, or you can take what needs to be automated and automate it; that orchestration harness can now become that common thing that links them.
1. How can you ensure cross-culture collaboration?
  Warheit: Creating that concrete example, that proof case tying analytics to it, so that we have real measurable ways to make good business decisions, and being able to foster that perspective so that we can look across the organization, as opposed to in a localized way, is really critical to be able to foment that collaboration that’s needed.
1. How do you measure cultural change?
  Daniele Romano, product owner, Continuous Delivery Pipeline, ING Bank: The most important thing as an organization is to able to apply an analytical approach, meaning that for each team or department you should look at the current situation and have in mind the target situation, and then have different means to guide everyone toward that target.
1. What’s a key cultural change metric?
  Lehenbauer: We’ve a developed an agility rating scale that allows people to earn scores for something as basic as change management. Based on how those key metrics behave, and there are several of them, but they are fact-based and they’re user impact driven for the most part, they reward the right behaviors. Those types of things can draw out some of DevOps principles results, but also have hard data behind them.
1. How do you recognize advocates of cultural change?
  Whitfield: Being able to phase reward and recognition into the process is key. Organizations are doing a lot of great things and making millions of dollars, and as the individuals that are coding or testing are driving it, you have to understand how you get to those people’s hearts, to make them passionate about what they’re doing. That’s something that becomes key and it’s something that’s different per organization.
1. What’s the best way to gauge successful cultural transformation?
  Romano: There is a really only one critical human metric, which is happiness. So, if engineers are happy and they can deliver fast, at a high quality and with intense focus—that’s a very unique but important metric.
So there you have it, some of today’s most critical elements in driving the cultural transformation necessary to succeed in the DevOps world.

If you missed the DevOps Virtual Summit you can still view recordings of all the sessions including this customer panel, and stay tuned to this space for more excerpts and highlights.
March 30, 2016
Digital Transformation Strains Traditional IT

It’s hard to believe, but it’s almost been 13 years since Nicholas G. Carr wrote his famous essay, “IT Doesn’t Matter.” In that column Carr argued that IT had become so pervasive in enterprises and so widely used that it had essentially become a commodity and was no longer useful as a tool for business differentiation.

“Behind the change in thinking lies a simple assumption: that as IT’s potency and ubiquity have increased, so too has its strategic value. It’s a reasonable assumption, even an intuitive one. But it’s mistaken. What makes a resource truly strategic—what gives it the capacity to be the basis for a sustained competitive advantage—is not ubiquity but scarcity,” Carr wrote.

If that sentiment was accurate then, and I wasn’t convinced it was at the time, it’s not accurate anymore. Today, how enterprises are building and implementing IT is a clear differentiator when it comes to delivering apps business users and customers need and want, built and designed in ways they want to interact, and delivered in a timely manner.

According to a recent report published by Salesforce, “2016 State of IT,” IT leaders are focusing on mobile apps, migration to the cloud, as well as building adequate cybersecurity/incident response, customer-facing digital apps and productivity apps. The report found that 68 percent of respondents said that they are increasing their budgets on mobile apps, cloud and security. The lion’s share of respondents also plan to increase their budgets allocated to cybersecurity (63 percent) while 62 percent will spend more on employee productivity apps.

The report survey, conducted at the end of 2015, is based on responses from 2,255 CIOs and IT leaders from within the United States, Canada, Brazil, Australia, Japan, France, the United Kingdom and Germany. One of the first things to leap out at me from the results is, based on my interviews with many enterprise users, this increased focus on mobile apps and employee productivity apps will certainly be welcome in most enterprises—mobile app backlogs are a problem in many organizations today, as we covered in “Make ‘Mobile First’ an Innovation Strategy,” “Mobile App Development Will Soon Grow More Enterprise-Focused,” and “For More Mobile Wins, Enterprises Must Find their MVPs.”

As IT leadership had to do in every other transformative period (and cloud, mobile, data analytics are all transformative) such as the displacement of mainframes by PCs in the 1980s, the rise of the local area network and the arrival of the commercial web in the 1990s, IT is at the center of business strategy. CIOs and IT leadership need to make sure they get themselves out in front of these trends and align the services technologies they are delivering with what their users need. According to the report, this need for IT to drive innovation is forcing leadership to rethink their IT organizations. And, as a result, according to the “State of IT” report, to help address this, 60 percent of enterprises now have a relatively new position in the chief digital officer.

Of course, as this push by enterprises continue, the competition for talent heats up. According to the “State of IT” report, the IT skills demand gap is widening: there just isn’t enough talent to go around. I expect this to grow worse as these enterprise budgets for mobile apps only continue to grow in the years ahead. And one-third of those surveyed in this report said that they are having a painful time keeping skills relevant with emerging trends in cloud, mobile and data analytics. Seventy-two percent say talent/IT skills development and training will be absolutely critical or very important for their team in the next five to eight years.

According to this eWeek story, “How the Skills Gap Is Threatening the Growth of App Economy,” while nearly 80 percent of respondents of a CA-sponsored study, “The Battle for Competitive Advantage in the App Economy,” said that becoming a “software-driven enterprise” is a top priority, the biggest challenge they have in realizing that goal is the skills shortage. The top four critical skills in that survey close resemble the findings in the “State of IT” survey: data science, collaboration, DevOps and APIs.

The research firm Gartner predicts that by the end of 2017 demand for mobile app development services will grow no less than five times faster than the capacity of internal IT organizations’ deliver mobile apps. With steady mobile phone sales continuing to fuel demands for enterprise mobile apps, the result will be, according to Gartner analyst Adrian Leow, that enterprises will have a hard time rapidly developing, deploying and maintaining mobile apps to meet demand because of the scarcity of developers with good mobile coding and development skills.

“Organizations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic,” Leow said in this statement. “We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging.”

IT leaders are also seeing demand outstrip supply of those with skills in IT security and data engineering and data science—and there’s no sign of a letup in any of these disciplines. Considering all of that, and what Carr write 13 years ago, parts of IT may very well have become commodities—especially at the infrastructure layer of the IT stack. Just don’t try and sell that view to anyone trying to clear their mobile app backlogs or get the most value out of their data today. They’re too busy trying to keep up and hopefully innovate a little to have time to listen.

March 30, 2016
Herding Kittens: Developer Tools Trends From Our Survey
Back in late February we launched our latest survey in partnership with Automic. The survey sought to understand how developer tools are selected and used within organizations. We wanted to have some insight into how prevalent Shadow IT was. Well thanks to the hundreds of you who responded, we have been busy working with Automic analyzing the results. Frankly in some areas the responses bore out our original hypothesis, but in other ones the results were pretty surprising.

Not to be a tease, I should tell you we are not releasing the full report and results until our webinar on this on May 4th. You can register for that one here. But let me give you some insight into some of the results:
1. A big difference between DevOps empowered organizations versus traditional IT shops. We actually ran the survey to both our DevOps.com audience and then to a general IT control group and had a look at the differences. DevOps empowered groups had far greater insight into what tools were being used, generally used more tools, more open source tools and generally had greater diversity (that they knew about anyway).
2. The large majority of respondents reported that their organization use tools besides those on the “approved list”. This is a form of Shadow IT and shows how new software tools are sneaked in under the radar of the official IT.
3. Many times these tools that snuck in the back door were eventually adopted as official tools, showing that this is a viable method of introducing new tools into the organization.
4. Another insight was whether entire dev teams were using the same toolset. This answer as you might imagine was different when you compared organization sizes. However, overall the message is that developers like to use their chosen tools.
These are just some of the insights we will be discussing at the webinar. Also all attendees will receive a full copy of the report with analysis. So mark your calendars now and register for the webinar where we will discuss these results and more.

BTW, the webinar will feature myself and Kerry Lebel, senior director of community for Automic.

Scott Willson

Scott Willson is Product Marketing Director, Release Automation at Automic Software. He has over 20 years of technology experience that spans software development, pre-sales, post sales, and marketing. Scott is passionate about technology and helping business achieve value through technology and was leading DevOps at organizations before it was coined DevOps.
March 30, 2016
How to Determine Enterprise Security Vulnerability

— ROELBOB

March 30, 2016
Our Sprint to Agile Success
Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

A change is needed.

Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

Our Perception Was Wrong

When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

This is what brought us back to the drawing board.

Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

Renewed Focus

Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:
- Adoption of sprints
- Open communication
- Version tracking
- Environment of continuous testing
- Responsibility definition
None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

The Daily Sprint Meeting

In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:
1. What did I accomplish yesterday?
2. What will I achieve today?
3. What obstacles do I face to accomplish my projects?
4. How am I feeling today?
With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

About the Author/Logan Rivenes

Logan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
Twitter: @loganrivenes

LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a
March 29, 2016