devopsy.kinsta.cloud

Tag: doing DevOps

  • How to Cut Design Sprints in Half

    How to Cut Design Sprints in Half

    Any company that has created a product in the digital sphere will no doubt be familiar with the purpose of design sprints. Traditionally both back-end and front-end developers, designers, marketing teams and other stakeholders in the company come together over the course of five days to prototype ideas, gather insights on users and validate them before building solutions with company resources.

    Like most startups we are always extremely busy and getting people to work for five days felt like a lot—even two days was a stretch for some, so we decided to see if we could come up with a way to get the same results in a fraction of the time.

    Traditional design sprints are held over five key days to help:

    • Understand –  Map a challenge and particular focus area.
    • Ideate – Come up with many design solutions.
    • Decide – Turn those design solutions into a storyboard.
    • Prototype – Create a prototype based on those storyboards.
    • Test – See how live users interact with the prototype and learn to iterate further.

    For our design sprint this time, we wanted to test another approach for the first three steps in the process (understanding, ideating and deciding). Instead of taking three days to complete the majority of the design sprint, we wanted to test if we could deliver similar results in four hours. We did, handing off storyboards to our designer for testing and iterating with live users. This cut a normal five-day design sprint in half. This is how we did it.

    The Purpose of Our Design Sprint

    We were creating a top-secret brand new feature we wanted to add to our product that required the design sprint in the first place. At Usersnap, as a customer feedback company, it is probably no surprise that we use our product to collect feedback from people using our products, do extensive research on that feedback and take our findings directly to a design sprint for ideation and prototyping.

    Preparation Is Key for Shortened Design Sprints

    If you want to cut your design sprint in half, make sure you have the following in advance:

    1. Research on our target personas (we conducted 20 interviews and collected 130 survey responses).
    2. A clearly defined and agreed-upon challenge for your design sprint team to tackle.
    3. The deliverables at the end of the session.

    Desired outcome: Make sure everyone is clear and aligned on the challenge to tackle.

    You may wonder: “Why would you prepare these things beforehand when all of this could be discussed during the design sprint?”

    We wanted to give people time to sit with the challenge and have ideas to present during the design sprint, and save the time that was used just getting everyone up to speed.

    Understand (1 hour)

    Instead of a full day to understand the challenge, we used one hour. How is this possible, you ask? Our participants came prepared in advance and our in-house researchers had extensively analyzed the findings from our research stage.

    Presentations (15 minutes)

    First, each expert presented the findings of our target persona and their pain points. There were three researchers who each had five minutes to present the qualitative, quantitative and nuanced aspects of the persona’s pain points. With a short period of time, our researchers were forced to focus on the most important problems of our persona.

    While presenting, the other participants wrote down “How Might We’s” (HMWs) on post-it notes. HMWs frame challenges in question form and these post-it notes are integral to the ideation stage.

    Desired outcome: Understand the persona of the chosen design sprint challenge.

    Expert Interviews (45 minutes)

    Second, researchers were interviewed by the participants to learn more about the persona’s challenges. We set the timer for 15 minutes for each researcher and fired away with our questions.

    Desired outcome: Expand on particular points that participants wanted to know more about.

    While Q&A continued, respondents continued writing HMWs on post-it notes.

    Ideate (1.5 hours) and Decide (1.25 hours)

    Ideation and decision takes two days in total, according to the design sprint manual, and we gave ourselves less than three hours.

    Problems Worth Solving (30 minutes)

    First, we set the timer for three minutes, and all of us came up with our top three HMWs to put on the wall. When time expired, we presented our HMWs and placed them on the wall in order of our persona’s job steps. If a HMW is repeated, we either replaced it because it’s more relevant, or threw it away.

    From there, we all received three stickers, set the timer for three more minutes and proceeded to vote on which three HMWs were most relevant to the persona’s pain points. The voting is not meant to eliminate less relevant HMWs, but to clarify what the group thinks is most important.

    Desired outcome: Focus the group on problems to solve within the persona’s challenges.

    Crazy 8s (1 hour)

    Next, we did two rounds of Crazy 8s. At this point, we were breezing along, and even my own expectations were exceeded: We were getting close to designing something in a fraction of the time it normally takes!

    The steps to Crazy 8s are simple:

    1. Take a large piece of paper, and fold it into eight parts (“tiles”).
    2. Set the timer for eight minutes, and begin.
    3. Provide up to eight screen designs based on any of the HMWs written down (those that made it to the wall and those that didn’t).
      • Less than eight screen designs? No problem.
      • Want to present a flow with multiple tiles? Go for it.
    4. When the eight minutes are up, place each piece of paper on the wall.
    5. Present three of your eight ideas to the group and explain what problem the design should solve.
    6. Repeat the process a second time; combine ideas from others or expand on them.

    Desired outcome: Demonstrate how we could solve a problem related to the persona’s pain points.

    Decide (1.25 hours)

    Storyboards (1 hour, then 15 minutes)

    Next, we broke up the design sprint team into two groups, making sure there weren’t too many participants with substantial design sprint experience in a group.

    We set the timer for one hour, and each group came up with a storyboard flow with five sheets of paper. We didn’t give clear guidance on how to design the storyboard, but it should represent five key steps to reach a goal. If both groups approached the problem in the same way, it provided good insights on the nuances of the problem. If each group approached the problem differently, it provided perspective to the problem itself.

    Desired outcome: Design screens in an order that tackle the challenge of the design sprint for our persona.

    We then presented our storyboards. Each group had five minutes (set your timers!), and time for quick Q&A afterwards.

    Retrospective (15 minutes)

    Finally, it was time to conduct a quick retrospective. Each participant had three minutes to provide their thoughts:

    • What did you like?
    • What didn’t you like?
    • What could we improve?
    • Any additional comments?

    Handover for Prototyping and Testing

    From there, we handed the HMWs, Crazy 8s solutions and storyboards to our designer to develop a prototype, do user testing and iterate on the design. From previous prototypes, we knew that we would hear a lot of the same feedback from the participants. So we decided to change relevant and obvious flows right away and test an already modified version with the next participant. This process allowed us to achieve a more relevant flow in a shorter time.

    In the end, none of this was or would be possible without customer research. It was the foundation of our design sprint, and we used our own product to collect feedback and organize it in a way that gave us sound insights leading up to our design sprint.

    Those four hours yielded great results for the type of challenge we wanted to solve, and we didn’t use three days to get there. It took us longer to get to a tested prototype, but only one or two people were involved and they didn’t dedicate 100% of their time to the prototype iteration. This process fits better to our day-to-day schedule.

    Trimming Design Sprint Time

    We found the process very helpful and will do it again, always re-evaluating where we can improve. For anyone who would try this method:

    1. Be sharp and clear on the goal.
    2. Have well-prepared participants.
    3. Keep your timers handy.
    4. Question the quality of your results.
    5. Let us know if we’re onto something.

    Happy sprinting!

  • Culture, Not Changing Much in DevOps

    Culture, Not Changing Much in DevOps

    One of the things that has bemused me from day one of the DevOps movement is how culture is viewed with an odd dichotomy. It is simultaneously DevOps’ greatest strength and its greatest weakness.

    Of course, there is a simple and reasonable explanation for this phenomenon. DevOps wants to change culture. Cultures that are resistant to change are typified as “bad” and those that are not are typified as “good.” It is never that simple, but that’s how the portrayal goes.

    After a decade, you would think we’d have massive IT culture change supporting DevOps initiatives at one level or another (somewhere on a scale from pilot project to corporate standard) pretty much everywhere.

    But data seems to indicate that this is not the case. Disclaimer here: I fall more on the “automation” side of the “What is DevOps, really?” question. I don’t think that matters here, since I’m pointing at data from the DORA “State of DevOps Research Report,” which is 1,900 of you all speaking, not me.

    Image Credit: DORA State of DevOps Report

    Most of the coverage on this report is by people who have bet their entire career on DevOps—a solid bet, but one that can lead to stilted coverage, which takes all the positives and hoists them high. And there is a lot of positive to be found. But I’ve noticed a trend of not looking at the data with a critical eye. The bit that I’d like to focus on today is what DORA labels “Firmographics”—a breakdown of respondents by title.

    Only 27 percent of those who responded were on a DevOps team. Presumably because Google is a sponsor of DORA, it included Site Reliability Engineering with DevOps teams, and that’s a fair inclusion, since SREs by definition are doing DevOps.

    Consider that data point representing “culture change” in a world where the respondents are, by self-identification, doing DevOps. Some will argue this is the wrong way to look at it, but one of the issues that culture people bring up constantly is breaking down silos and organizing around product or product portfolio instead of development and operations. But it seems more as though organizations are knocking holes in silos and communicating through them—which means we should pay more attention to that style of DevOps and quit harping on organizational change. Again, this fits well with my world view, which has always been “That specialist in a shared bit of hardware is not moving to a DevOps team.” The EMC specialist (for example) adds value to the entire org because of their domain-specific knowledge, not because of their deep understanding of the entire DevOps toolset. Once you’ve carved out exceptions for storage, networking and platform specialists, moving everyone to a DevOps team is pretty moot.

    I won’t conjecture why only 27 percent are moved into dedicated teams, nor why that number did not go up from 2017. I have a predilection toward “because it’s not necessary,” but likely there will be two camps when this discussion gains steam because more reports show a low rate of change—Group A will be, “Because those people are resisting change,” while Group B will be, “Because those people don’t feel they need change.” Guess what? That will be the same group of people, and that angle of discussion will be irrelevant. The important bit will be, “Are you completing everything you need to get done, and what is your structure?” That’s where the meat of the discussion will need to occur. Because by deduction, 73 percent of people participating in the DORA survey are doing DevOps while not being on a dedicated (eg: reorged) team.

    And that’s perfectly okay, as long as they’re achieving the goals, that’s what matters. The how is useful when deciding to move in a certain direction, but delivering is the thing IT should—and generally is these days—be gauged on.

    — Don Macvittie

  • DevOps: Making Developer Experience Reality

    DevOps: Making Developer Experience Reality

    As DevOps professionals, among other things we are responsible for making developers’ lives a little bit easier. How many times have you heard, “Do you have a working vagrant box?” Or maybe you need to set aside a few days to onboard a new developer.

    Many times a development environment is created when a project is started, usually on a developer workstation. This typically means it will work on that laptop. But, as the project evolves and more engineers get involved, the need to share this environment becomes apparent. When the project grows in complexity, requiring more components and third-party services, this organically grown developer environment quickly becomes unmanageable.

    Get Ready for Production

    Another interesting aspect of the developer environment is the level of similarity with the actual production environment. Even evaluating this aspect requires that you have insight in what production looks like. If projects start on a developer laptop, the desired production setup is seldom considered. More times than I care to remember, I was called into a project when the “thing” that worked well on the development teams’ laptop had no sensible production deployment format.

    This teaches us that even if we start out small, we must think about how the project will function in a production environment and how we are going to get it there. In practice this means that any new project requires at least the following:

    • Some unit tests, they may even start out as stubs.
    • A minimal deployment target environment.
    • Continuous integration (CI), running the (stubbed) unit tests.
    • Automated delivery, preferably continuous deployment (CD).
    • At least one simple integration test, possibly just a curl to the deployment app to verify it is alive.

    This does add some complexity to your project startup, possibly beyond an individual developers’ abilities. It does, however, lay the foundation to, at the very least, be able to deploy the application somewhere. For a seasoned DevOps professional, adding a basic CI/CD only takes an hour or so and there are plenty of free cloud resources for small projects.

    When the project grows and the development environment gets more complex, things get a bit more tricky. The above steps will not really help you mitigate the possible frustration of keeping all the moving part inline. A pattern I see often is that developers try to spin up the entire production stack on their laptop. For a containerized environment, this might mean a Docker Compose-based setup or even minikube to run a local kubernetes cluster. These tools often are using shared volumes for quick iteration, which work well until a large number of files need to be kept in sync. Vagrant is a great way to quickly spin up an environment. This does offer some level of production parity, but certain parts are missing: The CI/CD system watching commits to your source code repository is not deploying to your local setup and traffic to and from it are not passing any additional infrastructure such as load balancers or firewalls, to name a few.

    Local-Remote

    When things break in production, “It it works on my laptop!” is a phrase we have all heard at some time or other. What if we could bring the laptop environment a bit closer to production? It’s not the developers’ fault if things break in production but work well on the local workstation. Providing an option for developers to develop iteratively using a remote infrastructure means we can get closer to production parity. Also, it means that onboarding new developers in the team could be simplified significantly because all the complexity is in the remote environment. This remote environment is provisioned in the same automated way as production, so we have a great degree of confidence about its state. For Kubernetes-based environments, many great tools exist including Skaffold and Draft. They both provide an easy way to build, push and deploy applications to a Kubernetes cluster. This makes it easy for the developer to take on the responsibility to ensure the application under development will run in the target environment.

    If, for some vague reason, you are not containerizing you applications but run code in a virtual machine instead, there are also options. Most modern editors provide automatic syncing with a remote server, either on-demand or when code is changed. Ksync is a tool for syncing your local code into a pod in a Kubernetes cluster on file change. Syncing code live removes the delay of rebuilding a container image and uploading it every time you want to see it in the deployment environment. As such, code sync tools are better suited for iterative development.

    Recently, I worked with a client setting up Telepresence  for a development team. This is also a tool for Kubernetes environments but it offers a twist—developers get to run their code locally with all traffic in and out proxied through a remote Kubernetes cluster. Like with sync tools, this means there is no more long delay before viewing changes, IDE debugging works as normal and all the log output is local as well. When code is committed and pushed, the CI/CD system should update the cluster with the latest version, which in turn can be used to iteratively develop on with Telepresence. It’s a relatively young project but offers great potential. An added advantage is that only a small portion of the entire application stack or landscape needs to run on the developers’ laptop, which means it can do with less memory and a cheaper CPU.

    Conclusion

    Containers and microservices are more widespread than ever, making it increasingly difficult for developers to have a production-like environment to develop in. The key to solving this problem is to not try to load everything into an evermore powerful laptop, but splitting the load and complexity between developer workstation and a remote environment.

    — Alex Knol

  • What Comes after DevOps? Two Possibilities

    What Comes after DevOps? Two Possibilities

    People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

    The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

    At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

    Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

    That begs the question: What comes after DevOps? I think there are two distinct possibilities.

    A Reaction Against DevOps

    One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

    Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

    But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

    In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

    DevOps-ifying the Whole Organization

    The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.

    This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

    Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

    To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

    — Chris Tozzi

  • Top 5 Considerations for DevOps Success in 2018

    Top 5 Considerations for DevOps Success in 2018

    Top tips for maximizing DevOps effectiveness

    Whether you are well into your DevOps journey or still thinking about getting started, there’s always room for improvement and an opportunity to learn from each other. Perhaps at the top of your to-do list this year is to implement DevOps as part of your product strategy. You can picture it in your mind: Increased software velocity fueled by frequent releases, better team collaboration and visibility, improved testing procedures and more robust and reliable products.

    But picturing something in your mind and making it a reality are two very different things. Which is why I’m offering what I consider to be the Top 5 Considerations for DevOps Success in 2018. Keeping these five items in mind as you make DevOps part of your organization will help increase your chances of having a successful implementation.

    However, before diving right into the top five, let’s take a minute to define what success looks like in this landscape. DevOps means releasing software every second of every day, right? No! While that may be a reality at companies such as Amazon and Netflix, it’s a common misconception that to be successful in DevOps you have to fire off releases constantly. In reality, what works fantastically for one company (say, Netflix) may not work at all for your organization. DevOps is a personal journey and realizing success is about being flexible and understanding your organizational requirements.

    With all that said, across organizations and industries of all kinds, one constant about DevOps that remains is that it should focus on making continuous improvement through changes, both big and small. In doing so, you will create the ability to improve the flow of work through your value stream to change how you deliver value to your customers. The only way to realize that improvement in value is through change, and if DevOps is designed to do one thing, it’s to make change easier.

    Top 5 Considerations for DevOps Success

    With a loose definition of what success looks like in this context, let’s take a look at the top five considerations for DevOps success to drive your business forward in 2018.

    Make the Work Visible

    The goal of every company in the software development space is to deliver value to your users. It’s often incremental improvements over time, but ultimately, your focus is to deliver a better product and a better user experience. The challenge is that it is not always (or even rarely) straightforward, and that’s because the work is not visible. When work is not visible—which means progress is not visible—not only can the work take longer, but also there may be misalignment within the company. This can lead to more mistakes along the way, as issues don’t get properly addressed in a timely fashion.

    Part of this issue of visibility stems from the fact that many companies don’t use tools or methods to visualize their entire value stream or the value flowing through it. While some companies use physical means to address this problem, there are modern platforms that are able to aggregate data from all the different sources, provide a digital representation of the value stream and help identify any value that is falling through it.

    Using a Common Currency for Value Across the Enterprise

    There are several parts of the software delivery life cycle teams might use to measure value for development—releases, versions, packages, binary artifacts, etc. When an organization is fundamentally measuring teams using different value currencies, it becomes very difficult to accurately understand whether it is successful. What it needs to do is find a common currency that can span the organization and give stakeholders and developers a real apples-to-apples way of comparing and looking at value-add. In DevOps implementations this common currency is work items. Then, when code commits are actually occurring, those code commits can be affiliated to those stories and work items, which is basically the business value. In that way, the business can use a common currency to track and measure progress.

    Measurement

    Over the past couple of years, we’ve seen many companies buying tools and changing processes and spending a lot of money in their DevOps initiatives. While these tools are great and can provide incredible insight into your workflow, it is necessary to dig deeper into the measurement to get a bigger picture of the entire pipeline.

    So, while measurement is important, what will really drive increased value for an organization is to measure the entire flow of value across the full value stream, not only in one phase or in one area. This means measuring from the very beginning—when an idea is created—all the way until end-of-life.

    Along this same line, it is absolutely imperative for a company to establish real baselines for its data. Even if the numbers aren’t pretty, the company must have truthful baselines not only to measure against future performance increases, but also to help identify bottlenecks and other areas of weakness that are opportunities to improve.

    Configuration as Code

    The goal here is to leverage version control in such a way that a company is creating ultimate efficiency in its build cycle. Versioning everything touched in the software development process will allow for speedier deployments. When there is an error, the team can roll back without much effort. Fundamentally, a company must establish the practice such that every code push becomes a snapshot of the configuration of the entire stack.

    Doing this effectively lowers computing code and it becomes trivial to stand up entire environments for the sake of a single user story or a single feature. Having configuration as code will allow a company to perform rollbacks much easier and will enable faster and more frequent deployments.

    Compliance

    Compliance used to take place after the software was done. When it had gone through development and testing, and prior to going into production, it was passed to a compliance team or officer who was responsible for making sure everything checked out. Not only does this slow things down, it creates a single point of failure and puts the organization at greater risk for not realizing ever-increasing and changing compliance requirements.

    In modern practices, teams are embedding the compliance aspect of software development into their value stream and that allows them to avoid rework and waste. Compliance activities should occur in parallel to the development and testing work, rather than when the release is marked done or code complete. Modern DevOps platforms allow builds of all the activities of the software development process into the different phases. The goal here is to have confidence that every software release that comes out of a company’s value stream will be fully compliant and can be deployed into production at any time.

    Conclusion

    Whether you are already knee-deep in DevOps or are just starting to consider it as a strategy to drive your business results forward and improve your software development, keeping these five considerations in mind will help you stay focused, generate better results and realize success in 2018. If your ultimate goal is to improve value for your customers through incremental and on-going change, it’s a great time to be part of the DevOps culture.

    Want more? Check out this webinar for a more in-depth look into what drives DevOps success.

    — Eric Robertson