Tag: Agile Manifesto

  • Are Your Development Processes Truly Agile?

    Are Your Development Processes Truly Agile?

    Many organizations are making a move to agile-powered environments, but agile development is more than a name. How do you determine if your organization is truly agile? The evaluation starts with the Agile Manifesto. If you’re following the principles laid out in the manifesto, that’s a good sign that you’re on an agile journey.

    For those not familiar with the manifesto, however, let’s review its points quickly. The Agile Manifesto’s core is simple—the primary points of the manifesto include the following:

    Individuals and interactions take precedence over processes and tools. This means the organization and its leaders place more value on people than they do on processes. People respond to business needs and they drive the development process within the organization.

    Working software takes precedence over comprehensive documentation. This is not about not providing any documentation at all, but you should streamline documentation. Any documentation that does exist should be necessary only for current and future development.

    Customer collaboration over contract negotiation. Engaging customers throughout the development process makes it easier for your people to meet the needs of your customers. Doing so means all business case features are clear and useful to customers.

    Responding to change over following a plan. This means change is welcome throughout the project, each project and allows for priorities to shift over time versus following a rigid or scripted development plan. 

    The Agile Manifesto 12 Steps

    Essentially, the core values of the Agile Manifesto can be fully detailed in 12 steps, or principles. These principles support the key points of the manifesto and provide additional detail as to how the practices can be followed in an agile environment. Again, for those who currently follow the Agile Manifesto, the following may be redundant. For those new to the concept, these steps provide clarification and direction to drive agile processes overall.

    • Self-organizing teams encourage great architectures, requirements and designs.
    • Regular reflections on how to become more effective.
    • Frequent delivery of working software.
    • Simplicity.
    • Support and trust for those involved in the process.
    • Enable face-to-face interactions.
    • Working software is the primary measure of progress.
    • Agile processes to support a consistent development pace.
    • Attention to technical detail and design enhances agility.
    • Collaboration between the business stakeholders and developers throughout the project.
    • Customer satisfaction through early and continuous software delivery.
    • Accommodate changing requirements throughout the development process.

    Based on these principles, there are three points—the final three listed here—that we often find the most compelling. A colleague of mine, Tobias Spöcker, scrum master and QA engineer, says these points naturally float to the top for an organization such as TOPdesk.

    The reasons for this are fairly obvious. We create products that are sold to thousands of customers around the world. To pinpoint any development problems, we look to the scrum process described by the scrum guide, with an emphasis on the last parts of the process. For example, the following illustration is edifying for explaining this process:

    Agile scrum process

    Notice in the “product release” phase illustrated above that the team listed here focuses on finished work for the development sprint. This portion of the model should be able to present a product incrementally to the stakeholders, including the customer. Ideally, these increments are released through a continuous delivery model. Here are two principles that further illustrate the point: Collaboration between the business stakeholders and developers throughout the project and customer satisfaction through early and continuous delivery of the software.

    There’s an additional consideration when providing value: Develop what is right; don’t simply develop something right.

    Adding Value

    At TOPdesk, providing the proper value to customers is a major goal for us. To achieve our organizational goals, we consider the impacts on our customers so when we start on a new product development project, we always work with some of our customers so they are involved in the development process, which makes the process and the product better for everyone. Those of our customers that have participated in our development processes usually tell us that they find the experience valuable and that being a part of the process also helps them when they use the solution. These same customers also express satisfaction in our efforts—as partners in the development process—and with us as an organization.

    Direct Feedback is the Key to Better Development

    The immediate and direct feedback we receive also helps to achieve another of our key operational principles: accommodating changing requirements throughout the development process. Through the partnership with our customers during the development phase, we’re able to receive regular, constructive feedback—even criticism—that leads to changes and evolutions in the product map and development stream. This feedback facilitates refinement of the most important processes and features, and moves them to the top of the priority list, leading to a project that’s undertaken with a focus on the most valuable areas so that development capacity (on the part of our organization) is spent the most wisely.

    Agile-Organization

    In Sum

    The agile mindset and the scrum framework are powerful tools if they are used in the right way. When considering following any development principles, don’t go in blindly. It is a good idea to see which parts of the toolbox help your organization be the most agile, efficient and customer-focused, and utilize the processes and principles that work best for your organization.

    Consider direct feedback from customers, which can be implemented immediately into the product scope. Provide simple-to-use customer communications vehicles, including metrics built into the software, surveys and feedback portals. Live demos of the product, when ready, can be extremely effective in helping you collect copious feedback efficiently. However, if your feedback loop is too big—meaning there are too many cooks in your kitchen—the whole process will quickly balloon beyond profitable, resulting in a less agile development process.

    The projects we develop using these principles are the ones that deliver the most value to our customers the most quickly. Including feedback from customers makes the development team more confident in what they are creating, and our customers tell us that they feel their needs and input have been heard, which they greatly appreciate.

    — Nancy Van Elsacker Louisnord

  • Apply Balance and Critical Thinking for Greater Agile Success

    Apply Balance and Critical Thinking for Greater Agile Success

    In an ideal world, implementing DevOps practices and Agile methodologies would be the key building blocks organizations need to realize rapid, high-quality releases.

    The ability to iterate on a product with a high volume, velocity and level of quality is the ultimate goal of the modern enterprise; every CEO wants a faster time to market. But keeping business practices agile is much easier said than done. The term “agile” is broad. While The Agile Manifesto does a good job of defining the concept, there are myriad technical and non-technical aspects to the idea. At the end of the day, simply saying you are “agile” isn’t some silver bullet that delivers faster cycle times, a better product and more satisfied users.

    Instead, success with Agile methodologies means thinking more critically about how they are deployed and if your current DevOps practices are strong enough to support that strategy.

    What is Agility, Really?

    In practice, agility is a complex combination of things, perhaps best understood by what it’s not. Being agile with a product is not simply thinking about how fast you can complete a collection of features. Yes, it’s great when the backlog becomes smaller, faster. But Agile, when applied correctly, is really about having a true understanding of the user’s business problem and a real idea of their envisioned, desired outcome—and what it might take to achieve that outcome.

    This requires a shift in thinking when it comes to the product backlog. Too often, backlogs are viewed vertically, meaning features are built that may not have independent value. As a result, release efforts grow in development effort and elapsed time, limiting the ability to quickly release in small, incremental stages. As an example, consider search functionality as a feature set. On its own, search isn’t necessarily an independently valuable feature. What are users searching for? Why do they need this information and what are they doing with the results? A vertical view of agility fails to ask these questions and focuses only on the myopic feature set at hand. Consequently, even the most mature Agile practices are limited in what they can accomplish. Who really cares if you can get a feature out of the backlog quickly if it doesn’t matter to users?

    Agile thinking should instead be applied horizontally; the user’s journey is the center of everything. What do they need to accomplish? What are they unable to do now and how quickly can we give them that ability? In the search example, this means thinking beyond simply building a search function and instead developing a new product release that eases a specific pain point of users. Quick and iterative changes based on direct user feedback is the goal.

    So Where Does DevOps Come In?

    Agile is hardly a foreign concept for software engineers—86 percent use an Agile methodology (such as scrum) day to day. But the tools, processes and practices of DevOps need to be honed constantly to support iterative development, testing and release of code.

    As with the development of any product, software developers have much to gain from building and testing functionality in small, iterative releases. Smaller tests allow for more intensive studies of accuracy and problem-solving before allowing an entire organization to rely on a solution. While these pilots may not be fully rolled out, the teams involved must be integrated to include voices from a variety of stakeholders, including but not limited to:

    • Architecture
    • Experience design
    • Development
    • Security
    • Quality assurance
    • Operations

    Teams must also keep these DevOps best practices front-of-mind when developing a software solution:

    • Employ microservices. A solution built from these separately deployable services that perform specific business functions is much easier to scale out or expand. Microservices also remove single points of failure (SPOFs) by preventing issues in one area of an application from affecting others.
    • Blend continuous integration (CI) and continuous delivery (CD). These two DevOps strategies support each other in much the same way as integrated human teams that consider stakeholder needs. While CI automates the build and testing processes, CD automates the deployment cycle from development to production. The automation behind both results in a vastly increased deployment frequency.
    • Use infrastructure-as-code. Modern cloud platforms allow for infrastructure to be software-defined. This allows DevOps practitioners to bring best practices from the field of software engineering to bear against systems challenges. Think about the new features AWS announced for CloudFormation this year, for example: configuration drift detection, dynamic references, macros (functions with iteration support) and linters. All of these are in support of treating infrastructure orchestration as a software engineering activity, allowing DevOps teams to use one common set of tools and practices.
    • Refine observability. As architecture becomes ever more complex, the practices of monitoring and logging are evolving. No longer can you independently monitor the uptime of a server and simply log OS and app issues. Application performance management (APM) becomes paramount, measuring aspects of the user experience as they flow through the app, as does identifying and publishing relevant business metrics. The distributed nature of microservices and the various cloud services enabling them, demand new tooling to measure potential bottlenecks in the form of distributed tracing. And the DevOps best practice of “hands-off production” (e.g. no shell or attachment access) means you’ll need to provide real-time visibility into the health and inner workings of your application via log shipping, adding your centralized logging solution into the critical path of application troubleshooting.
    • Focus on communication. This is perhaps the most beneficial point for your team and should not be overlooked. The cross-functional, collaborative teams supported by both Agile and DevOps culture break down traditional silos and unite members around a common goal. Formal structures around these teams should start early and continue through retrospectives to assess and celebrate everything you’ve accomplished in a short time. You’re not working in a vacuum, and this project isn’t the only one your team will ever produce. Keeping careful records of successes, failures and areas for improvement will only make your work more efficient and Agile in the future.

    Agile is the perfect process for the modern tech landscape—releasing quickly in small bites that are then perfected based on customer feedback. In living up to that ideal, teams who turn to Agile in managing their projects shouldn’t take a set-it-and-forget-it approach to their processes. Instead, bolstered by DevOps tools, culture and practices, they should embrace the ongoing refinement and reflection required to support both customer needs and business goals.

    — Adam Hanson

  • Our Sprint to Agile Success

    Our Sprint to Agile Success

    Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

    We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

    But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

    A change is needed.

    Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

    Our Perception Was Wrong

    When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

    At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

    As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

    This is what brought us back to the drawing board.

    Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

    The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

    Renewed Focus

    Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:

    • Adoption of sprints
    • Open communication
    • Version tracking
    • Environment of continuous testing
    • Responsibility definition

    None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

    The Daily Sprint Meeting

    In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

    The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:

    1. What did I accomplish yesterday?
    2. What will I achieve today?
    3. What obstacles do I face to accomplish my projects?
    4. How am I feeling today?

    With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

    The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

    About the Author/Logan Rivenes

    LRivenes PictureLogan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
    Twitter: @loganrivenes

    LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a