devopsy.kinsta.cloud

Tag: agile

Building a Bridge from Agile to DevOps, Scrum.org Partners with the DevOps Institute
Scrum.org, which is dedicated to improving the profession of software delivery, and the DevOps Institute, which is dedicated to fostering a community around emerging practices in Continuous Delivery and DevOps, today announced an alliance that seeks to build a bridge from agile to DevOps. It will include scrum teams, agile practices and DevOps. I think this partnership could have huge implications for both the Agile/Scrum and DevOps communities.

Let me say from the outset that I am a co-founder of the DevOps Institute, so feel free to take what I am saying (or writing) with a grain of salt. I also have been involved in the formation of this partnership since its initiation. From then until now, I remain convinced that this is a critical step in making software development and delivery better for us all.

My fellow co-founder at the DevOps Institute, Jayne Groll, perhaps says it better: “There is an inherent organic relationship between Scrum and DevOps. By demonstrating how to improve the collaboration, integration and communication between IT’s roles, frameworks, practices and automation, we pave the way for end-to-end organizational agility and a faster flow from idea to value.”

While formulating this partnership, I have had the chance to meet and work with some incredible people over at Scrum.org. One of them is Dave West, CEO of Scrum.org. When I first met Dave (you can hear a podcast of that here), he was just formulating his ideas around Agile/Scrum and DevOps being intrinsically linked. Since then, Dave has seen a clear path for this linking and has embraced and enunciated it well. “Scrum without DevOps is impossible to scale. Work needs to flow seamlessly from the Scrum team to production and back again,” Dave says. “It is funny that great Scrum teams have to do DevOps to be great and great DevOps teams use an agile approach like Scrum to enable better collaboration.”

For me, the real value of this partnership is, as Dave so eloquently states: “I am always shocked that the DevOps community are often seen as different from the agile and Scrum communities, when the reality is that agile and DevOps encourage breaking down those barriers to deliver customer value.”

At the end of the day that is really what this is all about. The partnership is not just about Scrum.org and the DOI as institutions & organizations—the partnership really has to be about the community of IT professionals who adhere to and practice Agile/Scrum and DevOps.

As I like to tell people, there is only one truth. There is not a separate set of facts that apply to Agile/Scrum and another set that apply to DevOps. There is not a separate truth that applies to enterprises and another truth that applies only to startups. There is only one truth. If it is truth, it is true. I look forward to this partnership illuminating and standardizing on this one truth.

By the way, this alliance is just the beginning. I believe that this “one truth” philosophy applies beyond Scrum and DevOps. I think it also applies to ITSM, security and other IT disciplines. Bringing together a common set of best practices and way of doing things across these is inevitable.

We have crossed a boundary in IT. As I write this, I am at the InfoSec World conference in Orlando. My friend Rich Mogull is delivering a keynote where he is talking about how infrastructure as a service, software as a service and the new reality of ubiquitous, safer endpoints and connectivity are changing the mission of the security professional. These same factors are changing the mission of the Agile/Scrum developer and the DevOps team member. It is a great time to be in IT.

But it also calls for forward-thinking organizations to recognize, adopt, adapt and evolve. I think this is a great opportunity for organizations like Scrum.org and the DevOps Institute to help lay out a path for common learning and uniting communities. That is what really gets me so excited about this partnership.

So what are ways for you to find out more and be involved in this? Well, it starts April 26 in Dallas at the DevOps Connect conference. Dave and Jayne will be delivering a joint keynote and a full afternoon workshop. These sessions will be listed under the “ScrumOps” moniker. If you are in Dallas or can get there to attend DevOps Connect, please do so.

Dave’s blog lists some other ways this partnership will work together:
- Consistently describe the ideas of each body of knowledge through Scrum.org and DevOps Institute classes and certifications – providing consistent words and concepts to help ensure that both groups can share a common dialogue.
- Shared events that bring together the two audiences to create an environment that allows ideas to be exchanged and new ones to grow. It has always seemed odd that DevOps and Scrum/Agile events are separate. It is crucial that the two groups work together and that we as one.
- Invest in a growing body of thought leadership. Scrum has a very precise, documented body of knowledge with the Scrum Guide, but there is much ‘mystic’ in the DevOps and agile community about certain terms and ideas. DevOps Institute is already working with DevOps Express on building standard patterns and terminology. By working with the DevOps Institute, we can start bringing in the concepts of professional Scrum so that the entire software delivery team can work together as one.
So stay tuned for more info on this partnership in the coming weeks and months. In the meantime, today is the first day of Scrum/DevOps working together in ScrumOps.

— Alan Shimel
April 4, 2017
Scaled Agile: Faster Feature Cycle Time, Improved Time to Value

Do you remember when the business imperative was improving feature cycle time? As if we just needed to deliver more stuff faster to win in the marketplace. I wouldn’t say that times have changed, but I would say we were just scratching the surface, and rightfully so. After all, we have to start somewhere. The adoption of agile methodologies have proven successful in helping redefine the characteristics and behavior of development teams and, in the process, have certainly helped speed feature delivery cycle time. Great! Is your business more successful now?

Our goal then, and now, should have been to improve time to value. What good is it to deliver more stuff faster if it’s not the right stuff? How do you know whether it’s the right stuff? How do you make smarter decisions so that you know?

Agile & Lean at Scale

The Agile Manifesto explains the key tenets of agile transformations that lead us to this thought: It’s all about value, vision and quality—and rethinking what quality means—in terms of customer value. I didn’t make this up … a team of really smart people from different organizations and industries collaborated and the result is a truly inspiring set of guidance to help teams focus to deliver faster, smarter and better. The thing is, without adopting this guidance at scale, without thinking about what value means and how to prioritize investments into the delivery of value from the top down, we’re back to the same old decision-making process that often takes us off track.

Business owners, portfolio managers, analysts, solution architects, product managers … all of these roles that operate largely on the “business” side need to think lean and agile and collaborate with engineering continuously to drive the organization as a whole to work faster, smarter, better. Aristotle said: “The whole is greater than the sum of its parts.” Think about that in terms of creating a unified, collaborative organization that marches to the same drum beat, uses the same language, follows the same process to make decisions and drive change. Regardless of whether you are operating at the portfolio or team level, or somewhere in between, you are essentially planning and executing, planning and executing. Your deliverables may be different but the goal is the same: deliver value faster, get feedback, rinse and repeat.

Addressing the Whole Transformation

Convinced? Maybe just intrigued? Fair enough. Let’s talk about how to do this, starting with my warning: Change is hard, especially when you’re trying to transform the mindset of an organization and do real work at the same time, so it’s not for the weak or meek. I’m not trying to scare you, just making sure you enter this with eyes wide open.

With that out of the way, let me enforce the need to consider the whole transformation to be successful; this is not just about the process and it’s even less about the tools that support that process. It’s about the cultural change, first and foremost. There is no tool or magic pill for that. A well-defined, cohesive process is key, however, in uniting the tribes, so in this way it helps with the culture issue. Finally, embedding a well-defined process in tooling just makes things easier because you knock off the requirements related to collaboration, traceability and reporting with the tooling. Remember: people, process, tools.

SAFe is the Recipe

So what scaled agile process should you use? Well, I can tell you that you do not need to develop your own process, there are several out there. I favor the Scaled Agile Framework (SAFe) for a number of reasons: it is extremely well-defined, it covers nearly any size and complexity, and it is flexible despite what some may think. At the same time, it’s just a framework—there is no one size fits all and you do not have to adopt every aspect. But you don’t need to start from scratch, either. Be smart about this and take advantage of the invaluable insight that went into the development of SAFe 4.0. My team has done that and I’ve worked with several large enterprise organizations that have as well.

I love analogies to illustrate a point and simplify what might otherwise be complex, so let me leave you with this one: scaled agile transformations are like cooking. Start with a simple recipe (especially if you’re an inexperienced cook), learn the art and how to adjust seasoning as you go, and fine-tune the dish after feedback from your family. Then try it again. Do you get it? Same with scaled agile: Start with a good framework (SAFe), learn about it, take what is valuable from it for your organizational needs and try it out for an iteration, get feedback from your team and make adjustments to the process for the next iteration. Simple.

Please visit our SAFe landing page on jazz.net for all things “SAFe”! We are here to help you with your scaled agile transformation (SAFe or not), so don’t hesitate to reach out.

The IBM SAFe Team (safeinfo@bg.vnet.ibm.com)

About the Author/ Amy Silberbauer

Amy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Watson IoT line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 29 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework) transformations.

Connect with Amy on LinkedIn.

March 20, 2017
CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery
And now, for Episode 3 … you decide if it beats “Star Wars – Revenge of the Sith.”

I think we accidentally just set the bar pretty low, but …

… here we go. Let’s begin with a prerequisite pithy quote from an objective industry observer:

“If agile software development was the opening act to a great performance, continuous delivery is the headliner,” according to Kurt Bittner of Forrester Research.

Kurt explains this concept further by saying, “The pace at which consumers expect change is causing a crisis in application development and delivery … agile was a good start, but it wasn’t sufficient to drive better business results; continuous delivery forges the broken link in the value chain, connecting business strategy with business results.”

So there, you have it. At least according to Forrester, continuous delivery (CD) is one of the most important evolutions of agile methodology within the modern software factory. But, there’s more.

Andrew Binstock from Dr. Dobbs fairly well echoes this sentiment, saying: “It’s becoming clear that agile alone is no longer sufficient to keep up with the demands of the present day … software complexity and the need for constant updates are making it difficult for leading edge organizations to keep up without moving beyond agile and embracing continuous delivery.”

Episode 3 of our podcast series discusses the importance of Agile Transformation along WITH Continuous Delivery to automated some of the development, test, and release efforts to remove some of the bottlenecks downstream in the software development life cycle in the build, test and release phases.

Lean Agile + CD can create these 1+1=3 types of results.

Episode 3 of the Continuous Delivery 101 Podcast can be found by:
- Listening to it on your computer on YouTube
- Downloading it from iTunes store
- Downloading the podcast from your Podcast App by searching for “Continuous Delivery 101 podcast”
Thanks for listening!

— Scott Edwards
March 13, 2017
Why Financial Companies Love Continuous Delivery
The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

“We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:
- Bank of America: “Here to help connect you to what matters most.”
- ING: “Empowering people to stay a step ahead in life and in business.”
- MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”
Financial Companies Love Their Customers

My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

Getting the Pulse of Fintech Continuous Delivery Adoption

But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

How Continuous Delivery Helps Fintech Win

Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:
- Delivering features and updates that customers need when they need them
- Delivering applications that meet performance and quality expectations of customers
- Delivering secure, compliant applications (for external and internal customers)
Continuous delivery enables continuous devotion to the customer experience.

Continuous Release: Fast Customer Response

With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

Continuous Testing: Building in Quality

In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

Continuous Compliance: Audit-Ready Processes

Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

Customer Satisfaction Through Automation

Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

— Patricia Johnson
March 2, 2017
Be Here Now – Agile and DevOps in the Current State of Synergy

If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

Register today for the 3^rd Annual DevOps Virtual Summit.

With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

Point being, we’re still pretty early.

That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

So this begs the two-part question – where do we really stand, and what do I really need to care about?

The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

On Tuesday Mar. 7, we’ll host just such an event, the 3^rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

Register for the event and join us to find out where agile and DevOps actually stand today.

— Matt Hines

February 22, 2017
Using DevOps for Non-Code Artifacts
Figure: Linking various aspects for an article that can be connected through the “DevOps way of working”

Innovation lies at the intersection of two or more otherwise-non-related areas. A very intriguing such instance I recently read was of Charles Babbage and Ada Lovelace setting up the foundation of the modern programmable computer by taking the punch card from the loom industry and applying it to their analytical machine (see: Wikipedia or refer to the book, “The Innovators“). There have been numerous cases where one industry has taken up the best practices of another industry and aligned it to work well in a new use case. We don’t have to go far to look at such examples; the IT industry has picked up a lot of manufacturing industry best practices such lean and Kanban.

Today a lot is being talked about DevOps in the IT world as the new model of software development and support. The DevOps way is being adopted by various teams and everybody is exploring how they can adopt it in their environment. Can we break down the “DevOps way” and extend its principles to some other areas of work?

DevOps in its simplest definition serves one purpose: Enabling businesses to reach their consumers faster with innovations and new offerings, enabled by tools and automation. By incorporating lean principles, automating various steps and bringing all the stakeholders closer (biz-dev-test-sec-ops), the life cycle is aligned to release continuously. The main objective is to have a releasable version always ready to be pulled, rather than wait for long periods before the next increment is available. That way, releasing it for the end users becomes a simple business call and a non-event.

How can we extend the DevOps principles to the benefit of other business functions?

What is the natural process that comes to the mind for completing an assignment? Does it look some variety of the below figure?

Figure: Generally followed process model for completing an assignment from start to complete. There might be one or two iterations of the output, that means feedback provided once or twice. Low collaboration between stakeholders results in sub-optimal output or significant rework and wastage.

Some shortcomings in the above process are:
- There are no defined interim timelines or, even if defined, are not tracked among other competing priorities
- Feedback is received only once or twice in the whole cycle
- Approving sub-par quality output to close in time
- Results in a high cost of change because feedback is received on near the complete version
- Generated artifacts are not maintained properly, thus reinventing the wheel every time
Accommodating slight changes in the above process can offer significant improvements overall. The first step is to make the “outcome” at the center of all the other things (instead of “output”). By keeping the end result (outcome) at the center and aligning all other things around it, we ensure that the objective is clear.

Figure: Suggested process flow model keeping outcome at the center and completing the assignment iteratively and continuously. Output can be picked up when all the stakeholders are satisfied. This model gives an opportunity to start socializing a work-in-progress version and get continuous feedback.

What I am saying here effectively is that we put the entire focus on the outcome and make the process “iterative” and “continuous.” “Iterative” essentially means that you don’t aim to complete the work in near entirety before going for a review. You break down the task into logical steps which will incrementally show the reviewer the direction or approach you are taking toward the task completion. And continuous refers to the lean flow, enabling the outcome to not get stuck at any stage, and continuously being aware of and removing bottlenecks.

Make every important outcome a time-boxed event and work toward its closure in an agile manner. One of the best ways to complete something proactive is by creating self-imposed deadlines. Agile (or scrum, specifically) provides a systematic way of putting deadlines in the whole life cycle (McKinsey Article – “Making your marketing organization agile: a step-by-step guide“).

My belief is that the same concepts can be extended to any important assignment for effecting the outcome.

Figure: Agile Scrum process which suggests maintaining the requirements in a backlog that is always kept prioritized. Then work in an iterative manner, generating output incrementally toward an ever-improving state, incorporating feedback continuously.

The key thing to observe here is that sprint duration and ceremony frequency can be adjusted to make them much more frequent than the recommended one to four weeks.

Some people consider agile-scrum unnecessary. Well, the concept of Minimum Viable Product (MVP) and creating a “continuous” flow in the development of work item can be brought in irrespective of whether a team follows an agile-scrum approach or not. I have drawn that parallel and created a universal model for any kind of artifact (non-code – such as marketing flyer, legal contracts, product documentation, customer presentations, reports etc.).

Figure: A model for following the DevOps best practices of continuous feedback, collaboration, automation and continuously improving outcome in any type of work environment or team.

Here the requirements can come from any source internal or external to the organization. The “source content management” should become the single source of truth for any final artifact; it will also be the versioning system to maintain a record of historic artifacts. The orchestration platform could be an advanced CMS tools, a utility application developed in-house or a simple cloud storage tool such as OneDrive, Google Drive, Dropbox or even plain file systems.

There will have to be a set of process and policies that support this model. I have appended an indicative list below.

Collaboration sits at the core of the entire model. Unless people come together and share continuous feedback, the DevOps way of working cannot succeed. The lifecycle stages are explained in the next section, but the main idea is to prototype fast, get continuous feedback, fail fast and always maintain a releasable version ready. Feedback should become an integral part of the entire system. Feedback captured internally or from external audience should be captured and stored along with the artifact version for which the feedback was received. The next time the iteration starts, because the artifact is a periodically updating work item (marketing campaign or sales pitch material) or is being enhanced (website content or product documentation), the latest artifact version along with its feedback should be taken into consideration.

The lifecycle stages for good-to-have artifacts are presented below. These stages could be slightly different than the one indicated in the above model to suite your requirements:
- Dev (Development environment): Individual contributors local machine. People work on their picked stories (as in agile: a broken down unit of work). This could be an individual or a group of people.
- Int (Integration environment): All the individual pieces are stitched together to form one coherent outcome. There should be an artifact ‘owner’ (as in agile: product owner) identified, who will do this work on his system. This has scope for automation. It will benefit if done collaboratively.
- Test (Testing environment): Receive review and feedback by the approver (could be the “owner” or business leader who gave original requirements). This stage has a scope for automation. From this stage onward, the content resides centrally on the source content management system.
- Pre-Prod (Pre-production environment): Approved and finalized version rests here until sent for final audience’s use.
- Prod (Production environment): Only those artifacts that are for end users are maintained here (published news item, signed contracts, delivered customer pitch, etc.). Maintain the version-controlled artifact. This stage also becomes the single source of truth for all artifacts. Maintain historic data for record-keeping. Market feedback is captured and stored along with each version.
- Release & Ops Mgmt (Operations): The purpose of this stage is to ensuring periodic cleanup activities in the source content management system. Ensure periodic enhancements on the content and maintenance of production copies.
Artifact lifecycle policies, to start. You may identify and add more as per your requirements:
- Identify owner for each artifact. She would become approving authority for the content.
- Prototype & fail fast (MVP). Follow agile methodologies as much as possible and adjust sprint duration for different content types.
- Make feedback your bible. This is necessary for continuous improvement. Record the feedback and act on it.
- Collaboration should be at the heart of the entire process. All involved individuals should be part of the entire artifact life cycle.
- No e-mail content should ever be accepted for review, approval or final use. E-mail can be sent with a link for source content management.
The purpose of this article was to draw a parallel with non-code artifacts so that DevOps philosophy can be understood with a non-development angle. It’s my hope that it is evident that DevOps is not something that can be adopted overnight, and it’s not just about implementing tools. People have to be aligned and trained for the new ways of working. It entails a lot of cultural change to be initiated. And finally, the benefits are better visible as the scale grows; however, small steps must be taken at the beginning to identify a model that is fit for your specific landscape.

This is the first iteration of this article and it will surely undergo improvements. Feedback and ideas are welcome in comments below.

About the Author / Kunal Gupta

Kunal Gupta is Product Owner in IG Group for their Payments team. Prior to this Kunal managed AgileBase, a DevOps platform developed in and by Wipro, a global IT major. Kunal played a key role in defining and streamlining the roadmap for AgileBase platform, its pricing and positioning to global customers. Kunal has diverse experience in Technology Product and Services Industry spanning across Product Management, Presales, Sales, Campaign Management and Demand Generation. He has a worked for major customers in financial, technology, and manufacturing industry across U.S. and European markets. Connect with him on LinkedIn.
February 22, 2017
CD 101 Podcast Episode 2: The Agile Enterprise
And we’re back with another episode of the “Continuous Delivery 101 Podcast.”

In Episode 1, we covered the three waves of IT disruption—and how these disruptions, combined with the move toward digital transformation, are drastically changing every industry.

This, of course, underlined how accelerating speed-to-market is clearly more important than ever before.

In this second episode, we talk about Agile methodologies with expert Dan Rice, who addresses how these practices can enable business strategies to be implemented at greater speed.

Listen closely and you’ll learn more about what Agile actually means across various teams, roles, product owners and scrum masters, along with related points on DevOps and CD tooling.

All of these topics are great food for thought as you think about how you can move to build software faster and with increased quality. Yet, if enterprises only focus on these issues, they aren’t tackling or talking about the real problem in their organization that Agile can solve.

It’s time to take the conversation beyond the team level and talk about how work flows to every involved team, enterprise-wide—specifically, about how initiatives can expand across multiple teams, how to manage shared resources and how to pull in other dependent teams.

For Agile to work, it has to expand universally and be ingrained further at program level, to understand precisely how work is coordinated and flows across every domain.

You can listen to Episode 2 of the “Continuous Delivery 101 Podcast” via:
- YouTube
- iTunes store
- Or by searching for it in the iTunes Podcast App under “Continuous Delivery 101 Podcast”
Thanks for tuning in to the “Continuous Delivery 101 Podcast.” We hope you’ll continue the conversation by posting your comments below or in the comments section on YouTube or iTunes.

Meanwhile, keep tuning in: We’ll be back soon with another episode!

— Scott Edwards
February 21, 2017
What Happens Post-Deployment: The Rotating Roster
DevOps has become that celebrity who’s always the talk of the town but is largely misunderstood. It’s even quoted in the wrong context.

A few days back, while speaking at a conference, I was interacting with audience and one of the attendees said DevOps is like the backbone of Agile. I think that’s an excellent way of describing DevOps. In an industry where we are still struggling to implement Agile—and even more so to keep people from drifting—is DevOps ahead of its time? Maybe not.

DevOps is the set of practices necessary to sustain the fast pace of delivery. The best part of DevOps is there are no levels or certifications one needs to achieve. It’s the stack of practices that you pick and implement and reap benefits. The 7Cs—continuous planning, continuous integration, continuous delivery, continuous testing, continuous deployment, continuous monitoring and continuous operations—help maintain sanity, though.

One teams had to sustain fast-paced releases with a big customer base. We saw our users increase from .1 million to 2.4 million in three years. Agile, continuous integration and continuous delivery are not just fads for us, but needs for survival.

Using the Rotating Roster Method

When we talk about continuous delivery but then focus on just delivery, it’s not enough. It’s equally important to work on what happens post-deployment, such as continuous monitoring and continuous operations.

Rotating Roster is one practice we use in our organization and this has helped us pull together the whole ecosystem of:
- Resolving customer issues,
- Feedback system pumping into out technical pipeline/debt for next releases,
- Knowledge transfer and learning ecosystem to address attrition, and
- Broken silos.
Here’s how we do this. First, we define the scope of the Roster. We picked the following:
- Production Outage
- Customer issues/P1
- Ad hoc requests from stakeholders
- Data extraction (only tasks out of scope of a separate Data Analytics team)
Next, we publish a schedule of every two to four weeks, designating at least one person to be on the Roster. It’s essential that the Roster rotates to all or most in the team to build a bus factor or a knowledge transfer ecosystem in the team.

For each request received, we asked the Roster person to log it in JIRA. This was not just for bookkeeping sake, but as an essential step in line with the Roster objective.

After every Roster period, we sat down and reviewed these JIRA requests for possible targets to:
- Automate the task or the effort involved, such as account creation requests automated by writing php scripts, for example.
- Delegate the task to the right team to cut the effort. For example, for a new data extraction we set up SQL slaves and replicate tables on analytics machines, then delegate the task to them for all future instances.
- Mitigate the reason for the request, such as the root cause of an outage.
The mitigation/automation steps had to be picked by development team in their Sprints. Otherwise, usually they become technical debt and lay around in the backlog.

Since the development team was taking turns on the Roster, they understood the priority and necessity of doing the task. Thus, the technical pipeline was chosen and fed actively.

Another advantage of the Roster was it showed the team the “big picture” and helped catch early trends.

The Rotating Roster system turned out to be a big success for our teams; thus, we replicated the model through the rest of the organization. It’s a small but essential step to adopting DevOps culture.

In one definition, Jez Humble explained that DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly changing resilient systems at scale.”

I could not have put it in better words.

About the Author / Kiran Chhabra

Kiran Chhabra is Vice President of Engineering at Infoedge India Ltd. She has 14 years of industry experience designing and implementing highly scalable and available architectures with optimized continuous integration and delivery in technologies including LAMP, Java and mobile technologies.
Kiran holds a U.S. Patent and has published technical papers. She is certified scrum master and certified scrum professional, and speaks at various Scrum Alliance & technical conferences in India and the United States. Connect with her on LinkedIn and Twitter.
February 20, 2017
Reality Check: Bringing Continuous Delivery Dreams to Life

Every developer shares the same dream: to write a piece of code or app that changes everything.

Whether it makes your company do things more efficiently, attracts hordes of new customers, simply makes existing clients happier or maybe even changes the world a little bit, that code is what we strive for. Some of us don’t merely harbor that dream; many of us actually achieve that moment of brilliance. For those who have, it’s remembered as a moment of pure joy.

So, where does this magical process begin? First, you talk to your manager and, if you’re lucky, she or he agrees that it is a fantastic idea and starts to sell it internally. Sometimes the idea is so good that you get the go-ahead on the same day and even get a small team to work on it!

Then, soon thereafter, reality kicks in.

You need data, inevitably from applications running somewhere in the cloud and/or some other data from on-premises data stores. You need to interface with APIs, some well-documented, some not. You need some user experience work done, and the standards your company has adopted don’t really match your vision.

You also need to interface with many of the standard services your company has already implemented because, after all, your app doesn’t run in isolation—you work with existing billing systems, a CRM system, a fulfillment system … and all of them run on servers that can be anywhere. Soon you find yourself fighting for test data, systems to test with and applications and APIs to interface with. Before you know it, you’re banging your head against the wall.

Fortunately, your teammates are flexible, creative people. And because your internal systems seem to work against you, you go around them. You download a trial version of some testing software; you install a copy of some internal systems on a virtualized test server (if you can find one) and start working with these.

Since your app needs to be snazzy and snappy, you download some open-source software to help you test the performance on mobile devices. After three sprints, you’re now ready to move your app to an environment where you can start performing real tests!

Most times this is the moment when the hardest reality kicks in. The copies of the systems you tested with were not up to date. Data has changed. APIs have changed. The real system responds three times slower than the copy that sat on the server right next to you. The data in the cloud has changed. The performance testing tool you used is not available in the official testing environment. … The list goes on.

This doesn’t even include the difficulties of moving all the components of your new app to different environments. Trust me, this is not a fictional nightmare scenario; it is reality and I see it happen all the time.

Now, what if you had the test-data generators necessary to create the data you need and a server that ran virtualized services, mimicking all the (up-to-date) external systems you need including the APIs to talk to them—services that would allow you to say, “What if this application responds three times slower when I request data?” or, “What happens if this system suddenly goes down?” What if, when you’re done building, you could simply migrate the app and all the components that go with it to another (test/QA) system with one click?

Everybody wants to support people with good ideas and turn these ideas into working software without the frustration that very often distracts and demotivates people. To do so, you need to create the infrastructure that supports this. Is it difficult? Not really, the tools to automate services, create test data (and test scenarios) and migrate complete applications from A to Z are available.

However, just like a great app, this too starts with a dream—the dream of allowing people with great ideas to work on these ideas without the overhead of an infrastructure that allows them to focus on the coding and not on the infrastructural issues; the dream to create a software factory where the creation of the app takes 90 percent of the time and the infrastructural burden only 10 percent, not the other way around.

If you’re serious about developing software and want to create an environment where the infrastructure allows people to develop and release software faster instead of working against them, find the tools that support it and jump in, because they exist today.

Enacting this change now and maybe the next time someone comes to you with a great idea you can be confident that they will have all the support needed to get there efficiently.

— Marcel den Hartog

February 17, 2017
Security @ the Speed of DevOps Survey: Efforts Still Lag

Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In devopsy.kinsta.cloud’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

Have a look at our survey and report to see how enterprises are tackling this challenge today.

— George V. Hulme

February 13, 2017