Category: Doin’ DevOps

  • App Dev: Stop Spinning Wheels on the Spinning Wheel

    App Dev: Stop Spinning Wheels on the Spinning Wheel

    When it comes to websites and apps – speed matters; today’s consumers want everything yesterday. Recent studies show that there is no surer way to lose the trust of a consumer than to produce an app with sluggish performance. Recently, Amazon reported that for every tenth of a second of latency, sales decrease by one percent. Furthermore, almost half (48 percent) of consumers stated that they immediately uninstalled an app after slow performance. That’s a huge cost that translates directly to the bottom line.

    Today’s websites and applications are hyper competitive when it comes to user experience (UX). Consumers are educated – and if the digital experience isn’t engaging and effective, they will leave for a digital channel that does deliver that experience.

    The problem lies in the collaboration between UX designers and line of business teams. UX designers load up their sites and apps with cool content and hot third party JavaScript for a strong visual appeal. Following that, teams who are looking at competitor’s digital properties ask for even more content to be added in hopes that the app will be even more useful. Unfortunately, with this strategy, the end result is an incredible experience that probably performs somewhere between “eh” and “terrible”. Off go the consumers because the one thing they hate worse than something boring? Something slow.

    So, it’s tough being a designer; contrary to popular belief, the reality is that web loading speeds on average are actually getting slower on a global scale. As more users flock to social media, and ecommerce sites to get their fix of images, videos and interactive plugins, web speeds have been plummeting. Factor in that 50 million people in the U.S. now watch streaming video on mobile phones, and the issue become clear. High-speed Internet is no longer enough to get content to consumers in a timely manner. In fact, you have to assume high speed is irrelevant because so much interaction is now “over the air” mobile.

    The question now becomes, what can designers, developers and organizations do to maximize experience and keep things fast in a world where performance is slowly degrading?

    Testing is Mission Critical

    It’s not rocket science that before a website or app is released into the wild, it needs to be tested and then deployed it in a way where it can be monitored to check it for performance issues, or any bugs that might annoy users into never looking at it again. The “it will get better” model of the past is dead. You have to get it right the first time.

    However, testing and monitoring once isn’t enough; because there are so many variables that are introduced by 3rd party content – from a paid ad slot to an image to logins for social accounts to all the various marketing tags. A failure on the part of any one of these sources can damage performance. Furthermore, those third party bits are part of long chains of infrastructure themselves– with lots of exposed weak points. If your third party social media login JavaScript object can’t communicate to its house – or the pipe it’s house uses to talk to Facebook is down, all the consumer knows is that they won’t be back.

    As good of an idea as it may seem to drop in one more marketing or advertising capability to increase the revenue generated by applications, it needs to be tested and monitored first to make sure it doesn’t have the opposite effect. Without fully assessing the risks associated with the addition of these services, it’s hard to evaluate whether it will help or hurt the business.

    Finally, be sure to load test at different traffic levels. It can be easy to focus testing on best-case scenarios, but be aware that once released, apps need to perform under a whole host of different network conditions.

    Keep It Simple, but Don’t be Stupid

    Design is always a balance between the desire to give consumers more functionality and a more interactive and friendly UI. For many organizations, this means coming up with something snazzy, and then having developers and operations make sense of it to enable performance. So – often to avoid potential points of contention – the bias drifts towards being safe and ensuring performance at minimal cost.

    Ultimately, the best experience will equal more sales, more views, more consumers, and better ROI. It actually is rooted in economic fact – the experience can and will drive more revenue, but only by investing in support.

    So, how do you maintain and stretch experience without blowing up performance? The key is being predictable by spending time on research, evaluating different options and constantly testing them to see what provides the right balance of experience and performance. Just because you have been using the same social media JavaScript object from a well-known source doesn’t mean you shouldn’t always be comparing it against other alternatives. And given that at least 30% of web pages come from third parties, this means there is a lot of continuous monitoring and research to do.

    Scientific Method

    Ultimately what we are doing here is taking the artist’s mindset of maximizing creativity, and applying the scientific method. Researching all those third party options and checking their performance – before presenting to the DevOps team – provides the ammunition to show that it’s possible to affordably deliver great performance and a great experience. Then, partnering with DevOps to constantly monitor third party content makes sure that at the first sign of degradation, backup providers are waiting in the wings to be deployed.

    About the Author/Adam Thier

    adam-thierAdam Thier is the Executive Vice President of Engineering at Keynote Systems. He brings Keynote over 25 years of software development and product experience ranging from a number of successful startups through engineering leadership roles at industry leaders such as SAP. In particular, he is an expert in analytic applications, predictive analytics, massively parallel in-memory databases, and columnar store processing.
     
    Prior to Keynote, Thier was the Senior Vice President of Frontline applications at SAP, and prior to that ran development for Hyperion’s applications portfolio prior to its acquisition by Oracle. Thier is an avid proponent and practitioner of design thinking and credits most of the success of the products he has been responsible for to deep engagement with customers and continuous co-innovation.  Thier has a BA from Marist College.
  • The 3L rule, a general piece of advice

    The 3L rule, a general piece of advice

    What I am going to describe will sound elementary to most of you, even trivial but I know that there is a difference between being aware of something and actually doing it.

    I have been working hard to spread the DevOps word these last few years and through experiences, project, conferences and articles I have come up with my very own little personal piece of knowledge; what I call the 3L rule.

    Learn from the world.

    This is the easiest of the three. Use Bing, Yahoo, Google, blogs like www.devopsy.kinsta.cloud, specialized websites, books and everything you want. The world is now at your reach, thanks to the internet and the wide spreading of smartphones. How many persons in the bus or metro around you are watching a screen nowadays? How many of those are actually watching the screen and learning something new? I know I see many playing cwazy cupcakes or any other game that is a time killer. However, they are exactly that, time killers.
    Why would you want to kill time when your brain is most likely craving new knowledge, begging to use it for more than just identifying a simple pattern on a screen, dodging monkey poop or even cutting fruits? On a personal note, if you really feel like a samurai, go cut some fresh fruits and make yourself a nice juice.
    The internet is available to you at all times with an almost infinite amount of information to collect. I am not telling you to stop playing, I am a hardcore gamer myself, but for your brain’s sake, you have to diversify activities. Do not always play, your brain is a sponge, make it absorb data or it will go dry.

    Learn from those around you.

    This one is a bit harder; it requires a couple of things:
    – Some attention span: it is not always easy to be ready to listen to someone when you reach your tenth hour of meeting of the day (but then maybe you should learn to better plan your days) but try to make an effort. Many might disagree with that but most meetings have a message to convey. It might not be the main topic but a well-driven meeting can be a valuable source of information. To figure it out, the only way there is, is to actually listen to the person talking.
    – Empathy: some persons struggle to get their message through, not matter how important it is. That is where you should try to demonstrate what might be a new skill: empathy. Instead of watching the speaker desperately and painfully trying to make a point, why don’t you try to help him/her. Do not jump in with what you know, that is stealing the light, instead why don’t you ask a question to put him/her back on track? It’s super easy and by making a human contact (mute people in meetings can be scary), you create a link with the presenter and might relieve some of the stress.
    – Capacity of analysis: people do things around you, all the time. They work, they speak; they create value. If you are at the office right now (you should not be reading this but please continue), look around you. Take a quick break and go ask one of your teammates what he/she is doing and why. You might actually learn something. Do this repeatedly until you got the whole picture of who does what. Then try to wonder why and repeat the process many times until you reach the big bang. Through every single iteration, you will most likely learn something new. Forest Gump used to say: ”life is like a box of chocolate: you never know what you’re gonna get”. I prefer to think that life is like a puzzle, it is up to you to put the pieces together.

    Learn from yourself

    The hardest of the three rules.
    You are flawed. Humans are flawed and make errors. What makes us worth something though is that we can actually learn from our mistakes. Once again, the big question you should ask yourself when facing an error is why.
    Why did that happen? Was there an error in the process? Did I misunderstand something? Do I lack knowledge or skill to perform that task? Did I not get enough time to perform that task? Ask yourself all the questions you need until you can come up with a definitive answer.
    When you do, that is where the tricky part starts. If you are to blame for the problem, make sure that if you were to redo the same task there would be no chance of the same error happening again. Fix the process, correct the documentation, train yourself, speak up! If this is someone else’s fault, do not point fingers, you are not in third grade anymore, instead help that person to do a better job so that, in turn you can perform your task as expected. Who knows, that very same person might help you one day.
    The problem with that rule is to admit that you might make mistakes. Once again, humans are flawed and it is only normal to fail every now and then. Some of the greatest things were invented by mistakes: the tarte tatin, corn flakes or even the microwave oven. Maybe you will create something life changing too.

    While that 3L rule should not surprise anyone, especially people in IT where learning is key, I find it a good reminder and always recommend everyone to apply it. It works very well in our domain since it is evolving so fast but it can be applied to everything really. Try the last rule with your better half for example, this might prevent conflicts to come like another fight about why you washed a pair of black jeans with his/her white underwear.

    Good learning!

  • Steer SAFely – So how do you do it?

    Steer SAFely – So how do you do it?

    This is the third blog in the DevOps – Scaled Agile series. In the previous blogs, we discussed the characteristics of a successful enterprise agile transformation and provided specific guidance on applying lean and agile practices at an enterprise level. We covered the “why” and a bit of the “how” at a high level, making the case for the need to address all aspects of a scaled agile transformation –people, process, and tools – to achieve success.

    By now you should be asking “where’s the beef?!” You get it… now you want to do it. Great! Because we have tooling that can help. Yes, tools are just one aspect of the transformation to a continuous delivery model, but man, wouldn’t it be nice to have tools that just support enterprise scaled agile methodology out of the box so you don’t have to think about that part and get on with the hard stuff – like the cultural aspects of this transformation?

    The Scaled Agile Framework® (SAFe®) provides the “rules” for scaling lean and agile across the enterprise; the tools support those rules to get you up and running quickly.

    Let’s start by breaking down the organizational structure: SAFe v3.0 describes a methodology for scaling agile and lean across three organizational layers:

    • Portfolio: Where investment decisions are made. This is the heart of economic planning, where programs are aligned with the enterprise strategy. There may be multiple portfolios in an enterprise, even within a line-of-business. The decision hinges on strategy and funding; a Portfolio has its own strategy and its own bucket of money.Amy Blog 1 pic 1
    • Program: Where funding and strategy meet planning and execution. The Program has the resources allocated to deliver on the strategy. Programs are long-lived and require a persistent structure and mission, so they are not exactly equivalent to business-driven “projects”, which might typically have start and end dates. That said, Programs deliver capabilities in support of “projects” through their contribution to Portfolio Epics. And we will discuss more on this later.
    • Team: Where the real work gets done! Teams are solely responsible for defining, building and testing their own user stories that contribute to value delivery for a Program. They are independent and self-governing, but they do operate in lock-step with other teams to deliver software aligned with the Program vision and the Portfolio strategy.

     

    With me so far? The tooling that supports SAFe encapsulates this organizational structure, giving you places to capture things like budget, strategy and roadmaps at a Portfolio level along with the “change” artifacts – the work items that identify what will be delivered by the Programs and how it will be delivered by the Teams. By providing a system to hold the data, we can also then provide visibility into status and health of executing Programs and the means to report on trends to demonstrate measured improvement – or not! – as your transformation evolves.

    Let’s explore the tooling bottom up, as that is typically how most organizations get started with SAFe.

    SAFe Program/ Teams

    SAFe Programs and Teams are supported in IBM Rational Team Concert. A process template is provided that you can use to create a Program project area with Teams as team areas within the Program. Alternative topologies, such as Teams in their own project areas or even using third-party tooling, can also be supported.Amy blog 2 pic 2

    The process template provides:

    • Project Area Initialization
    • Work Items & Attributes
    • Plans (Roadmap, Kanban, WSJF Ranked List)
    • Reports
    • Process Guidance

    Everything you need to quickly initiate a new program and kick off program increment planning, is available and ready for your team to get started.

    SAFe Portfolio

    In the next release of the Rational Collaborative Lifecycle Management (CLM) solution, IBM will provide support for the SAFe Portfolio, rounding out our SAFe V3.0 support. As with the Program process template, the CLM Lifecycle Project Area template will provide a Portfolio tooling infrastructure that joins change management with requirements and quality management to fully support the execution of the Portfolio. Through a set of template, we provide you with:

    Amy blog 2 pic 3

    • Portfolio Artifacts & Attributes
    • Plans (Roadmap, Kanban)
    • Reports
    • Process Guidance

    As a starting point, the Portfolio includes a set of Programs as team areas, allowing you to easily identify the resources involved in each Program.

     

     

    SAFe Key Concepts

    In the last blog, we discussed three key SAFe concepts that we believe are required to achieve success: Kanban, WSJF for relative ranking, and PI Objective to capture and assess value delivery. Each of these concepts is supported by the tooling.

    Kanban System

    At both the Portfolio and Program levels, the tooling provides a Kanban plan view to enable your team to drive relative ranking and prioritization discussions based on the Kanban System.

    Amy blog 2 pic 4

    WSJF

    To help your Program drive backlog planning, the WSJF Ranked List view is provided with the capability to actively lead a planning session making changes in-line to create a ranked list of Features.

    Amy blog 2 pic 5

    PI Objective

    The PI Objective is a work item artifact provided by the Program process template, allowing you to capture planned and actual value delivery consistent with SAFe guidelines. In the next release, we will also provide a new calculated attribute that captures the percentage of value (actual / planned) so that we can provide trending reports that demonstrate the Program’s ability to deliver value over time.

    Stay tuned for more with the next few blogs in the series coming soon. Till then do read the last 2 blogs if you missed them earlier – Scaling Lean and Agile for the enterprise: All hands on keyboard!!! and Steer SAFely – Driving collaboration across multi-disciplinary teams.

    Also, learn from the experts here:

    To learn more about our ongoing SAFe support, visit the SAFe Landing Page: http://ibm.biz/safesupport. We look forward to your feedback! 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

  • Why I became DevOps Certified

    Why I became DevOps Certified

    I usually do not care too much about diplomas or certifications. To me, one’s value isn’t reflected by a piece of paper but rather by his or her actions, dedication, motivation and efficiency. And yet, I decided to become DevOps certified and furthermore, become a teacher for that very same certification. Have I gone insane or did I make a choice based on reasons that could appeal to you? Read further to find out.

    Set up a standard.

    I have been advocating DevOps for years now, reading everything I could about it when it was just a fun word created by Debois and recently writing quite a lot and giving conferences about it too. One thing that always strike me is that, no matter the context, no matter the experience of the people I’m speaking to, there is always one person asking me: “but can you tell me what exactly is DevOps?”.

    DevOps strength is also its weakness. By not defining a manifesto, a chart of good conduct or even a clear definition, DevOps leaves room for improvement over time but also creates what it tries to break down: silos. By being so undefined, you end with people “in the know” and the others who are desperately trying to get a grasp of an idea that’s clear to many.

    A certification, while arguable, brings exactly that level of standardisation we needed. By enabling me to have a clear definition of what DevOps is, it gives me the opportunity to spread it further but not only that, I also finally talk about the same thing as others around the globe. Gone are the days where you would see a new definition a minute, now that we all know – and agree on – what we are talking about, we can finally start to actually do it.

    I could have stopped here, taking the certification, being all knowledgeable about that topic but it would have been a bit against DevOps’ philosophy. Sharing is caring and if I get people to understand at least the basics of I what I preach, then we understand each other better and I make others better at their job (hopefully). And that’s exactly why I became a teacher: to spread the word and get people who don’t know to finally know. People over everything else, right?

    The DevOps Institute.

    Ok this part will sound a bit like a commercial but I’m just going to explain the reasoning behind my decision to go with that one.

    There are many certifications about the topic popping up these days so it was not necessarily an easy decision to make. After all, since we are still discussing whether or not to have a certification on that specific field, nobody was more legitimate than another. And then I read this article by our dear Alan Shimel: here.

    The fact that his name was associated with a certification intrigued me and I went to check it out. Then I realized that names I was already familiar with were also a part the institute (Lisa Schwartz and Jayne Groll) which made me think I was actually facing serious people.

    I read a bit more about them and discovered that both Gene Kim and Sanjeev Sharma, two persons I highly respect and read a lot from, were part of the institute’s board.

    That was it! It all went super-fast after I took contact with the institute. I filled up the usual forms and in no time, I was in the program, training myself to become the trainer, reading even more about DevOps, learning some new things and exchanging with brilliant minds before taking the final exam.

    What it all means

    While it won’t change your life, those of you who wanted to become unicorns still have to buy a costume for that, becoming a certification trainer gives you the opportunity to meet and help people who want to know more. Whether or not they take the actual test does not really matter. What matters is that you hold the same speech as others around the world and that people who come to you with questions might leave with a bit better understanding of what it is that you talk about.

    Before comments rain down on me, telling me that this is heresy and that I should be condemned to watch Nyan cats for 48 hours non-stop, I just want to precise that I do not have any interest in anything other than my job. I am just advocating for a certification and explaining why I took this one more than another.

     

  • Defining On-Prem

    Defining On-Prem

    Sometimes, the meaning of a word or a phrase changes so quickly that you don’t even notice that it’s changed; at some point, you just realize that you’ve been using it differently.  Take “on-prem,” for example. Not too long ago, if you said that a component of your IT system was on-prem, you meant that it was physically located at your facility. If it was hardware, the hardware was in the IT room down the hall. If it was software, it was running on a server in the IT room. But today it means something entirely different.

    (more…)

  • Code Review – Write your code right

    Code Review – Write your code right

    Writing code is definitely subjected to individual thinking, logics and perspective. How one writes code is completely depend on their technical and logical skills. Two different people can write the same code in an entirely different tactic (May be both logics of the code are right in their own way). Even two persons can write bad code as well as good code as per the same standard.

    In the real world it is most likely possible that one writes the code and same will be read multiple times by many other developers to fix the bugs, improve the features, understand the code. That is why each language has its own style of coding and guideline to make it more meaningful and understandable.

    Most of time the Developers struggle to understand the code written by someone else on the team. I have even heard people saying that it’s difficult to read someone else’s code rather writing same from scratch.

    I would like to highlight a few compiled techniques in once place to make writing code better.

    Classical Method

    Classical method is a tools based code review. Developers write their code and submit it for review in some 3rd party tool like review board, Rietveld, or Collaborator for somebody to review the code.

    The tool will be used to track code changes comments, patches and review. Someone can merge code to the active branch once it is reviewed. Reviewers can have a look at the code and provide comments and inputs to the relevant piece of code.

    The good side is that it can be used for almost all sorts of old source code tools and is very much compatible with most of the version control tools.

    The problem with this mechanism is that it needs another tool other then version control system to maintain code review related information.

    Integrated Method

    To overcome the classical method downside, review systems have been introduced with in version control tools; a very good example of this is GIT. Where there is no (or rarely) 2nd tool needed to perform code review activity. Code review can be done via pull request even before merging. Comments, issues, patches can be tracked within Version control system with same workflow.

     As mentioned earlier everything related to review remains with in the same system and that is the biggest benefit of this system.But this mechanist also needs the same time and effort for someone else to go through the code and sign off.

    Extreme Workflow

    Pair programming falls under this category. In this Technique, two programmers work as a pair together on one workstation. One writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

    This way coding and its review happen at the same time by 2 programmers simultaneously.

    Some say that 2 developers working on same code at same time doesn’t make any sense, as they will be end up spending double man hours. It may lead to problems with practical implementation of the technique.

    But the good part is that they don’t need to spend extra time to understand and perform code review. It removes to and fro communication between developers. You don’t even need another tool for additional help to submit patch.

    In conjunction with review techniques I would like to add one more point about who can review code.

    • Leaders review the code: – One of the very common processes is that 2-3 leads will review the code always from the entire team (number depends on team size). They are always whole responsible for performing the review, checking the code before it goes for further consumption.
    • Anybody can review the code: – Another technique is that anybody with in team can review the code. Only restriction is that the one is writing code cannot review his own code because this doesn’t make any sense to review your own written code. There is no leader who is responsible for code review. A junior programmer can also review code written by senior, as there is no reason to allot hard role and not allowing others to review code.

    Whatever practice we use it is very necessary to have a look at code by another pair of eyes and have code reviewed.

     

    References-

    https://en.wikipedia.org/wiki/Code_review

    https://en.wikipedia.org/wiki/Pair_programming

    http://www.scmtechblog.net

  • The Second “S” To A Successful App: Simplicity

    The Second “S” To A Successful App: Simplicity

    When developing an app for the first time, there are important factors that need to be taken into consideration, such as scalability as previously discussed. Ensuring the app can scale with a growing user base is paramount to success, but how do we ensure the user base will steadily increase? While there are a plethora of factors that lead to app success and increased downloads, one to keep in mind is simplicity. Every app essentially starts as a simple idea, yet can easily become packed with unnecessary features and lose its focus and core purpose.

    Keeping an app simple starts with understanding the market need in the beginning of development, not losing sight of the app’s core purpose and understanding which features are most critical to the app’s functionality.

    How simple is too simple?

    There is a fine line between simple and too simple and developers are often faced with the challenge to find the right balance between the two.

    Finding that balance is a difficult feat, but not impossible. It begins with determining how the app meets the market’s need and building the app to meet it. From there, the app’s feature set can increase. Push for Pizza is a great example of an app that has one simple purpose: allow its users to order a pizza with a single push. The user simply chooses which toppings they would like, pushes the pizza button within the app and it’s on its way to their location. Push for Pizza began as a simple idea and the developers built an application to meet the demand. From there, the app has seen great success and has increased the feature set, such as the ability to add coupon codes.

    Using simplicity to create customer delight

    The moment of customer delight is a manifestation of having a really simple but powerful idea. There are few apps that have created customer delight by doing something for the first time or presenting an experience in a new way. The best example is Uber. When the service launched, users for the first time were able to see the cars moving in real time, which was unlike any other taxi or ride sharing experience at that time. Uber offered a completely painless service and has changed the way people travel.

    Using simplicity to create customer delight comes from focusing on doing one thing, and both Uber and Push for Pizza do it well. However, that moment of customer delight is hard to achieve; but when it is, the app has accomplished either something simple or done something complex but presented it in a simple way. The key to customer delight is focusing on the app’s core purpose.

    Be original and don’t take short cuts

    A current trend in app development is the “hamburger menu,” or the three line button within the app that pulls out to the app’s menu. There is pushback in the developer community on this type of design because there isn’t any taxonomy for what will be included in the menu itself. The hamburger menu is working against simple apps and is hurting effective user interface (UI) design. Effective, and successful apps should be guiding the user through each stage or feature in a simple manner, not using shortcuts to jump to the end.

    Instagram is a great example of an app presenting features and menus in a new and simplified way. The app walks the user through each step with the appropriate feature set as opposed to throwing each feature in one pull out menu. To achieve the same type of simplicity, stay focused on what the core purpose of the app is, to eliminate unnecessary features from piling up in menus.

    Final Thoughts

    Developers strive to deliver the experiences that will change the way people work and live, and they are created from simple ideas. When building your first app it’s easy to succumb to including every new, trendy feature. But it’s important not to lose sight of the app’s purpose, as that is what will drive customer delight and keep the user base growing. These are some of the keys to a successful app.

  • DevOps Empathicus – Where is your organization on the evolutionary scale?

    DevOps Empathicus – Where is your organization on the evolutionary scale?

    Ok, I admit it – I sometimes cry when watching sad movies or as real-life events play out in the news. I put myself in the position of other people, sharing their joy and pain. This got me thinking about change-based initiatives like DevOps and what benefits organizations can realize when IT staff have the support to do what should come naturally. That is, considering what it’s like to be on the ‘other side’ – whether the other side means Dev, Ops and Security or as a customer, and then collaborating to drive improvements.

    Below is a “scale” that can be used to assess the empathetic maturity of your organization. Failing to acknowledge (however painful) your organization’s maturity will compromise any hope of success with DevOps – no matter what tools or would be process improvements you put into place.

    1. Hunter Gatherers – at the lowest point on the evolutionary scale, these organizations have a preponderance of what can be considered IT foragers and scavengers. Singularly focused, their survival depends on technical dexterity in the harsh environments they operate. Using specialized tools and with little management oversight, their sustenance is every technical issue and problem. They trust no-one, thriving instead on the ‘hero status’ they’ve acquired over many years of keeping the technical lights on. To them, DevOps is like every other change initiative – a painful and unnecessary distraction they’ll attempt to discredit – by doing what every good hunter gather does — beating it to death.

    To ferret out hunter gatherers, I’d suggest a simple test. Ask everyone how they dealt with the last Severity 1 outage. If they start by blaming other folks (even on their own team), or claiming that recovery was down to them alone, then they probably should be kept away from a DevOps style initiative. If however, the quiet introspective Ops guy fesses up that he calls for help from his pals in security to tackle problems, or that he’s even sharing monitoring tools with Dev to improve code quality, there’s hope that teams can hang up the spears.

    1. Tribes and Clans – moving up the empathetic scale, these organizations are characterized by teams of technology domain-based specialists – like the NOC clan or the service center tribe. True, these groups share each other’s pain, but this is almost always (in their minds) brought about by the habits of competing tribes. Here, every release delay, lengthy compliance check, outage and problem, is caused by another team – like the hipster, tofu loving developers or those hard-nosed security and compliance specialists.

    With IT teams being traditionally organized by technology function, it’s not surprising that tribalism persists. Many organizations attempt to resolve the issue by for example co-locating teams. But without putting some shared skin into the mix that’s going to be as successful as a TV celebrity sharing some deep thoughts on Twitter. Therefore, start by finding some common ground to help unite teams. A shared area might help for sure — but better still are shared outcome-driven business metrics with linked incentives.

    1. Religious Cults – best practices and methodologies like agile development, ITIL, Cobit and Lean are great for bringing similar like-minded tribes together. Unfortunately, pragmatic application often gives way to dogmatic enforcement; with crusade-like implementations promising much, but never delivering much in the way of business value.

    DevOps itself can still fail miserably if organizations succumb to all the hype and hyperbole; readily accepting rants that whatever preceded it has to be bad. More mature IT teams look beyond industry spin – accepting that many existing practices can have a place in supporting the goal of rapidly delivering high quality software. For example, incorporating existing integrated ITIL incident and problem management processes during pre-production to build and circulate knowledge, or even automating compliance procedures during testing to both harden security and prevent delays.

    1. DevOps Empathicus – it’s no surprise that the most successful organizations display high degrees of empathy. They care about their colleagues and customers. They collectively swarm issues, treating problems as the enemy. For these organizations the ‘smartest guy in the room’ syndrome is a thing of the past – with acceptance that people innovating solutions don’t have to be MBA grads or domain experts.

    But while we can hope that organizations naturally evolve to this nirvana state, it just doesn’t happen that way. It takes subtle intervention from management to get people from a state of just caring about the technology to being deeply connected with the business problems they are trying to solve. Sure, that sounds fanciful, but the first time you see a high-five because the business just exceeded its Net Promoter goal or they’re measuring downtime in terms revenue lost not milliseconds, you’ll appreciate the power and value of empathy — Then perhaps like me you can get out the tissues and have a darned good cry.

    So where does your organization fall in this scale?

  • The Pros and Cons of Remote Work in Ops

    The Pros and Cons of Remote Work in Ops

    Remote work in Ops is divisive. The perks of working from home, your local coffee shop or wherever can be quite obvious to engineers and contributors. But some team leaders and company execs aren’t buying into it. One faction sees it as a way to do better quality work. Another has watched deadlines and motivation fall by the wayside because of unresponsive remote workers.

    What are the advantages and disadvantages of remote work? What should you consider before you take the plunge into flexible hours and asynchronous communication?

    Why Do Companies Go Remote?
    Company leaders worry that remote work erodes culture. Workers fret that colleagues and reports don’t get enough done outside the office. And team leaders lose sleep chasing down time-sensitive updates and deliverables.

    Remote work can definitely present some challenges. So, why do companies go remote? Several find it can provide serious benefits when implemented properly.

    By considering remote workers, businesses are able to attract high- quality talent from a larger pool of candidates – that’s especially important in the technology and software world where recruiting top-notch engineers is often a company-level initiative. If your company is based in a geographically competitive market, this opens doors and extends your reach to premier candidates outside of that area. It also goes the other way around – engineers who don’t live in tech-focused cities are given opportunities to be a part of those companies and cultures and aren’t penalized simply for where they live.

    Some contend remote policies produce better work. GitHub argues that code doesn’t follow a 9-to-5 schedule. Remote work can enable engineers to write great code during their peak hours of energy, focus and productivity, rather than on a set schedule that doesn’t play to their strengths. Because all employees – and engineers – are different, remote work provides the option to hone that creativity and focus outside of normal working hours.

    Since we’re so used to operating online, both in our work and personal lives, remote work embraces that to make employees more efficient. Remote workers communicate asynchronously.In other words, they respond to messages and transcripts when it makes logical sense, without interrupting serious tasks or disrupting intense focus. Another plus taking communication online is that it naturally leads itself to fewer meetings, and more doing. You’d be surprised how much you can cover in a three-minute chat via Skype, Slack, Campfire or another communication tool.

    That’s to say nothing of fostering a more enjoyable work environment. Plenty of people believe remote work improves morale. Who doesn’t want to work flexible hours and code when they’re in the zone?

    Finally, remote work supports inclusivity and diverse teams. What are the chances that every single person who can meaningfully contribute to your company just happens to live within a short commute? Not only do distributed teams open up opportunities for skilled workers who live outside of tech hubs, they also make it easier for people to work around family and other obligations.

    For some close-knit teams, there’s no difference between chatting in Google Hangouts and meeting on-site in a conference room. Going remote helps everyone get more done, more efficiently and on their terms.

    How Do You Get Started?
    Remote work may not be for every company. Your business needs or culture might not work best in a distributed environment. But if you do want to give it a try, there are some basic ways to start.

    Using the right tools is key. 37signals, the company behind Basecamp, literally wrote the book on remote work, and most of their team works remotely, using the company’s Campfire chat client to aggregate company communications and keep everyone on the same page. Email works for some conversations, but project management tools like Asana, Trello, Basecamp and JIRA let you add state, metadata, and delicious permalinks to everything that needs to get done.

    Be judicious about which tools you pick, though. Text, video and voice all have pros and cons. You’ll need to use communication channels that make sense for your company’s work style. For instance, when teams that are used to face-to-face stand-ups switch to typed messages, there can be miscommunication and misinterpretation. You’ll get more value out of the tools that enhance your in-office interaction methods. You might have to adopt several tools for your needs: The developer team at Hanno, a user experience company, uses nine different tools to work remotely, including Basecamp, Slack and Google Hangouts.

    While tools are important, they’ll only take you so far. You need to develop strong foundational relationships among teams, colleagues and management before implementing remote work policies. In-person relationships set the tone for remote ones. Try to grab a beer or lunch with your colleagues – it will help form healthy relationships and ensure remote work is truly effective. If your team is completely distributed, try to get together once every quarter or two to reconnect, put faces to Slack handles, and build culture. The plane tickets and hotels may seem a little pricey, but they’ll pay off in productivity and morale.

    And as with many other tests, start small first. Maybe you have a smaller engineering team that’s used to working this way already – let them test drive with a couple days per week so one piece of the company has a chance to hash things out before rolling out more widely. As GitHub points out in this post on how the company works remote, if something doesn’t work, just ditch it in favor of something that does.

    What Should You Consider When You Go Remote?
    Just because everyone’s excited to go remote doesn’t mean you have a bright out-of-office future ahead. Remote work comes with its fair share of challenges and considerations.

    If remote work isn’t ingrained into company culture, problems won’t be far behind. Projects can be delayed because dispersed teams aren’t used to communicating in a timely fashion with out-of-office colleagues. Discontent might simmer if in-office workers view remote teams as slackers. Subcultures can also easily form among remote and non-remote employees.

    Communication presents another daunting obstacle. Teams outside the office might over-communicate, while on-site workers bristle at a deluge of messages. Conversely, remote workers might fail to communicate enough, furthering the perception they’re not getting much done. As mentioned at the USENIX LISA 14 conference remote work panel, refrains of “your team’s never in the office” might become all too common.

    In the end, interpretation matters. For remote policies to work, employees in-office and outside need to understand that they’re both working hard toward a common goal, even if their methods differ. But that doesn’t happen on its own: you need to implement the tools, processes and culture to make it a reality.

    The bottom line is that remote policies work for some organizations and not others. What matters is finding a sustainable organizational culture that leads to business success, whether you do it from behind a desk or at home in your pajamas.

  • 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