devopsy.kinsta.cloud

Tag: agile

  • Five often expressed obstacles to enterprise IT innovation

    Five often expressed obstacles to enterprise IT innovation

    Business leaders know, for their business to succeed in the years ahead, that their IT and developer teams need to innovate. But surveys show that too often the IT teams may not be able to deliver the innovative value that the business seeks. Have a look out our recent Q&A, The IT mandate: Be a catalyst of business innovation for some more insight on the IT and business innovation gap. The fact is that technology and developer teams can’t do it on their own, they need to operate in an environment that enables innovation. In speaking with CIOs, developers, and others close to the process of creating value with IT a number of obstacles continuously surface. And these obstacles are holding their development efforts back.

    These obstacles include the tight collaboration with development and operations teams, the failure to actually embrace Shadow IT for what it actually is, staying stuck in single mode IT, and oversights in how they are developing mobile applications.

    Here they are:

    Obstacle Number 1: They don’t effectively unleash the power of their developers. DevOps teams are known to grind through technical debt and when they manage to hit on all cylinders they also have very short application backlogs. One way to keep such app backlogs short is to focus on the Minimum Viable Product (MVP). Because the MVP is an application that is, initially, focused only on what it takes to get the job done, and no less or more, developers don’t get bogged down overdeveloping apps that won’t get used. To be clear, MVP doesn’t mean shoddy app, rather it means the minimum app to be productive at the task. With this Spartan approach, development teams can invest no more than is needed into an app, release it into production and see how enthusiastically (or not) it is embraced by the user base. This enables development teams to push apps forward with as little risk and investment as necessary. And then either dig deeper into that app, or move on to another.

    What does that have to do with innovation? Plenty if you consider the amount of time saved from over-developing applications that wont be used and investing that time and effort elsewhere, perhaps apps that will provide value to the organization.

    Obstacle Number 2: They don’t embrace shadow IT. Rather than embrace Shadow IT, many organizations shun the notion of users choosing the tools and technology they need to get their job done. But end users and employees are turning to cloud services and bringing their own devices because these are the devices and services that they know they enjoy to use and they can use to effectively do their jobs. That makes for more productive and happier workers. Certainly not just any old rogue service and device can be used, but the enterprise can watch and vet the services that are safe or find ways to make them safe. A good place to look for this is the Cloud Security Alliance’s Security Guidance for Critical Areas of Mobile Computing.

    Obstacle Number 3: They don’t bimodal. By not embracing two-speed or bimodal IT, enterprises have a harder time allotting resources to strategic development and IT efforts. In bimodal IT there are two modes, one mode is focused on quickly delivering the applications the enterprise most needs to compete and be effective while the other mode is focused on the infrastructure services and API development and management.

    A good overview on bimodal IT can be found here in our post Bimodal IT and Remodeling Traditional IT for Greater Agility.

    Obstacle Number 4: There exists an average to poor business to technology interface in the organization. In too many organizations there is a lot of collaboration within the technology groups, such as operations and developers, but not enough interfacing with the business teams. For better outcomes, there needs to be tighter collaboration between DevOps and the business through continuous feedback on current and future objectives. This way DevOps teams know what the business priorities are and can develop to them more effectively.

    Obstacle number 5: They aren’t focused on the context within mobile moments. The world of IT has gone mobile and will someday go wearable. This is more than just a mere form factor trade; it is creating a profound change in the way we interact with our apps. When we sit down to work on a laptop, we are usually settling in for a nice stretch of work time. However, when it comes to phones and wearables, we are usually working in short instances. We are sending a text, answering one email, or capturing one or two new data points about a client for entry into the CRM app. Developers need to focus on providing users apps that work in the same way too. That is they need to develop apps that provide users the data they need based on short device interactions and hopefully context of what they’re doing. If the user were at a clients’ office, for instance, and the rep launces the CRM app, it’d be ideal if that customer profile launched by default with the app. If the user is involved in a certain workflow, other items that are commonly taken care of at the same time would also ideally be suggested.

    While these obstacles may sound simple, they can be quite transformative to the way your business-technology teams will develop, collaborate with the business, and hopefully provide more innovative services.

  • Digital Disrupters – Building a DevOps Leadership Profile

    Digital Disrupters – Building a DevOps Leadership Profile

    While the advancement of DevOps methodology remains fairly nascent for many organizations, an ever-expanding class of leading practitioners are evolving a wide range of related best practices.

    Beyond the well-worn concept of “unicorns” – the scant few organizations that stand as mythical examples of DevOps nirvana – this broader set of early adopters have begun to pull back the curtain on their efforts, lending further detail to the strategies that have bred this current model for success.

    Last week, industry analysts Freeform Dynamics published valuable research that highlights the ongoing work of such DevOps innovators, dubbed as “Digital Disrupters” for their accomplishments in pursuing larger digital transformation. The report “Exploiting the Software Advantage” – sponsored by CA Technologies, outlines a critical set of initiatives crucial to navigating the DevOps landscape.

    What are the specific hallmarks of those organizations leading the charge? Where are others struggling to catch-up? Many of the Freeform Dynamics survey results, based on 1442 respondents, reaffirm widespread DevOps observations, while other findings serve to shed new light, including:

    • Everyone builds software: Perception is, in fact, reality and to deeply engrain digital transformation, Digital Disruptors are increasingly identifying with this mantra. While 95% of leaders have committed to becoming more app-centric, only 51% of mainstream organizations have adopted this persona. Similarly, 84% of Disruptors directly identify as “software companies”, regardless of industry, compared to 40% among the masses.
    • Transformation is required: This point may seem obvious, but it certainly bears repeating. A whopping 92% of leaders have actively moved to break down traditional silos between Dev and Ops, with 51% of those organizations having already completed this work. By comparison, only 18% of mainstream organizations claim to have done the same, supported by 59% who at least share this more collaborative DevOps vision.
    • Commitment is critical: This may also seem like a no-brainer, but the numbers bear out this requirement. Some 77% of Disruptors have agile development methodologies in place, with 70% having “broadly” implemented DevOps activities. For mainstream organizations, these metrics rate at only 31% and 21%, respectively; leaders are going all-in and appreciating the benefits, and those that follow will need to do the same.
    • Experimentation is omnipresent: To garner the benefits of continuous delivery, embracing trial and error is a must. Among Disruptors, 93% recognized the need to “experiment and fail quickly on the road to success”, compared to only 58% of mainstream organizations. Some 95% of leaders have already shifted from fixed product cycles to continuous innovation, while only 56% of the mainstream have made this leap.
    • APIs are everywhere: Ubiquitous integration, both in-house and in connecting to third parties, has only increased emphasis on the API. Disruptors are resoundingly focused on API management, with 68% using APIs to integrate third party services into their applications, and 66% to offer external access to systems and data. Mainstream peers compare at only 26% and 24%, respectively, denoting a sizable API management gap.

    These are only a handful of the most dramatic and obvious areas where DevOps advocates have clearly re-architected their approach, separating themselves from those organizations that have yet to go all-in; it doesn’t stop there.

    As highlighted in the research, other areas of differentiation and dichotomy include cross-functional alignment, emphasis on digital channels, use of digital to drive core business efficiency, and even funding of digital investments.

    Beyond these key philosophical milestones that litter the pathway to DevOps success, the survey also highlights the vast array of strategic goals that these organizations have sought to accomplish. The results spotlight the massive range of significant business benefits that practitioners believe DevOps can deliver.

    Leading use cases include:

    • Improved customer satisfaction (49%)
    • Better workforce productivity (44%)
    • Improved customer experience (41%)
    • Improved competitive differentiation (38%)
    • Better agility / speed-to-market (37%)
    • Opening up of new markets (35%)
    • Creation of new business models (30%)
    • Creation of new routes to market (26%)

    If one were to take those outcomes out of context, unrelated to the impact of DevOps, it’s fair to say that they read like a generic list of leading business initiatives – further underlining the movement’s overall relevance.

    That’s not to say this is all accomplished easily. Report respondents detail hard won victories that required significant time and investment to achieve all this DevOps-driven advancement. After all, the notion of “disruption” doesn’t exactly evoke images of ease or comfort.

    Click here to read the report for yourself – there’s a lot more to be considered. Namely, how well your organization measures up in affecting digital transformation in its own right, and where it can take steps to move forward.

  • Building a Winning Software “A-Team” with DevOps

    Building a Winning Software “A-Team” with DevOps

    The 1980’s TV show The A-team was brilliant. Four ex-commandos with special skills who help the oppressed. Throw in some over-the-top violence where no-one gets hurt, together with some tech wizardry where the team magically create weapons out of old spare parts. Add a catchy theme tune – and voila – classic viewing.

    In many ways agile software development teams want the autonomy portrayed by the A-team. And why not? Let’s bring together small teams of bad-ass code junkies. Provide them with enough open source software to build, integrate and deploy virtually anything. While we’re at it, give them the power to smash all the evil villains’ conspiring to prevent the rapid release of software for the oppressed business – like out-of-touch operations, process-crazy service management, or security and compliance police.

    So on the face of it our A-Team looks like an IT winner. They save the day and no-one gets injured, right? Well not exactly.

    When Agile Autonomy meets an Immovable Object

    Autonomy is both a blessing and a curse. On the one hand, letting teams self-organize and self-manage without outside interference seems like a productivity no-brainer. However, when team autonomy descends into selfish technology-centric rants over rational program level thinking, all hell can break loose. Suddenly every team has access to a plethora of super open source tools — need a document style database for your new Python coded microservice? No problem, click here to download, quickly brush up by reading some appdeveloper articles, and hey presto you’re off and running. Rinse and repeat for different programming languages, build tools, code versioning, configuration management and your teams are all swimming in a fast river of technical goodness where considerations about resilience, performance and security can be easily lost.

    The only problem is that the river flows down to where it eventually meets guess who – all those out-of-touch operations folks, process crazies, and security guards. Not surprisingly, they view this last minute technical deluge with a more cautionary eye. And since they’re compensated and rewarded on preventing problems, security issues and compliance exposures, they’re not going let any software pass freely into production – well, not without a fight anyway.

    And herein lies the problem with the autonomous A-Team. The “A” suddenly becomes more associated with adversarial engagement than anything remotely agile. So cue delays and the business being ticked off yet again with IT.

    Lessons from the Art World – Rembrandt and Stradivarius

    DevOps with its focus on team collaboration aims to channel the healthy tension existing between Dev and Ops into business goodness. This starts by understanding how and where to engage all that natural team angst.

    There’s a classic old sketch from the late British comedian, Tommy Cooper — who walks on stage with a painting and violin, proclaiming – “I bought a Rembrandt and a Stradivarius – the only problem is Rembrandt made lousy violins and Stradivarius couldn’t paint”.  He then smashes the violin into the painting – hilarious.

    In development we have our own Stradivarius’ who write great code, but have little appreciation on what makes a “complete” system. They can add all functional bells and whistles, but when it comes to compliance, resilience and supportability, forget it – they’re like the maestro violin maker with a paintbrush – pretty crap. Worse still, the only time they get to learn is when they’re forced to slug it out during a gated security review or regulatory compliance session – this usually doesn’t end well.

    These issues may be resolved when development, operations and other stakeholders engage much earlier in the software development lifecycle. Here as requirements are established and code begins to take shape, stakeholders can work with development; guiding them on what’s needed for the software to become more secure, perform optimally and be a breeze to support.  For starters, this has to include IT Operations sharing years of expertise – like how to exploit monitoring tools in pre-production to equip developers with an early warning system on performance issues as they code, or explaining what’s needed to support new distributed architectures at scale.

    Engage Early and Broadly for Success at Scale

    Beyond operations, there are many other IT and non-IT stakeholders who should be drafted into the A-Team.

    When working on a new web to back-end system integration for example, security could advise development on end-to-end transaction tracing and static-code analysis techniques to help detect code or SQL vulnerabilities. In an API project, threat teams should engage early to model and mitigate against many new attack vectors that hackers can exploit, providing advice on strong, API-specific infrastructure and management. Naturally, if your team is doing anything with mobile payments you better hunker down early with the security and PCI compliance team – or if the agile team has devised some neat sensor, software and cloud technologies to capture and analyze customer-centric data ala the Internet of Things, then early involvement with the legal department on privacy gotchas is a must.

    Large scale success from agile teams can be realized when those teams become less feral about their own individual needs and more focused on supporting business objectives at a program level. To this end, and whatever the makeup of individual teams, it’s vital to establish DevOps style collaboration early in the lifecycle; engaging all business and IT stakeholders in order to establish resilience, quality, security and even supportability into the fabric of software as its developed.

    Do this and you’ll deliver great software without ever having to compromise speed. Fail, and your agile efforts may just stutter and fail – of course you’ll still have an A-Team, but the “A” now stands for something far less complementary!

  • The business benefits of DevOps

    The business benefits of DevOps

    As DevOps has become more of a mainstream concept it seems like there’s less need to define what it is or explain what it does. As prevalent as DevOps is for those of us who work in the world of DevOps or organizations that have already embraced DevOps there are still many businesses out there muddling along the old-fashioned way and wondering why they should care about DevOps.

    The simple answer is that not caring about DevOps may be suicidal. The 2014 State of DevOps report found that organizations successfully implementing DevOps tools and practices lead competitors in almost every relevant metric. Two statistics that stand out from that report are that companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals, and had 50 percent higher market capitalization and growth than rival businesses.

    Why is that, though? What is it about DevOps that leads an organization to be more profitable and productive? It’s a combination of three things, really: faster delivery times, greater stability / reliability, and freeing up time to focus on value.

    Let’s break those down some. DevOps is an evolution of the Agile development methodology. In fact, I’ve asserted in the past that DevOps is really just a matter of taking Agile principles and applying them to the rest of the company outside of software development. Whether Agile or DevOps the result when it comes to developing software is faster, more frequent delivery.

    Next we have greater stability and reliability. It might seem that the traditional linear method of developing software and releasing it on a pre-defined schedule is more stable. Developers and the rest of the organization have plenty of time to refine the code before it’s deployed, they know exactly when it will be deployed, and they know it basically won’t change for another year or so when the next major release is scheduled. The reality is the complete opposite in many cases.

    Developing with a rigid process methodology like waterfall means that only the changes and features identified at the beginning of the project are included in the release. As the need for improvements or additional features is identified during development those things are sidelined and added to a list to be pursued in the next release cycle. By the time the software is developed, tested, and deployed it is already out of date to some extent and bugs or issues that are identified take longer to address or get pushed to be handled in the next major release.

    The whole process is slow and results in less stability and reliability. DevOps yields greater stability and reliability because the faster development and more frequent release schedule enables organizations to identify and resolve issues immediately.

    Those two things combined mean that developers and others throughout the organization have more time available to focus on improvements and innovations that contribute to the bottom line. Organizations that have embraced DevOps also generally have tools in place to automate routine tasks which enables individuals to dedicate more time to growing the business and less time to pissing on fires and maintaining the status quo.

    DevOps has come a long way in just a few short years. There may still be companies out there trying to figure out why they need DevOps, but those companies won’t be around long. They’ll either figure it out and jump on the DevOps bandwagon or they will no longer exist to worry about it.

  • Native Integration of APM Driving DevOps Maturity

    Native Integration of APM Driving DevOps Maturity

    With applications performance monitoring established as one of the fundamental cornerstones of today’s DevOps methodologies, it’s easy to overlook the reality that effective instrumentation of such tools remains extremely difficult. Specifically, the biggest challenge remains creating performance metrics that address both IT and larger business initiatives.

    There’s no question that APM is one of the most widely adopted and deeply embedded elements in today’s DevOps world, serving as the critical source of measurement that enables more transparent and agile applications. Yet, despite the fact that performance monitoring solutions, and their respective providers, are considered to be among the most mature on the DevOps landscape, customers still struggle to optimize the systems to meet their specific requirements.

    However, as the market continues to advance, specifically via direct integration of widely-adopted APM tools with other strategic applications management systems, such as e-commerce platforms, organizations are finding a faster path to success, and bigger-picture DevOps benefits. One such partnership, announced in late August, saw market leader New Relic expanding integration with e-commerce platform provider Magento, owned by eBay.

    Jon Azrielant, director of marketing at online retailer Jewelry.com, a Magento customer, said that his company initially ran into significant obstacles in adapting New Relic’s APM capabilities to its processes, despite the comparative strength of the tools.

    “We had a really difficult time implementing New Relic initially, it was a painful process,” Azrielant said.

    While the APM tools provided Jewelry.com with the data necessary to generate vital alerts, along with more agile sysadmin and operations monitoring, the more silo-based, fragmented approach that it employed could not empower the retailer to circumvent traditional walls between apps support and service support teams, Azrielant said.

    Leveraging the extension of New Relic’s Software Analytics Cloud within Magento, the company has created more advanced instrumentation to inform critical business decisions. Among the most helpful of these measurements are those relating directly to customer experiences, while correlation of such metrics with Jewelry.com’s bottom line has also advanced executive decision-making, he said.

    “The critical result of this integration is more complete visibility across applications and business performance, importantly tied to the actual business ramifications,” said Doug McIver, director of product for Magento. “In the past, merchants had to do a lot of difficult integration to use these systems together, so obviously this is a hugely valuable capability for us to be able to offer, especially to customers with highly performant site requirements.”

    Moreover, Magento claims that it is growing its own customer base by tying APM more closely to its platform. Likewise, New Relic officials concede that to help advance crucial DevOps workflows, it must partner with such platforms to deliver APM data within the context of business requirements.

    “If we’re talking about how to win in world where we’re iterating the end users’ experience on a regular basis, we have to put performance metrics within context of the UI, and the business results; working from the same data sets and getting people on the same page is incredibly important,” said Abner Germanow, senior director of solutions marketing at New Relic.

    While pure performance stats are “near and dear” to New Relic for obvious reasons, the solutions provider is also attempting to advance a broader array of information that drives closer collaboration through new “iteration and experimentation”. New Relic is also focused on further developing the specific types of information most critical to key constituents such as e-commerce platform users. The need to create a common language for those DevOps efforts is amplified by the fact that development and operations officials are often unsure which metrics are critical to the business, and vice versa.

    “Instrumenting code has always been a challenge, and we’ve worked very hard to ease that pain across a lot of different platforms; there’s always another language where work can be done, and we look to our customers to help lead us into the next phase of instrumentation,” Germanow said. “We’re seeing a lot of pressure around the need for constant change and iteration in industries where it’s truly a matter of survival, such as e-commerce, publishing, digital governance and finance – places where the industry is behaving very differently now than it has over the last 50 years.”

    This work, and the subsequent APM integrations offered via platform providers such as Magento, have allowed end user organizations to remain focused on customer experience and sales, the ultimate goal of DevOps, said Jewelry.com’s Azrielant.

    “In terms of how this relates to the DevOps revolution, this is the advancement that is bringing everything together and allowing everyone to look at the same numbers, to share common APIs, to streamline reporting and event response, and define everything in uniform terms,” Azrielant said. “Ostensibly, the most basic tenet of DevOps centers around the unification of these disciplines, and you can’t support that without the unification of this information.”

  • DevOps Chat: Varun Singh, CTO of ScaleArc

    DevOps Chat: Varun Singh, CTO of ScaleArc

    singhI recently had a chance to sit down with Varun Singh, CTO and founder of ScaleArc. ScaleArc was recently named a Gartner Cool Vendor and is the leading provider of database load balancing software.

    Varun and I spoke about why IT leaders need to ensure that their databases are performing optimally.  On top of that Singh has had a colorful career in India as a pioneer in the Internet.  You can listen to our conversation and follow along with the transcript. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505149″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Alan Shimel:                Hi everyone, this is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Very happy to be joined today by our guest, Mr. Varun Singh, founder and CTO of ScaleArc. Varun, welcome to our webcast.

    Varun Singh:               Thank you, Alan. Thank you for having me today, it’s going to be fun.

    Alan Shimel:                I think so. So Varun, we were talking a little bit before we went live, or recorded, as the case may be, and you were giving me a little bit of your background. You’ve had quite an interesting career working on OS/2 Warp and BBS’s in India, running the first BBS based on Linux in India and hosting a TV show there as well.

    Varun Singh:               Yep, yep. I’ve really sort of aimed for diversity, if you want to put it that way, in my career. I’ve tried anything and everything. Been a writer. Been a journalist, sort of reviews and everything else. Started a website called TechTree.com, which is now like the number one tech website in India at this point in time, and a whole bunch of other stuff. Joined CNBC sort of at the peak of their build up and joined them primarily as a tech editor, but they wanted me to be the CTO, so I did that sometime. Built a whole lot of websites with them, and when we did that, essentially learned the value of how to scale databases. And from there came the idea of ScaleArc.

    Alan Shimel:                Excellent. So Varun, excellent lead in for our audience who may not be familiar with ScaleArc, can you give us a quick background?

    Varun Singh:               Sure. ScaleArc is database load balancing software. We essentially ship you a virtual machine, and that virtual machine includes the database load balancing software that let you scale, provide a zero downtime environment, and essentially make your transactional apps completely zero downtime. This is the kind of tech that pretty much Google, Facebook, everybody else have had within their networks, because they’ve built it for themselves. What we’re doing is building it for the rest of the world.

    Alan Shimel:                So as some others have been wont to say, the CoreOS people, you’re bringing sort of Google-like experience to the masses.

    Varun Singh:               Yes, at the database layer, yes. So CoreOS is doing it essentially, the OS layer, and there’s a whole lot of stuff that’s going on in the container world, which is all very, very exciting and we’re participating in that in someway as well. But essentially what we do is we sit at the transaction box. So applications and websites, they connect to us with an abstraction layer, and once they connect to us, we then go ahead and establish connections to multiple database servers in the background and make sure that no matter what happens, that application gets its transactions through.

    Alan Shimel:                Excellent. And Varun, ScaleArc is sort of a six-year overnight sensation, right? You guys have been around for some time since 2009?

    Varun Singh:               Yep, it took us about 2.5 to 3 years to sort of build the tech itself, because it’s pretty complicated to build what we’ve built, because we’ve built essentially the world’s first transparent database engine. If you look at the four patents that we filed in 2010, they’re all about transparency and how we’ve basically made this possible for any and every app. So all an app has to do is just transfer its connection over to us and immediately they get access to an entire cluster, they get access to zero downtime, they get access to deep SQL  analytics, and all of that is available to them as part of that one single package that we provide.

    Alan Shimel:                Excellent. So Varun, our talk today is really aimed at C-level, VP manager level people. Why should – without getting too far into the weeds on the technology or feature set, why should executives care about what ScaleArc is doing and what problem are you solving that executives care about?

    Varun Singh:               Sure. So at this point in time I’m sure a lot of executives are looking at how to migrate to the cloud. The moment you go to the cloud you’re essentially running into smaller machines, you’re running into unpredictable arrangements windows, and you also have to worry about how to aggregate capacity across multiple machines to be able to make your performance numbers.

    A lot of applications that are running on very large servers on prem don’t have a way, don’t have a path into the cloud right now. So ScaleArc is basically the thing left that’s the last step in being able to migrate to the cloud as far as large mission critical database intensive apps go. So that’s the first thing that we do.

    We’re making it a lot easier for your application developers to develop these apps and not have to worry about the HA piece, not have to worry about the failover piece and all those things. And that makes your developer’s life so much easier. We provide you a lot of APIs and all those APIs let you automate pretty much all of these functions. You could go ahead and do a rolling upgrade. You could do a rolling patch. All of that can be automated, and you can do all of that using our S API’s that are provided by us.

    Alan Shimel:                Excellent. So Varun, when you guys typically – well first of all, is it mostly larger enterprises that are looking for this kind of thing or is it across the board?

    Varun Singh:               It is across the board, but we’re specifically at this point in time targeting larger enterprises. So some of our largest customers are like Dell.com. So every single transaction on Dell.com works with us and we’ve been with them through the last two Black Fridays and just preparing now for a third Black Friday with them. We work with NASDAQ, so NASDAQ pretty much all price feeds at this point in time come through our system. We work with Answers at Microsoft.com, so all user queries that are going through Answers to Microsoft.com come through us. And that’s one of our large deployments that is across the board, four regions, multiple datacenters, active active. So pretty complex applications and pretty complex deployments.

    Alan Shimel:                Excellent. And Varun, when you engage customers of this size, where is the engagement coming from? Is it executive led or are there sort of technical champions that are bringing ScaleArc technology to the exec team?

    Varun Singh:               Sometimes it is executive led, sometimes it’s architecture led. Sometimes it’s even DBA or application developer led. It’s across the board. We’ve seen all kinds, but the most consistent one we’ve seen is the architecture, and that’s a pretty good fit I think with your show as well.

    Alan Shimel:                Yeah, yeah, I believe so.  So Varun, as I think we were speaking earlier, we live in interesting times. It’s sort of a boundary layer as we move into a world dominated by movements like DevOps and automation and continuous delivery integration, continuous integration, continuous everything. How has that played into your life and ScaleArc?

    Varun Singh:               It’s helping us massively. That’s pretty much exactly what people want. They want that application infrastructure to be continuously available. So from that perspective, the fact that databases are the last thing remaining in that stack which are hard to manage, we’re sort of flying at this point in time.

    Alan Shimel:                Exactly. So the database is one of the last pieces of the stack to kind of get the message about doing more faster and getting sort of a DevOps approach to things, or agile.

    Varun Singh:               Yep, and essentially what customers are right now aiming at is to be able to get to a point where they really understand their database stack and have full control over their database stack. And we’re kind of becoming that one control panel that they look at every day and essentially find out exactly what’s happening, whether it’s new users that are logging in to their database stack or new queries that are being executed that have never been executed before. And what we’re providing them is that entire stack as well as the ability to do zero downtime maintenance, being able to mark a server offline in the middle of the day, put a patch on it, upgrade it, and bring it back online. And you have never been able to do it in the past because you would have always had a ton of application errors, and what we’re doing essentially is eliminating all of those application errors and providing a transactional engine that works with pretty much any application engine and allows that application engine to become a zero downtime app.

    Alan Shimel:                Excellent. Varun, for executives listening in on here, what do you see as the next frontier or the next thing that CTOs, CIOs, VP, managers should be looking for in terms of database management, database performance, database load and so forth?

    Varun Singh:               I think at this point in time, they have to look at figuring out a way to expand out, scale out and get to what we call shared nothing. Shared nothing is essentially a way to store database information on servers in a way that you don’t have to worry about interdependency issues. So each server is its own individual isolated zone and even if you have five servers, you can have four of them go down and the fifth one will still be alive. So that’s the architecture that I think everybody is headed to right now. That’s the architecture that MySQL sort of made famous, and now at this point of time pretty much all databases are headed to that architecture. And databases are getting more and more sophisticated. But apps really haven’t been able to use that because the issue right now is that quite a lot of these apps are written to older versions of SQL databases. So what we do is provide all the new features that are coming in from the new databases to the apps without a single change on the app.

    Alan Shimel:                Excellent. Varun, we’re almost out of time here, believe it or not. We try to keep these chats relatively short. But a question I always ask people ending up is, for people listening in, whether they be managers, C-levels or people who want to be managers or C-levels. If you had to pick one book to read that would help them further their career and understand what’s happening and where they need to be, what would that book be?

    Varun Singh:               I could give you two or three right now, but if you really want one as far as an entrepreneur is concerned, I think The Hard Thing About Hard Things is really still the flavor of the month. It’s going pretty well still, I’ve sort of re-read it twice and it gives new meaning sometimes if you re-read it because you’re sort of analyzing a situation from a completely different perspective, and it’s a pretty interesting book to read.

    Alan Shimel:                So The Hard Thing About Hard Things.

    Varun Singh:               Yes, that’s by one of the partners from Jason Horowitz – Ben Horowitz.

    Alan Shimel:                Ben Horowitz, sure, I know the book well. Varun, and of course if people want to find out more about ScaleArc, is it ScaleArc.com?

    Varun Singh:               ScaleArc.com, and we’ve got a whole bunch of videos, we’ve got some webinars, we’ve got a lot of other stuff available as well as customer case studies as well.

    Alan Shimel:                Excellent. Varun Singh – founder/CTO of ScaleArc – thank you very much for appearing today on DEVOPS Chats and continued success with ScaleArc.

    Varun Singh:               Thank you. Thanks for having me.

  • Roll-up your sleeves – Launch a SAFe® Agile Release Train

    Roll-up your sleeves – Launch a SAFe® Agile Release Train

    Most organizations often begin their agile transformation with a series of low risk, stand-alone pilots. While these pilots may prove that teams can adopt small team agile practices such as “Scrum” or “XP”, however these pilots often don’t help prove that your organization can adopt agile at the enterprise level.

    Scaling agile to support larger more complex programs requires gaining alignment across stakeholders, providing program-wide transparency, and delivering end-to-end value with a large number of teams to work together (e.g., 100 – 500+).

    A few months ago, I had the opportunity to launch an agile release train (ART) for a large IT project (110+ resources) at one of the financial institutions that IBM provides agile coaching and mentoring for.   The organization had been following a waterfall approach for most of their larger projects until last year when they were purchased by a larger bank that was already undergoing its own agile transformation.

    IBM was brought in to assess their current progress and provide additional training and recommendations for rolling out to large enterprise programs.   Our mission was to assist them with:

    1. Defining a set of outcomes that supported the expected business benefits and assist them in successfully launching agile programs
    2. Identifying the value streams – the long-lived series of system definition, development and deployment process steps used to build and deploy systems?
    3. Defining the Agile Release Trains – the virtual organizations formed around these value streams?
    4. How to launch an ART and what Support IBM provides for SAFe

    Here are a multi-part blog to help you launch your own train:

     

    1. Launching an ART. Where to start?

    In its simplest form, agile offers a lightweight framework for helping organizations build software using a rapid delivery approach to providing business value. As a result these organizations are able to significantly reduce the overall risk associated with software development while providing high quality products and services.

    Agile is a powerful tool for software development, not only providing benefits to the development team, but also providing a number of important business benefits to the client. In addition, many agile project teams have been able to overcome many of the most common project pitfalls (such as cost, schedule predictability and scope creep) in a more controlled manner.

    The first step in our approach was to conduct a short agile assessment (or feasibility study) to verify the scope, identify the current challenges and recommend an adoption roadmap to support the transformation for the program (110+ resources).

    Having helped a several customers with agile transformation projects along with the challenges and business outcomes associated with those adoptions, I was immediately concerned about our ability to coordinate across multiple teams.

    The organization had several waterfall programs underway and had successfully piloted Scrum on some of their social apps. The leaders wanted our help to adopt a multi-team agile approach where some parts of the organization would stay waterfall.

    After performing a quick assessment we identified the following organizational concerns

    Reedy 1

    After reviewing some of the most common approaches at the time, we concluded given the organizational challenges that the Scaled Agile Framework (SAFe) would be our starting point.   SAFe, created by +Dean Leffingwell‘s Scaling Software Agility, is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale.

    Reedy 2In most cases we have found starting with a small to medium size program is the best place to start when attempting to help an organization scale agile in their organization.

    Benefits of starting at the Program Level:

    • A couple of key business stakeholders usually have finally say on budget, delivery teams
    • Can select program within sponsors span of responsibility / influence
    • Requires more organization than going team-by-team, but significantly less effort than a “big bang” enterprise transformation
    • Makes visible the real challenges of agile at scale
    • Gives true, fact-based measures of enterprise agility… the ability to quickly deliver quality software incrementally in a large, complex enterprise

    Here are some of the challenges of starting at the Team level.

    • Have the organization / cultural impacts that a larger adoption would have
    • Provide the visibility to “move the needle”
    • Cover enough ground. Delays dealing with the real challenges of implementing agile at scale

    Here are some of the challenges with starting at the Portfolio level:

    • Working with too many In-Flight Projects
    • Taking on too are a structure to impact (.e.g, Chaotic Architecture and Bloated Technology Stack)
    • Working with teams outside the reach of the team to really impact them.
    • Requires lean-thinking leaders and an Agile PMO who understand lean economics
    • Can be delayed due to the complex organizational and cultural changes needed for a full enterprise transformation
    • Difficult to manage software “assets” in a Lean|Agile portfolio if asset development isn’t agile

    See here for additional information:

     

     

    2. Preparing for first Agile Release Train (ART) launch?

    For any IT project to be successful (traditional, agile or otherwise), it’s vital that it has a clear vision which can be used to guide the project team in the right direction. The team should review the vision regularly to ensure program is fulfilling what it has set out to accomplish.

    Here are 3 key steps that must be done before launching the ART.

    • Identify the initial set of Value Streams

    A Value Stream is a long-lived set of capabilities used to provide a continuous flow of benefits to the business. Value Streams are typically realized by 1 or more ARTs and are the primary organizational concept for understanding how value is delivered in SAFe.

    Reedy 3Here are some questions to help identify the Value Streams

    • What are the larger, ongoing programs or initiatives that will differentiate your business over the next 2 to 3 years?
    • How do external customers perceive the value you provide? For example what are the key products or services that you provide
    • Can you describe the strategic initiatives that have 200+, 100+ or 50+ more developers / testers working together already? Do they have a high degree of interdependence between the features and components?
    • What key business processes do you enable?   What internal departments do you support?
    • What key process, cost, KPI or business improvement initiatives are targeted in this upcoming year?

    For more information checkout:

     

    • Define Vision, Scope and identify Portfolio and Program Epics

    SAFe organizes large agile projects into an scaled agile program structure containing three levels: Teams, Agile Programs (also referred to as Agile Release Trains – ARTs), and Portfolio

    The Agile Release Train is the primary organizational and operational construct within SAFe. Each ART is a self-organizing team of teams, responsible for delivering business value. Ideally each value stream should be mapped to a corresponding ART, however in many cases ART may be needed to support multiple value streams or in some cases a single value stream may require the support from multiple ART to delivered the required business value.

    Reedy 4SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The agile program backlog (a.k.a, ART) containing a prioritized list of features and stories.  Portfolio epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries. Most organizations Business epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries.

    Reedy 5

    Weighted Shortest Job First or WSJF comes from a comprehensive model defined by Don Reinertsen as a way to improve prioritization. In IBM’s solution, WSIF is automatically calculated based on the Job size, Business Value, Time criticality and Risk Reduction/Opportunity Enablement values provided. Then, the Program Roadmap is automatically sorted based on the WSIF score and gives a ranked view of the features’ backlog. WSIF is an useful tool to help with decision making process based on factual assumptions instead of personal feelings.

    Reedy 6

    Features are usually decomposed into User Stories, which flow to Team-level backlogs, and can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features are prioritized based on Weighted Shortest Job First (WSJF) economic decision framework.

     

    • Ensure you have established “Whole Teams”

    SAFe is based on Lean principles where the minimal viable product (MVP) epics and features are identified scheduled based on both business needs and technical constraints / dependencies. Like Scrum, SAFe assumes each agile delivery team (typically between 5 to 10) people each have all the cross functional roles necessary to deliver working solution each sprint.

    Unlike Scrum, SAFe assumes some stories may depend on each other or that multiple teams may need to work on Epic before it can be delivered. Prior to launching the ART, important to ensure that each of the teams have been formed with the appropriate set of agile practices (i.e., Whole Team) and know how to execute the ceremonies associate with Scrum / XP.   Whole team is a philosophy that involves significant collaboration between the team mReedy 7embers and stakeholders.

    Each team includes all individual who materially define, develop and deliver software for a project:

    • Any and all contributors
    • Both direct and indirect participants, such as sponsors and key stakeholders
    • Together have the skills to successfully communicate the essentials of a problem and deliver an agreed solution

     

    Here are seven tips for building an effective agile team:

    • Does the team have the skills to get the job done – they are “whole”
    • Is the team as small as possible
    • Are the people dedicated to the project and is there a single product owner
    • Have a single team lead (who is not the product owner)
    • Are team members cross functional, made up mostly of “generalizing specialists”
    • May include specialists, hopefully on their way to becoming generalizing specialists
    • Are self-organizing within an appropriate governance framework

    The greater the deviation from this strategy, the greater your project risk

     

    3. How does IBM Collaborative Lifecycle Management (CLM) support SAFe?

    As part of the engagement, the IBM team led the effort to implement IBM’s Collaborative Lifecycle Management (CLM) solution to support the Agile Release Train (SAFe). IBM DevOps combined with SAFe provides a comprehensive process and tooling platform and framework that will optimize your end-to-end lifecycle, so you can synchronize development, testing and deployment across teams in heterogeneous environments, and collaborate across all roles in the organization in the planning and execution of software delivery.

    Reedy 8

    IBM’s SAFe support provides the following key capabilities:

    • Get up and running quickly with out-of-the-box infrastructureto lead a SAFe Program
    • Improve agility and predictability with dashboardsfor visibility to adjust business goals in real-time
    • Simplify change to culture and process with quick and easy access to SAFe guidance

    Reedy 9

    Each team works in fixed-length time-boxes, called iterations or sprints, which typically last from two to six weeks. At the end of the sprint, there is measurable product increment or (PI).

    Planning an iteration is simple: From the Product Backlog, the Product Owner (PO) and the Scrum team holds a Sprint Planning meeting to select the most important stories that can be delivered in the upcoming iteration. Once the set of stories are identified, the team breaks down the work into smaller tasks and assign it to individual team members.

    Reedy 10

    The Agile Planning capabilities in RTC, can assists you doing this by several means:

    • Plans are accessible to everyone in the team – Be transparent.
    • Plans reflect the team’s position and direction – Know when you are about to fail.
    • Plans are live as they ground on work items – No unnecessary planning artifacts to be taken care of.

    IBM’s approach included a set of accelerators specifically designed to help organizations adopt a Lean mindset to take their current agile projects to the next level. Agile Planning includes a set of development practices that allow teams to plan and deliver high quality software rapidly. For more details see: see the following value-added assets:

    Finally for those teams that are using Scrum methods, here is an article on using Scrum with Rational Team Concert (RTC)

    About the Author/ Reedy Feggins

    Reedy FegginsReedy is a Lead Agile Coach and Software Architect with certifications as a SAFe SPC, Certified ScrumMaster and PMP® certified project manager with over 20 years’ experience leading successful IT projects, employing a combination of Agile, Waterfall, and RUP processes. At IBM he currently works as a Agile Coach leading large and medium agile transformations. Reedy has published papers in several magazines as well as been an invited speaker at conferences. His experience as a trainer has led to the development of several custom workshops on topics ranging from Project Management to Process Adoption.

    Connect with Reedy on twitterlinkedin

  • Impacts of DevOps on Testing

    Impacts of DevOps on Testing

    DevOps

    I always come across a standard question from testers in any DevOps related presentation. “Will DevOps remove the need for Testers?” A simple answer is “No”. DevOps is not going to replace Testing as a discipline. Firms implementing DevOps have a vision for better product quality workable by brilliant Testing.

    DevOps is an enabler for the following.

    • Reduction in IT Budgets
    • Efficient end-to-end delivery
    • Lean delivery framework
    • Working end-to-end automation framework

    Successful businesses today are design thinking driven. Businesses have a strong sense of urgency, aided by innovative software engineering practices. Businesses today need to have a working continuous delivery practice in place. Continuous delivery also mandates better product quality and zero touch end-to-end delivery. Automaton is key to success across DevOps processes.  Delivery by co-located, integrated teams using innovative tools prevents collaboration and communication issues.

    Manual errors, Stove-piped communication issues get sorted with a good DevOps Governance model.

    DevOps mandates “Fail Fast, Fail Often” driven by “Test First” concept. This means that testing is a continuous process and more extensive in nature. Testing allows for cohesiveness between various teams, automation of everything possible. Testing also allows for continuous improvement in test process delivered via iterations. Intelligent test automation, improved regression, continuous test augmentation are some benefits delivered by DevOps.

    • Key benefit delivered byDevOps is the cost reduction in end-to-end delivery.Businesses achieve cost reduction by Automation, manual error reduction and reduction of duplicate effort.
      • Continuous delivery enables streamlined governance and reduces time-to-market.
      • With fail-first, fail-fast, fail-often philosophy, shift-left testing is a reality. With early defect identification, product quality increases. With increased automation, continuous testing is a feasibility.
      • With co-location, productivity of DevOps teams (design, test, operations) improves.

    Implementing DevOps could be tricky in organizations having monolithic systems and processes. Culture change is critical for successful initiation of DevOps and Continuous Delivery.

    From a testing standpoint, DevOps addresses the following key testing challenges.

    • Test Environment – Virtualization, Automated Deployment, Automated build and configuration management, data refresh and maintenance becomes simple
    • Continuous Integration, Automation and Verification – Test First centric test driven development, behavior driven development concepts allow test processes to improve in a DevOps Model

    As per a report published in 2002 by NIST – Cost of Poor Quality (in US) was $59.5 Billion per year. Cost of poor quality is higher in large organizations running legacy infrastructure. By some industry guesstimates average cost of a production bug is about $7000. Customer experience and agility for quick delivery takes a hit if the organizations aren’t quicker. DevOps becomes a positive catalyst here.

    Some skeptics may say “DevOps looks easy on paper but difficult to put in place”. Any innovative change is difficult to implement at first. It takes discipline and drive to run the operations watertight to achieve the goals.

    Some key factors to implement for Successful DevOps are

    • Cohesive, One Team mentality between teams
    • Implementation and Use of Tools that take away manual effort
    • Continuous Delivery Phases
      • Superior, Automated Configuration Management Approach
      • Continuous Improvements across phases
      • Continuous Automation
      • Continuous Integration
      • Continuous Testing
      • Continuous Monitoring

    Use of tools is key to success of a DevOps program. Plethora of tools are available to support automation. Tools are available for Environment Build, System Configuration, Application Build, Database Setup, Artifact/Document Generation, Testing, Requirement Management, Collaboration, Production Monitoring, and Reporting across DevOps activities.

    Like Agile Delivery Programs DevOps needs a strong Team Cohesion to be successful. A DevOps team need to have a Product Life-cycle Management mindset as well. This also means that team needs to unlearn standard SDLC processes.  This means, DevOps team should have a clear vision. Vision to Ideate, Implement, and improvise and retire the product. An integrated DevOps team with clear vision will make DevOps projects successful.

    Conclusion:

    DevOps testing needs to address the need of Business and Technology needs. Automation plays a major role to achieve this aim. DevOps in principle has a goal for better product quality albeit the need for faster delivery. Terms such as “Shift-Left”, “Fail-First, Fail-Fast, Fail-Often” will be regular vocabulary in DevOps. DevOps Test team comprises of Cross Functional Specialists and Testing Purists. A Performing Testing Practice for DevOps will take some time. Testing as a practice has matured over the past two decades and is well equipped to support DevOps. Use of automation and productivity enhancement tools helps testing move faster.

    Successful DevOps implementation in large firms with legacy processes and technology is a challenge. A big culture change is the only way to achieve success in such firms. It will be a hybrid DevOps Model as purist implementation will be a challenge.

     

  • Five things to understand about Enterprise DevOps Solutions

    Five things to understand about Enterprise DevOps Solutions

    There is a lot of buzz in the industry around selling and consuming DevOps. Unfortunately there isn’t the same level of understanding or even a common definition about DevOps between consumers and service providers. In my experience the past couple of years of evangelizing DevOps, the following 5 aspects come to my mind as critical factors while considering and implementing enterprise DevOps solutions:

    1. Evolving Architectural models

    If you are a geek like me, and if you haven’t heard any of the following terms, you’ll probably google them immediately – Container technology, Microservices architecture, single page web apps (SPA), Node.js, mobile web apps, The Internet of things (Mobile awareness, sensors & wearables etc.), web APIs – these are the current trends in the application development space. Almost all of them disrupt traditional architectural models. And the reason I point this out is because they’ll also disrupt your traditional software development lifecycle (SDLC). The number of code & deployable units is only going in one direction, and that’s up. Very rapidly actually! That means source code management, build management, deployment & release management, dependency management, all become so much more relevant and cumbersome. The ONLY meaningful way to make these kinds of disruption manageable is through a mature DevOps approach, and a robust platform to enable DevOps. Developers always want to do the new and coolest thing. Enterprises will be well served to adopt a DevOps strategy NOW, before their own developers will cause so much disruption, that their IT strategy may fall flat.

    1. Integration with existing security and governance models

    More and more enterprises are headed towards a hybrid model of IT which involves traditional on-premise data centers, public cloud, private cloud and consumption of domain specific Software as a Service & Platform as a Service capabilities. Hybrid model also poses the same kinds of challenges discussed with some of the new architectural trends. How do you manage releases across so many disparate entities and providers? A centralized DevOps strategy can help mitigate issues posed in a hybrid model to a large extent. But the question is – what about the corporate policies around security and governance? Do we throw away existing tools & capabilities around change management, ticketing etc.? Disruption is a good thing for innovation, but too much disruption can also lead to disastrous outcomes. One of the key challenges that I’ve encountered while implementing an enterprise DevOps solution is to integrate the platform with existing security models and tools. Not all of them work together seamlessly all the time. But the key to success is to evaluate where the gaps are, and only bringing in new tools or capabilities where necessary, and not just for the sake of it (sell a solution, not a bunch of products).

    1. DevOps enablement

    One of my mentors in IBM used to say, that “a fool with a tool, is still a fool”. How true that is in the world of DevOps! Tooling is a key ingredient towards automation. In fact the concept of DevOps is not new at all, but the kinds of tools available today make automation possible in so many levels that was unthinkable a decade ago. But just providing a platform of seamlessly integrated tools for SDLC isn’t going to work. A level of “design thinking” is absolutely necessary towards DevOps enablement. A DevOps engineer should always be slotted in as a key member of this enablement team. Someone that can coach teams while starting new projects on – What elements of the tooling would apply for them? How to on-board the DevOps platform? What elements of automation are already available vs ones that’ll need to be newly created? What will be the roles and responsibilities of current team members in a DevOps world? – These are the elements that enterprises struggle with. Without a credible enablement program, a DevOps strategy is bound to be very slow in adoption, or just simply fail.

    1. Transformation Investment

    An enterprise DevOps platform and enablement program doesn’t come for free. I’ve constantly been challenged with questions like – what Line of business (LOB) is going to pay for it? Can’t we just use “open source” and make this all free? Can we only pay for what & when we use? All these are fair questions. And the debate about centralized IT expenditure vs LOB expenditure isn’t a new one, and will not go away either. But DevOps is disruptive enough and WILL challenge some of these old ideas and habits. “Automation as a Service” is certainly a viable option that can be availed on a consumption model. Open source tools are available by the dozen. And what comes for free with open source tools is just the usage license, and nothing else. You’ll still have to integrate them with your platform, still write automation scripts and manage them, and enterprise grade tools are usually not totally free and there is some cost involved in acquiring and managing them. All that being said, DevOps IS very much an investment. It is an investment for speed of delivery, higher quality of deliverables through automation and perhaps some cost take out in the form of reduced or re-assigned resources that were performing traditional activities in SDLC. There are several models to ascertain return on investment (ROI) on such investments, but I’ll refrain from getting into that discussion in this article. I’ll just leave this with the infamous cliché – there is no free lunch!

    1. Top Down vs Bottoms up buy-in

    Typically I’ve been involved in DevOps strategy conversations for enterprises at the executive levels, and they seem to be all over it. They love some of the cost take out numbers when they see it, deployment cycle time reduction and aggressive time to market fascinates them. And legitimately so. Getting executive level buy-in and support is absolutely key for any transformation to be successful, DevOps included. But just a top down approach isn’t going to make DevOps successful. It is imperative to reach out to developers and architects under each tower or LOB and get their buy-in as well. Developers and testers love their tools and methods, and are very unwilling to give them up if the strategy calls for standardization of tools (which, by the way has to happen to some degree to gain efficiencies). DevOps also redefines roles in development and testing teams through the level of automation it brings in. This causes a lot of grief amongst the staff, and as a service provider and enabler, I’m sometimes perceived as the ‘enemy’, which is never a good sign for a successful transformation. Developers and testers also have the domain knowledge around how builds are done today, what the application component dependencies are, what test scenarios are more relevant and so on and so forth, information that is so critical to understand for automation. Make friends with the developers and testers to be successful.

    About the Author/ Sunil Joshi

    Sunil JoshiSunil is an Executive Architect with IBM. He is currently the Application Development & Innovation (AD&I) DevOps offering owner for Global Business Services. He is IBM Senior Certified and Open group certified Distinguished Architect. His specialization are in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. He’s created complex hybrid solutions on cloud and DevOps for large enterprises. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA).

    Sunil is passionate about international music, multi-cultural cuisine, active sports and mentoring school & college students on career path and technology.

    Contact Sunil on  linkedin twitter

  • Steer SAFely – Driving collaboration across multi-disciplinary teams

    Steer SAFely – Driving collaboration across multi-disciplinary teams

    This is the second blog in the DevOps – Scaled Agile series. In the first blog, Scaling Lean and Agile for the enterprise: All hands on keyboard!!!, we discussed the characteristics of a successful enterprise agile transformation and described why engagement and commitment across all disciplines in the organization is not just optional, but required, to ensure you deliver differentiated value. Business and IT must be in sync because, as we have learned through experience, successful agile team-based development does not by itself guarantee organizational success.

    What does it mean to “be in sync”? How do we do it? Well, you Steer SAFely, of course. I know, a cute play on words, but just think about it for a moment. Consider a typical “day in your life”. From the time you wake up, you navigate through your day crossing paths with others along the way and continually adjusting in response. Your husband beats you to the shower, so you go get another cup of coffee. A guy crosses three lanes of freeway traffic (in front of you!) to get off at an exit he’s nearly missed, so you slow down a bit. You get a last-minute request to do something by the end of the day, so you engage with a colleague to get it done. Some of this is more reaction than collaboration, but nonetheless it is a siAmy blog 1mple analogy for Steer SAFely: Steer, which implies a series of continual adjustments to enable you to maintain course, and SAFely, which applies guidance and best practices as you Steer. The notion mirrors some of the basic concepts embraced by the IBM DevOps framework:

    • Being aware of your surroundings (understanding dependencies)
    • Recognizing and avoiding risks and roadblocks (monitoring and adjusting based on feedback)
    • Working with others (collaborating)

    Clear as mud? In a nutshell, to Steer SAFely means, as an enterprise, you are applying lean and agile principles to accelerate value delivery. To be successful requires collaboration of multiple disciplines across business and IT, continuously, from planning to development to deployment to delivery and then back to planning in response to feedback.

    Let’s explore how you do this.

    Step 1: Shift how you act and make decisions:

    1. Focus on delighting the customer instead of making money. Making money is the result, it should not be the goal. This notion is specifically enforced in the SAFe Portfolio layer, which requires the organization to take an economic view to help guide business priorities based on an understanding of the value of something versus its cost.
    2. Reconsider the role of bosses. Management’s role is to enable those doing the real work to be as efficient as possible by recognizing and removing impediments quickly, end-to-end. Agile used to mean “no management”, but enterprise agile is not the same. You need managers but their role is different. The SAFe tiered approach clearly describes the responsibilities and activities of managers at each level so that there is no confusion.
    3. Avoid steering top-down or bottom-up. Neither of these methods leads to success. Instead, drive collaboration horizontally across the organization and involve all disciplines early and often in the decision-making process. SAFe explicitly addresses this notion through a set of well-defined events and activities that are designed to engage the entire multi-disciplinary team.

    Amy 2

     

    Step 2: Ensure the transformation completely addresses all aspects of the environment:

    1. People: Establish an organization-wide culture with the right set of skills to embrace lean and agile values – everywhere, across all teams, every day
    2. Process: Apply lean and agile principles in the planning, development, deployment and delivery of value and then monitoring feedback to improve – continuously
    3.  Tools: Provide a framework that enables the implementation of lean and agile practices – easily

     

    The trick is to balance efficiency and effectiveness so that you can answer these questions in a positive way:Amy 3

    • Are we moving as fast as possible? Efficiency in execution is achieved through lean practices to minimize waste and maximize time in value added work.
    • Are we driving in the right direction? Effectiveness in execution is the result of smarter steering by quantifying value and cost tradeoffs through continuous feedback and better delivery analytics.

    Step 3: Adopt (at least) these three SAFe concepts:

    Kanban System: Kanban embraces lean principles to ensure that you invest just enough at the appropriate phase of your lifecycle within your capacity to do so. SAFe describes a phased analysis approach bounded by Work in Progress (WIP) limits and grounded in economic thinking to quickly rank work based on not only value but also cost.

    WSJF: Weighted-Shortest-Job-First is a value assigned to each of the key SAFe artifacts: Portfolio Epic, Program Epic and Feature. This value essentially defines an estimated return on investment and enables your team to consistently and relatively rank work across the Portfolio to drive priorities down to the Teams. Use of WSJF enforces the economic view in planning because it ensures that both value and cost are considered as you prioritize work.

    PI Objective: SAFe describes a Program Increment (PI) Objective artifact at both the Program and Team levels as a way to document expected and realized value in a relative way. Here, as with WSJF, consistency and relativity are most important, not precision. PI Objectives are also a way to capture the notion of acceptance criteria, which could guide solution-level validation.

    To learn more about our thoughts on SAFe and DevOps, try this: SAFe® with the Power of IBM DevOps.

    And please join IBM at AgileDC, October 26, 2015, Washington D.C. Submit a proposal through August 15, 2015. URL: http://agiledc.org/2015-call-for-proposals/

     

    About the Author/ Amy Silberbauer

    Amy SilberbauerAmy 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 Systems – Application Platform 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 28 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