Category: Doin’ DevOps

  • Starting with DevOps from Day 1

    Starting with DevOps from Day 1

    The Not So Minimal MVP

    In the ever evolving startup space, developers often skip crucial steps in their haste to get to market. Even more so, in the dynamic app development market, the common notion of an MVP (minimally viable product) allows developers to iterate versions of their product based on issues and feedback. Seen in the context of horizontal technologies like Facebook and Twitter, the iteration period is where the real magic happens. Historically, the first versions at the “MVP” stage were bare-bones. That was then, this is now.

    As apps get better, people’s expectations are getting higher. This puts more pressure on startups to have an impactful product from the get-go. Features that used to be new and fascinating are now the expectation, so startups must adapt to have a strong 1.0 as a foundation for iteration. I recently saw an ad for a company calledCircleci whom I know little about, but the tag line was brilliant; “Launches are dead, long live iteration.” Apple and Microsoft may still have ‘launches’. Startups iterate.

    One way Zipline achieved a high-standard first version was by adopting DevOps via Rackspace DevOps Automation Service from our inception. Instead of migrating our app over to a more mature platform after many iterations, we decided to make the investment early. Here are just a few reasons how adopting DevOps from day one can help position a startup on the cone of a rocket ship:

    1. Understanding Scalability

    There’s a line of thinking that goes like this: First comes product, later comes scalability. We strongly disagree. When people hear the word scalable, they think upwardly increasing capacity and size. So it can wait, right? For startups, downward scalability is just as crucial. While most startups view DevOps as an option for the future, we found success by leveraging DevOps from our inception. Instead of waiting to implement a mature infrastructure like DevOps, we looked for partners that could give us access to managed services typically only available for big companies. We found success with large scale systems that were downwardly scaled to match our business need. DevOps gave us an opportunity to work with systems that were ahead of us in terms of technology and culture. Startups who view their product as agile, dynamic and iterative, but DevOps as only a static-run environment are making a huge mistake.

    2.Understanding Culture

    Hiring and retaining top tech talent is difficult –even more so for startups. But we noticed something profound as we grew our development team from one to seven: Talented engineers who interviewed with us expected our infrastructure to be novice. When they realized that our DevOps infrastructure rivaled that of the big company where they previously worked, their minds were put at ease. I’m not saying it always closed the deal, but it signals to a growing team that they are part of a winning culture. Building a winning culture starts from day one.

    3.Understanding the Cost of DIY

    Most developers capable of writing quality code are also capable of creating an environment to run the code. The cost seems so innocent at first. For a bootstrapping startup, common sense says “do it yourself”. Again – wrong.

    Nothing is more costly for a startup than distraction. Every minute should focus on your unique competitive advantage. I’ve never heard anyone say, “I use this technology because of their awesome DevOps.” What makes your company great? Strong DevOps for startups should eliminate distractions, sharpen focus and accelerate code commits.

    4. Understanding Collaboration

    Walk into most mature tech companies and you’ll notice something: The development team and operations team are separated into different spaces. Startups should exploit this vulnerability to gain a competitive advantage. Collaboration in small startups should be instant and in real-time. At Zipline, deploying DevOps from day one promoted a culture of open communication across all people involved in delivering our application. According to the Rackspace DevOps Automation Survey, 41% of organizations have seen better collaboration amongst project teams and 35% have seen more accountability across developers and operations for getting apps to market after deploying DevOps. Running a collaborative system allows us to focus on elevating our product in innovative and creative ways.

    5. Understanding Iteration

    Every system at a startup should iterate constantly. Take something mundane, like bookkeeping. If your system of keeping books isn’t better on Friday than it was when the week began, then you failed. The death of a startup can occur quickly. Iterate or die. So ask these simple questions every Friday, “Is our DevOps better than it was on Monday? If so, how? If not, what can we do to change it next week?”

    About The Author/Kirk Bowman, JD

    Kirk Headshot Bowman is the founder of Zipline Labs, Inc. A life-long entrepreneur, Kirk loves applying the mental rigor he honed as an attorney to creating innovative businesses that shift perspectives and evolve behavior. His endless curiosity and capacity for complexity unearths opportunities in the least likely of places. Now, he’s focusing his thought leadership in the financial sector. As founder of Zipline, Kirk is exploring how people relate to money and how technology can support an evolution to financial systems that are more social, more connected and more human. A master storyteller, Kirk is a compelling voice when evangelizing for his belief that if we can shift the way we feel and behave around money in both our personal lives and our work, we can create a better human experience.

    Connect with Kirk on Twitter: @kirk_bowman Connect with Kirk on LinkedIn: LinkedIn

  • DevOpsDays MSP 2015: Minneapolis is a Tech Hub?

    DevOpsDays MSP 2015: Minneapolis is a Tech Hub?

    I stopped in the Minneapolis Airport to make a connection earlier this year. I never spent much time thinking about Minneapolis given its reputation for snow and ice. I hadn’t ever planned to go there nor had I explicitly made plans to avoid it. That was until the lineup for devopsdays MSP came out.
    I remembered seeing videos from the previous year and being mildly surprised they had such a seasoned lineup. When the speakers were announced I wasn’t expecting to see such a solid group of presenters taking the stage again. I like going to events in cities with a thriving tech industry. It always makes for a good hallway track when a lot of sharp folks are in the area and can easily attend. So what were all these people doing in Minneapolis?
    It ends up a lot of tech heavy companies are in the area. Target, US Bank, Cargill, General Mills, Best Buy, Land O’ Lakes, and 3M are among them. None of these are pure tech companies like I would expect to find around San Francisco, but any company that’s competitive these days is probably leveraging a lot of technology in an effort to better serve their customers and keep things running smoothly behind the scenes. If you know anything about what I’ve been doing with CookieOps it should be no surprise I was thrilled to see technology applied to traditional business models so enthusiastically.
    Target not only sponsored the event but had employees show up in force, fully engaged. 2nd place highlight for this event was discussing devOps, agile, and lean principles with Mary and Tom Poppendieck, authors of Lean Software Development: An Agile Toolkit, along with a group of folks from Target. Mary’s talk, “The New New Software Game” focused on techniques that make it possible for small teams to deploy small changes to large systems very rapidly and very safely. More specifically, this was a talk on how to break monolithic systems into micro services. I really appreciated how her talk highlighted human interaction and how it incorporates with technology.
    Getting to listen to Mary and Tom talk shop with Target was incredible. They mentioned the shelf life of software on more than one occasion, and I may have gotten a little light headed when Mary used a cookie company as an example of a manufacturing process that’s deeply concerned with time to market.
    The top highlight of the event for me had to be Daniel Willis’s ignite talk, “Sports Stats 101: Putting the R in Sports”. As a mathematician and a father I think getting kids into technology early is one of the best things we can do for them. When I saw Daniel was giving a talk on baseball stats in R at the age of 12 I had no choice but to make plans for Minneapolis. Daniel didn’t disappoint either, cracking standard deviation jokes in his bow tie in front of a crowd of about 400 people.
    Colleen Velo’s talk, “Rolling Your Own vs SaaS” covered the tradeoffs between internally coding solutions, using open source software, and running infrastructure in the public cloud. Bloom Health, another Minneapolis business, is in the high risk environment of healthcare. I found Colleen’s perspective and experience on this subject to be extremely relevant given the new security challenges we’re facing in our industry and the trouble that higher risk sectors are having with innovation as a result of it. I wasn’t surprised to hear Bloom is moving to SaltStack giving the risk associated with the industry where they operate.
    I also encourage you to take a look at Josh Zimmerman’s presentation on “Why You Should Care about DevOps in the Public Sector”. Public sector IT employees face a different set of problems with respect to structure, motivation, and funding. DevOps has moved from startups towards the enterprise, but there’s still a lot of good these practices can do to solve problems in the public sector where much of the resistance can be attributed to the need for a cultural change. Josh and I had a chance to talk about the cultural perspective of libraries, and how they’re viewed as places to keep books instead of places to keep information. I try to check out a library when I’m in a new town and see if they have anything interesting in the archives. This trip landed me in the Minneapolis Central Library where I was able to look at an early edition of Walden that included signed letters from Henry David Thoreau. There’s a lot of good stuff at the Hennepin County Central Library including a Dunn Bros Coffee on the first floor, a Teen Tech Center sponsored by Best Buy, art exhibits, and even a sound proof piano room. I stayed in Special Collections the entire time  I was there, but if you’re in Minneapolis it’s definitely worth stopping by.

    thoreau
    I really appreciated Jason Clifford ignite on GameOps, volunteering it as an Open Space, and coaching a group of us through a few rounds of The Resistance at the evening reception, which was sponsored by Target. Games like The Resistance and Werewolf help us learn how to interact and reinforce the low trust commensalism environment I’ve spent a good bit of time promoting this year and will be presenting this October at Lean Agile Scotland. If table top gaming isn’t low trust commensalism I don’t know what is. You literally have to share a table.

    I also introduced the group to The Drawing Game during the open space. You start with a random doodle on a blank page and pass the paper and pen around to each person so they can add something to the picture. We made it around our open space twice before stopping and ended up with the picture below. This game is a life saver for any group stuck waiting to eat, especially if there are kids with you. A spare place mat and a pen borrowed from the staff have warded off more toddler meltdowns for me than I can count. It’s still fun for older kids and adults too, even if you’re just watching the scene unfold.

    drawingGame

    So how did all this awesomeness end up in Minneapolis? As far as devopsdays MSP is concerned I’d give a lot of the credit to Bridget Kromhout. It’s obvious she puts a lot of time into the devOps community at large and hasn’t forgotten to help build a strong community in her own backyard. The food, shirts, event communications, AV, and even the slides and videos on the website for the event can all be traced back to her and the rest of the amazing staff. Bridget promised an awesome event while in New York but I was skeptical she might be partial when she started talking about the wonderful warm weather in Minneapolis. I can confirm first hand it doesn’t snow year round in Minneapolis, and devopsdays MSP happens during the perfect time of year for a visit.
    We’re only two weeks out from devopsdays Pittsburgh, and I’m looking forward to attending the event, visiting this town for the first time, and meeting some new faces while visiting with some more familiar ones. My expectations are pretty high thanks to Minneapolis, Bridget, and the entire MSP crew. Is Pittsburgh a tech hub too?

  • Benefits for the Product Team in Working Support Cases

    Benefits for the Product Team in Working Support Cases

    An increasingly popular practice that’s being adopted by DevOps groups are developers working regular shifts in front line support. The thinking behind this exercise is pretty sound. When exposed to the real world problems and frustrations customers face when using their software, a developer’s work becomes more about supporting that customer experience and increasing customer satisfaction and less about “Get the tests passing and ship it fast!” The practice also increases an individual developer’s understanding of the larger solution their company provides. If a particular developer is master over a small part of the total application, working support will give them valuable insight into the bigger picture of the problems they’re solving and how well their corner of the world is supporting the larger solution.

    We practice this at my company, Datical, but on a wider scale. In addition to the app dev engineers every member of the product team, myself included, regularly works support cases in direct contact with the customer. It has been a pretty eye opening experience for all of us and we are most certainly realizing the promised benefits of this practice.

    Our product team operates with a single guiding principle: Well defined, customer driven requirements yield excellent solutions. When you schedule calls or take customers to lunch, you get a lot of great feedback on where your product should go and net new features you should consider implementing to improve the overall solution. The conversations we’ve had with customers in this way are generally very positive and supportive with a focus on future direction and growth.

    Working a support case is an entirely different and much more crucial customer conversation. The conversation that takes place during a support interaction is centered on a pressing need. The customer may need clarification on usage that isn’t as intuitive or well documented as it should be. They may be dealing with a gap in previous requirements or a coding defect that is keeping them from completing a goal. Whatever prompted the call, it’s occurring because the customer is not delighted and we are getting a firsthand, real time account of what is problematic and what we must do better. These needs translate directly into our product plans and requirements.

    But there’s more to glean from these interactions than the matter at hand. When the customer is amenable we like to use GoToMeeting to remotely look over their shoulders as they demonstrate for us the issue they are having. During their demonstration, we get additional insight into the mechanics of our solutions. How do customers interface with our products? Are there minor inefficiencies our users have to contend with that they aren’t reporting? A few of the most well received features we have delivered since adopting this practice have been very small stories that were pretty easily addressed, which removed a minor annoyance that was encountered frequently in our workflows. We’ll release these fixes with a minimum of fanfare, but they are almost always noticed, commented upon and appreciated by the customer.

    The last class of lessons learned from our foray into front line support pertains to my new favorite non-word, troubleshootability. When something goes wrong, how easy is it to diagnose the problem and how long does it take? How detailed and centralized is your logging? Are users being updated on the progress of long running operations? If an error is encountered due to customer misuse, is the customer appropriately guided to correct the error? Anything that we can do to shorten the cycle and cut through the murk when something does go wrong improves the overall experience with the product and increases customer trust.

    Working support in product management and engineering has been a really great exercise. It’s given us a deeper understanding of our solutions, our users, our strengths and our weaknesses. This understanding has led to requirements that are tightly focused on our customers’ needs, holistic development practices concentrated around comprehensive customer workflows, and a solution that clearly communicates what’s going on as it happens for fast diagnosis and remediation of issues in the field. I highly recommend it.

    About the Author/Peter Pickerill

    High-Res-Peter-Pickerill-6571-150x150Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. His ability to understand product demands from a customer’s perspective and translate those demands into actionable product and development plans has led to expanded duties at every company for which he’s worked. In his time at Symantec, Pete worked directly with large financial services companies and online retailers to implement and improve online fraud prevention solutions that were used daily by millions of people worldwide. In addition to managing a development team and product schedule at BMC, Pete worked directly with large financial services institutions to provide the features they needed to achieve greater efficiency and cost savings in their application deployment processes.

    Connect with Peter on twitter: @PetePickerill

  • Tailoring DevOps to your IT: A case study for SAP

    Tailoring DevOps to your IT: A case study for SAP

    I am frequently asked if DevOps principles can be applied to legacy environments such as SAP. They clearly can, with some tailoring. But you should be aware of certain constraints.

    An agile transformation from conventional IT (where the SAP software delivery process is split between business analysts, development, the QA department and IT operations) towards an agile DevOps organization requires the following steps:

    1. Organize development teams by business capabilities rather than technology – when defining the structure, ensure teams can work as autonomous and independent as possible.
    2. Upskill business analysts to product owners.
    3. Organize development output by agile principles using SCRUM or KANBAN.
    4. Successively move QA into development teams – a separate QA team can take responsibility for automation of regression, security and performance tests, but should not be involved into day-to-day testing activities.
    5. Successively augment development teams with job scheduling know-how.
    6. Introduce automation tools to ease the promotion (transport) process for changes into upper environments and, ultimately, production.
    7. Add unit test and static code analysis (e.g. for security and performance checks).
    8. Automate regression, security and performance tests.
    9. Focus responsibilities of the SAP platform team on managing the platform (monitoring, patching, upgrading, environment provisioning and refresh, performance testing) and leave the transport of changes (“deployments”) to development teams.
    10. Use automation tools for environment clone and refresh.
    11. Move the SAP platform team towards KANBAN.

    While these steps are similar to agile DevOps transformations in other technology contexts, the specific automation tool chain is very different.

    Instead of using Git, Jenkins, Ansible or Chef, you are dealing with tools from SAP and third-party vendors for code inspection and analysis, transport management, test automation, environment refresh, performance testing and more. This requires skills that can be hard to find. In addition, different tools may be used to cover different SAP platforms (the “ABAP-Stack” and the “Java-Stack”).

    There is another peculiarity for SAP: Although new technology supports fast cloning of isolated SAP environments and their continuous refresh with current data, this is constrained to certain infrastructure. The costs and lead times to provision and manage a single SAP environment remain relatively high.

    Therefore, several teams will often have to share a single SAP environment for development, testing or release purposes. This requires coordination and sets limits to continuous delivery. In the best case, daily production deployments can be achieved by opening the pre-production environment for transport and application tests over a couple of hours, then locking it for another couple of hours for regression, performance and security testing (including batch) and production delivery.

    In summary, many principles of DevOps can be applied to SAP application delivery, if peculiarities are taken into account.

    While continuous deployment for SAP environments remains an ambition, daily releases can be achieved today.

    DevOps Dozen Awards! Automic is currently nominated for a DevOps Dozen Award in the Release Management and Continuous Delivery categories. Vote for us today!

  • Essential Ingredients for Continuous Deployment

    Essential Ingredients for Continuous Deployment

    To build the system to automate the build and deployment (continuous deployment) process there are few main areas which need to be covered. Following are our prerequisites.

    – Source code
    – Builds System
    – Deployments
    – QA Automation

    To describe above here are the main ingredients
    – Configuration Management
    – continuous integration/ Automated Build
    – Automated Deployment
    –  Automated testing

    Configuration management
    Very fist step to align your development practice is to select the right source control tool. Once you have the tool then you need to think of branching policy to make sure the starting point of the workflow is well defined and accepted by developers during their development phase.
    There could be lot of process around merging, branching code review etc which needs to be address and policy driven. Some key points could be
    – Developments and release branch should be separate.
    – Each change goes qualifies for next stage only if reviewed.
    – Code quality should not go down.

    Following are a few options
     Source control tool
    – SVN (Free)
    – CVS (Free)
    – Git (Free)
    -Perforce (Paid)
    -Clearcase (Paid)

    Build system
    Team needs to have robust and automated build system which can take care of all our needs (build, analysis, deployment etc).
    – Need to have automated build system which can keep building the source code from various branches to make sure we catch the broken piece fast.
    – Build can run the unit test and provide report
    – Build can check the health of the code by running findbugs and checkstyle (if any).

    Above checks can verify the heath and quality of the code (static analysis).
    Nothing should go beyond this point if any of the above is not matching with our criteria.

    Till this point we have reached to qualify the minimum criteria for continuous Integration.
    Here are few tools which comes under Build system
    Build Tools
    – Ant
    – Maven
    – Gradle
    – Make
    CI tool
    – Jenkins
    – Cruise control
    – Luntbuild
    -Bamboo
    Repository management
    – Nexus
    – Artifactory
    (Above are not open source but they are free to use with limited features).
    Code quality check
    – Findbugs
    – jacoco
    – cobertura

    **Deployments **

    Deployments are the next big bottleneck for continuous deployment.
    We need to have a deployment tool to move ahead,
    – configuration management tool like puppet or chef
    – Private cloud management (Openstack)
    – Third party tool like xl deploy, Udeploy, Opsworks etc..

    Deployment strategy can be chosen on the basis of our need and the tool we are using, most of the plugins are available in jenkins (or bamboo) to make tight integration of build and deployment.

    (At this stage I am not considering the dynamic provisioning of hardware in this section).

    Automated testing

    Once deployment phase is over QA regression suite can be triggered via jenkins (or any other tool) and entire reports can be published to central QA metrics board.
    This this point we can even use jacoco/cobertura to provide functional code coverage(for Java code) to demonstrate how much % of code QA regression/automation is covering and what is the level of automation.
    Similar way job can be setup to raise jira/bug ticket to file issues found during any of the above step.

    Finally we can have last step which can perform the final release build and push to staging /production in similar fashion.

     Resource Provisioning

    Developers/QA can just get the hardware either from infra team or if auto provisioning is enabled they can setup the environment and use the jenkins to perform build+deployment+QA
    If we talk about automatic scaling of environment, we can use AWS for same.
    Jenkins has AWS plugin to launch instance, This can be setup to launch instance dynamically and run the application and perform the QA Automation. Once need is over aws instance can be terminated automatically.

    Reference-1

    Reference-2

  • The Three “S’s” To A Successful App, Pt. 1

    The Three “S’s” To A Successful App, Pt. 1

    Developing your first app can be a daunting task. Many first-time developers may overlook, or over think, certain aspects of building their first app. Through scores of conversations and interactions with developers, I established common pain points and gathered advice that they themselves wish they had known before building their first app. With all of the collective feedback, I was able to identify the three “S’s” to building a successful app:

    • Scalability – knowing how to grow the app as user engagement increases
    • Simplicity – understanding which features are most critical to users
    • Streetsmart – analyzing the marketplace and differentiating the app

    This series of articles will discuss each “S” in detail, share developer stories and offer practical advice for first-time app developers.

    In conversations with developers about building their first app, several of them mentioned how the app turned out to be much more successful than they had originally anticipated, which in turn, lead to support issues due to the influx of traffic. These stories are what lead to the first “S”: scalability.

    What does it mean to scale an app?

    Scaling an app means architecting the app to accommodate the size of the audience that your organization predicts. While the future success of an app and brand it’s associated with is ultimately unknown, projected audience size is a key factor used to help guide developers to make the best decisions with regards to scalability. When projecting audience size, it’s important to make a bold prediction that’s an order of magnitude greater than the best case scenario. Why? Because it’s better to be over prepared than under. However, resources should not be exhausted and the app should not be over engineered.

    Finding the sweet spot

    Finding the sweet spot between scaling for a current audience size and a magnitude greater than the best case scenario can be tricky. The greatest factor in deciding this is the size and stage of the company. In the case of Uber for example, the app will need to be extremely robust right off the bat because the app is central to the operation of the organization. But with an organization such as Yo, the app does one thing and has a clearly defined scope, so the focus should be placed on getting the product out in the market and and scaling from there. Once an organization has found its market fit, scale should be at the forefront of the agenda. Because if scale is not top of mind, that’s when challenges will occur.

    Overcoming Challenges

    Developers are often faced with hurdles when their distributed systems do not allow for components to communicate together. Applications can’t achieve scalability if the different system components do not work seamlessly as the load increases.

    For example, if there is one server with one database that handles all of the read/write connections, it is rather easy to maintain; there is only one pipe to be concerned with. But when that database crashes due to traffic increase and lack of scalability, the app will stop functioning. So to add scalability to support the increased user-base, the database server needs to be replicated with load balancers that understand when the database server is overloaded and can transfer traffic over to a new one and so forth.

    To achieve this, it takes a combination of network expertise, smart app architecture and building smart connection points between the different services.

    Final Thoughts

    Scalability is just one factor that contributes to the success of an app. When developing your first app, whether it be for robust use or for a clearly defined scope, it is paramount to keep your database servers and the connections between them in mind because those smart connections are the key to building a successful platform for future users.

  • #HugOps in Practice: Empathy Skills for DevOps

    #HugOps in Practice: Empathy Skills for DevOps

    Get it together! Why is your service always down?!”

    We think we’re doing the whole DevOps thing right — new hires can deploy on day one, Travis CI is humming along, and we own the code we ship. But then something breaks, something doesn’t go according to plan, tempers flare up, and all that warm, fuzzy collaboration seems to evaporate. What’s going on? What happened to #HugOps?

    A large part of software engineering doesn’t involve code at all— it’s talking and collaborating with our teammates. Soft skills are harder to measure and quantify than performance or reliability, but they’re just as important— and while we’ll readily spend hundreds to thousands of dollars on books, courses, and training to improve our software skills, companies rarely invest in creating the culture of empathy and compassion that was behind DevOps in the first place.

    Empathy works great…until it doesn’t. It’s easy to be compassionate and collaborative when stuff is going great and everyone’s having an easy time, but it’s stressful, high-stakes situations that show you whether you’ve actually built a culture of empathy. Empathy skills for DevOps cannot be stressed enough.

    Let’s look at some specific strategies and tactics teams can use to improve organizational empathy.

    Learn to Communicate

    Conflict mediators, couples therapists, hostage negotiators, policemen, and others in high-conflict situations often use specialized communications frameworks to help de-escalate situations and get parties in conflict talking to each other in a productive way.

    I’m a fan of a communications framework called Nonviolent Communication, popular in education (I used to be a schoolteacher), parenting, mediation, as well as peace programs in war zones. Another popular guideline is Crucial Conversations, a more business-focused structure for handling conversations where emotions are charged and stakes are high. There are plenty of books, trainings, and other resources about empathetic communication out there, but they all have some common themes:

    • When dealing with a tough situation, separate — explicitly— what happened from how you feel about it. So for the example above, you might say something like “When your service went down for the third time in the past two weeks, I got worried, because our service depends on yours, and we’re trying to hit four nines of uptime this quarter.” Often just the simple step of decomposing reactions from what’s being reacted to defuses the majority of the speaker’s anger— this is used in blameless postmortems to move from “blame and shame” to an honest look at the facts of the situation.
    • When somebody shares a feeling, especially if emotions are high, take time to make sure they feel heard and validated…before you reply. That doesn’t mean you agree with them, just that you ensure that they know that you listened and are trying to understand. In our conflict above, this might be something like “It sounds like you’re really frustrated that our service went down, because it prevented your team from hitting your uptime goal.” Most of the time, the other person will instantly soften, relieved to feel heard. Sometimes you’ll get a “Well, duh!”, but that’s far preferable to the other person leaving the conversation feeling unheard and unacknowledged.
    • If you have a request of the other person, make it positive, concrete, and explicit. And “Could you not?” doesn’t count. Without a concrete request, it’s hard for the other party to know how to meet your needs or improve the situation, and hard to tell whether that effort has been made. For our situation above, this could be something like “Can you please do a postmortem on the outage, and let me know by the end of next week what you’re going to do to prevent a future outage and anything you need from me to help?”

    Again, there are all sorts of frameworks available, and like many tooling choices, it matters less the specific one you use than getting the organization on board with improving everybody’s communication and conflict resolution.

    Align on Common Values

    Cross-departmental collaboration gets much easier if you’re both trying to do the same thing. That doesn’t mean your day-to-day work has to be the same, but the more of your company that is driving toward the same goals, the easier it is to turn conflict into simple questions about sequencing or prioritization, rather than fundamental directional issues.

    LinkedIn, Google, Twitter, and other big tech companies favor the “Objective + Key Result” (OKR) system for this purpose, where a big, ambitious goal and set of results at the company level trickles down into corresponding goals and results for the department and the individual.

    We use OKRs here at PagerDuty, but there are plenty of other goal-setting systems that work. The important thing is agreeing on the meta-important stuff in plain language, so that when someone asks you to change your priorities or randomize what you’re working on, you can have a conversation about which of the options best supports the common goal, rather than the much hairier discussion about what the end-goal even is.

    Mind Your Medium

    Particularly with distributed teams, text-based communication can make tone hard to get across. A request said with a warm smile sounds quite different from one in flat text over email (or to everybody in the company HipChat room).

    Where possible, I prefer video chat to text chat— in fact, some of our teams use perpetual Hangouts so that they can all see each others’ pretty faces, and feel like they’re in the same room together. Where that’s not feasible, I like to over communicate: if the tone of a sentence might be ambiguous, I explicitly state what I mean and what I don’t mean. And while it’s a little weird to me that this has become business normal, emoticons also go a long way in communicating feels over the wire.

    Build Relationships, Inclusively

    Ultimately, all the communications frameworks and shared goals in the world won’t take you to #hugopsland if you don’t have a human relationship with the person you’re trying to work with. An HBR study found that while people generally claim to prefer competence over likability, in practice they behave oppositely — likability is much more important for collaboration than competence.

    And while a few people might be naturally gifted with irresistible charisma, for most likability isn’t a static, unchanging thing: it’s a quality built on familiarity and connection. If two people are going to be collaborating on something, get them some face time — not just screen face time— with each other. We have an engineering office in Toronto, and try to make sure new employees quickly get a chance to spend time with the team in the other office as well as their own. At DevOpsDays Minneapolis this year, Katherine Daniels shared the concept of “bootcamping,” where each new Etsy hire spends a period of time embedded in a different team, learning about how they work, what their goals and challenges are, and making meaningful contributions to their codebase.

    Plan off-sites, social events, time to chill out and get away from the laptops. But keep in mind that not everybody on your team necessarily drinks alcohol, and some of them might (gasp!) have families. That doesn’t mean that you can’t ever plan a team gathering at a bar or do nighttime activities, just try to be aware of the different constraints, preferences, and physical abilities your team members may have. Providing hangout spaces at work is a simple but often overlooked way to help build relationships while respecting those who may have out-of-work obligations or just really long commutes. And while a shared lunchroom can be a good way to cross-pollinate, it’s also sometimes nice to get out of the building— PagerDuty pairs all new employees up with a “buddy,” and sponsors lunch out in the neighborhood to help them get better acquainted.

    Being inclusive of different learning and personality types is important as well. Even if you don’t buy into specific personality tests such as Meyers-Briggs, introverts and extroverts handle relationships and communications differently, and it’s important not to assume that everybody handles information or makes decisions the same way you do. When doing a sprint retrospective, consider starting with a silent brainstorm, to make sure that people’s willingness to talk in a group doesn’t determine their ability to have their opinions heard.

    Finally, and this shouldn’t have to be said, but be respectful of differences in religion, diet, sexual orientation, gender identity, family structure, and anything else that’s not directly connected with their performance as your team member. When somebody expresses their preferred pronouns, a dietary preference, or a constraint on their time, recognize that can be a pretty vulnerable thing, especially if they feel like they’re being asked to justify it.

    Measure and Improve

    While empathy might be tougher to measure than uptime, error rates, or other performance metrics, there are still steps you can take to track how you’re doing.

    Our scrum teams each do “health checks” using Google Forms at the end of each sprint, where we smiley-face-rate our feelings about various factors including teamwork and support. Consistent sad-faces tell us there’s something systemic we need to work on. Managers can also specifically ask in 1:1s about how communication is going within and outside the team, to identify patterns.

    One additional measure (and benefit) of strong empathy is the amount of diversity you see in your organization. If you can’t connect and communicate with people from different backgrounds, you’re unlikely to be able to recruit or retain diverse talent. On the other hand, when you’re able to see through the beer test, or the hijab, and make potential team members feel included and valued, your pool of awesome candidates gets much bigger.

    One final reading recommendation here: Stalling for time: My life as a FBI hostage negotiator. Not only is Noesner’s story a thrilling read, but it takes many of the communication principles above and shows how a master of nonviolent communication permanently changed the FBI’s attitude about the place of empathy in rescuing hostages and defusing violent, high-stakes situations.

  • Five mistakes enterprises make while implementing automation

    Five mistakes enterprises make while implementing automation

    Automation, if done right, can add a ton of value to an IT organization.  Benefits include speed, quality, and improved productivity.  But only a few IT organizations have been able to truly reap the benefits of it.  Why is that?  What is it that these successful companies do differently while others continue to struggle?

    Here are 5 of the most common mistakes we see when organizations try to implement automation.

    1. Automating Infrequent Activities

    Automation works best when a manual task is well defined, predictable, and highly repetitive.  The first two dimensions are key in determining if an activity can be automated.  The third helps determine if it is worth automating.  Yet when organizations decide to automate, they focus on the first two and rarely consider the third.

    For example, automating code builds is a popular activity to automate.  It clearly meets the first two dimensions.  But if the project plan only calls for monthly builds…what is the point?  At best all you have done is saved the developers a few hours of work.  However, if the same automation is used for projects that require daily / weekly code builds.  Now you are literally eliminating hours of work.  Translate that to annual effort saved and you end up moving the needle.

    2. Automating In Silos

    Hand offs are the silent killers of efficiency.  However, most IT organizations are arranged as a series of hand offs (silos) – from requirement to development to testing to operations.  And like most silos, the focus is inward, resulting in optimized silos but sub optimized end to end process.  No wonder it takes weeks to get a new code through all the way to production with, in many cases, sub-par quality.

    The true value of automation kicks in when you stich various activities into a single process, that minimizes / eliminates hand offs, and orchestrates it across silos.  In essence, you are not just automating the activities but also automating the hand offs.  This in essence, is the heart of the entire DevOps movement.  To break down the silos, re-engineer, and automate the process.

    3. Forgetting To Reengineer the Process

    If you look at the data, most processes follow the classic 80/20 rule.  20% of the process time is spent on performing actual “work”, 80% of the time is wasted on motion.  Case in point…it used to take us days (sometime weeks) to open up a simple IP port.  The actual time to perform the work takes only about 5 – 10 mins, however getting the work to the SME literally took days (creating tickets, routing, approvals, finding SMEs etc.).

    Despite this fact, many organizations spend countless hours finding, agonizing, and optimizing the “perfect” tool (hint: there is’nt one) and spend little to no time on process.  In essence, if all you to is focus on the tool, then all you have done is optimize the 20%.  No wonder organizations scratch their heads when they put in automation and don’t get the expected results.  Automation and process reengineering are like two sides of a coin.  If you are truly looking to transform, you cannot have one without another.

    4. Not Planning For The Long Tail Of Automation

    Pssst…let me tell you a secret.  Creating automation scripts is easy…. after all it is the sexy part of automation.  The real heavy lifting begins once you have created it and now you have to constantly tweak and maintain it.

    Applications and its components, for better or for worse, are constantly changing.  Which means that the scripts have to be constantly tweaked.  Yet few consider the after math.  In fact, our clients have so many scripts that they simply don’t know what to do with it.  A better solution is to plan for the long tail ahead of time, set up a governance model that is responsible for updating, maintaining, and pruning the scripts and in turn protecting the investment that they have already made.

    5. Fear That Automation Will Take Their Work Away

    Fact – many of our clients are leery about automation.  Not because they feel it will not work, but are afraid that it will work too well.  And that success will eventually lead to good people losing their jobs.

    There are three key issues with this line of thinking.  First, the assumption is simply incorrect.  While automation will eliminate certain types of tasks it also creates new type of work.  After all you need someone to manage the automation.  Second, the genie is already out of the bottle.  Automation is here to stay.  Ignoring it will only make catching up to it harder.  And third, not implementing automation may have the exact opposite effect and speed up unemployment.  Look at Netflix (poster child for automation) vs. BlockBuster.  A better strategy is to start small now, while the industry is still trying to figure it out, and try to get ahead of the curve.


    Mustafa KapadiaMustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery.  He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

    His expertise is in DevOps, cloud, lean, application development, outsourcing, offshoring etc. and has published several articles on DevOps.  He lives in San Francisco Bay Area, is an avid blogger (when time permits), a speaker, and advisor to start ups.

    You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

  • The Cost to DevOps: 27 Mufflers

    The Cost to DevOps: 27 Mufflers

    Imagine

    Imagine that you are designing the 2016 Range Rover line of sport utility vehicles.  Like all gas powered vehicles, each one needs an exhaust muffler.  Range Rover likely has narrowed in on a preferred provider of mufflers. But imagine what would happen if the designers and factory line workers could pick from any one of 27 past versions of that muffler from their preferred provider for the new model year.  Yup, choose any one — even if it is outdated, lower performance, does not meet current emission standards, or  has a known defect.  Order it, place it on the vehicle, then ship it.

    We all realize this scenario would never happen.  No one would select a known defective part for the product they are manufacturing.  And who would knowingly choose the 10 year old version of a muffler without the latest advancements to support air quality? No organization would give a each of their designers and line workers free reign on procuring any one of 27 different mufflers for a single model year.  Imagine the operational cost of testing the different mufflers.  Imagine the maintenance cost of having different versions of the same part shipping.  Worse yet, imagine the liability of shipping parts with known defects.

    Land Rover is not taking this approach, but software development teams are.

    27 Versions

    My latest research report, the 2015 State of the Software Supply Chain, reveals that large software development organizations sourced an average of 27 different versions of open source components that they used in development last year.  To be more specific, out of the top 100 open source components these companies downloaded from the internet in 2014, they averaged 27 versions of each component.

     

    While auto manufacturers like Land Rover have preferred suppliers of vetted parts, the procurement of open source components is often more of a free-for-all.  If an organization has 300 developers, they effectively have a procurement department of 300 for sourcing externally developed software components. If you have 4,000 developers, you have 4,000 performing procurement.  Even as we all know only the latest version of a components is the most feature rich and of the highest quality and integrity.

    Not all organizations allow free-for-all sourcing practices for components.  Fifty-seven percent (57%) have open source policies in place as a method to guide developers toward higher quality parts with the fewest known defects or security vulnerabilities.  Organizations like Google mandate the use of no more than two versions of a given open source component across their development teams.

    Good Cost, Bad Cost

    What does this mean for a software development organization — especially one focused on improving it’s DevOps practices?  First the good news: developers are using open source components to speed time to release and improve innovation.  Both good things.

    The bad news: Organizations are building mountains of technical debt through poor software supply chain practices by sourcing an average of 27 versions of the same component, impacting quality, complexity, maintainability, supportability, etc.  They are doing this across the top 100 components being downloaded in a single year which equates to managing over 2700 different versions (when an optimized practice would only require the 100 best).

    Organizations are sourcing component “parts” for use in their applications that have up to 26 known better versions available (more features, fewer bugs, improved performance, etc.).

    Organizations are downloading and using parts that are sometimes 9 years old, or even older (simple math: open source projects release 3 – 4 new versions of their components each year).  They are electively using outdated parts.

    Organizations are also downloading some versions with known, documented security vulnerabilities.  They are electively using known vulnerable parts.

    Net Innovation Through Improved Sourcing

    While we often hear people tout a DevOps mantra of “even faster”, there is a consequence to pursuing speed at any cost: technical and security debt.

     

    Open source components are enablers of speed.  But free-for-all sourcing and use practices, add to technical and security debt that reduces “net innovation” and adds to the cost of operations.    As technical debt grows, net innovation and business value drops.

     

    Image source: http://joapen.com/blog/2014/06/17/how-to-monetize-application-technical-debt/

     

    If reducing the use 2,700 versions of 100 components was not motivating enough, consider this: the research also revealed that large development teams were consuming software components from over 7,600 external open source projects (suppliers).  Including all versions of those components, they average organization consumed nearly 19,000 unique components in 2014.

    Improved sourcing practices are just part of the overall story for improving net innovation and increasing business value.  Improved sourcing practices can also enable more efficient operations, reduce mean times to remediation, and eliminate unplanned work for many DevOps practices.  Improved sourcing practices have been employed across many industries resulting in sustained competitive advantages.  Improved sourcing practices are part of a broader software supply chain management strategy.

    Continuous Learning

    There are so many lessons we can learn from other industries who have automated and optimized their supply chains — like Land Rover and other auto manufacturers.   I’ll be sharing more of those lessons and perspectives from the 2015 State of the Software Supply Chain here this summer as well as expanding the discussion around “net innovation”.  Stay tuned.

  • Lean for DevOps: Mapping the tributaries and deltas of demand

    Lean for DevOps: Mapping the tributaries and deltas of demand

    Here at IBM’s Lean practice we use a diagram called ‘Mississippi’ to analyze demand. It is not so-called because it originates in Mississippi – in fact I’ve been given to understand that this tool was developed, and named, in our UK practice*. Instead, it’s called the Mississippi because, like that great river, demand comes from many different sources (or tributaries) and can leave a process through a number of different points (the delta). And, apparently, at times the Mississippi delta reflects tidal patterns and flows upstream. In the same way, demand can route back into, or upstream within, a process – for example, in the shape of rework.

    We want to analyze the volume and frequency of demand for a number of reasons. Understanding demand helps us to:

    • Identify ‘runners’ (everyday requests), ‘repeaters’ (less frequent, but not unusual requests) and ‘rarities’ (infrequent requests). This might be in terms of user groups, applications, or type of request (for example – small changes vs major project). When we design our improved future state, we will design it for runners and repeaters. Sometimes the impact of exceptions can be so painful, team’s lose sight of how infrequent they are, and design a process to prevent or manage those rarities – which will be inefficient for all those runners and repeaters.
    • Identify failure demand – Where are additional requests re-entering the process, as rework? Where is there process activity which doesn’t ‘go anywhere’?
    • Illustrate channels in and out of the process, so we can identify potential control points, or illuminate a lack of filter, and see where demand might be routed in via unexpected channels.
    • Tell us what we don’t know: which elements of demand are we unaware of? We need to understand all demand so that we can build and resource (load level) a process which can meet that demand. Sometimes finding out what we don’t know is a lesson in itself.

    These benefits are as relevant to Lean for DevOps as in any other area.

    It’s hard to say what you’ll learn from conducting this analysis, until you’ve done it, as every Mississippi is different. But to demonstrate some of the valuable lessons I’ve learned from drawing up Mississippis, here are some real life examples:

     

    Lightbulb moment: 'Churn is a fact of life - we need a better way to handle it'
    Lightbulb moment: ‘Churn is a fact of life – we need a better way to handle it’
    Lightbulb moment: 'We need to start saying no to enhancement requests'
    Lightbulb moment: ‘We need to start saying no to enhancement requests’
    Lightbulb moment: 'We have way too many changes taking the emergency route: a faster 'normal' route will reduce that demand and the associated risk.'
    Lightbulb moment: ‘We have way too many changes taking the emergency route: a faster ‘normal’ route will reduce that demand and the associated risk.’

    In their different ways, each of these helped make the case for a shortening of the SDLC, closer coupling of development to business demand, and a more nimble deployment process.

    *If you’ve seen this in use outside of an IBM engagement, I’d love to hear about it! Find me on Twitter to set the record straight.