devopsy.kinsta.cloud

Tag: sprint

  • Best Practices to Improve your Engineering Sprints

    Best Practices to Improve your Engineering Sprints

    What is the purpose of sprints? We break work into sprints so we can more easily monitor, estimate and predict what we want to ship and when. Over the years, engineering teams have gotten used to moving quickly from one sprint to the next, but I think it’s important to be more thoughtful in how we plan and execute sprints.

    Running effective and successful sprints can define whether or not your organization is able to ship high-quality software fast and often. It also gives teams more flexibility and the ability to quickly change something that is not working or, on the other hand, to iterate on a successful technology. 

    After almost 20 years as an engineer, manager and as a CTO, I have found there are several best practices that improve the sprints that are part of my team’s software development life cycle. 

    Sprint Planning

    When planning a sprint, there are several things to keep in mind.

    Make Sure the Work Aligns with Business Priorities

    There are always a number of elements an engineering team can focus on during any given sprint. It’s fairly easy to lose sight of the business’ end goal. Make sure to gut-check to make sure that the sprint goals align with current business priorities.

    Ensure the Workload is Balanced From the Start

    This seems like an obvious statement, but make sure team members have equivalent workloads so you avoid burnout. It is also important to understand how different engineers on the team work—some people work best by selecting their own tasks with items that are unassigned, some pick up unfinished tasks as they finish others and some prefer to be assigned certain tasks because they have specialized skills. 

    Don’t Underestimate the Time That Interruptions/Additions Take 

    Along the same lines as the above, don’t overlook this for several reasons. Without adequate, data-driven insight into the actual state of each team member’s workload, it is almost impossible to gauge what’s happening in real-time. While business-critical sprints are assumed to take priority, side projects, Slack interruptions and meetings can easily consume an engineer’s day. Make sure to proactively check that each member has enough true deep work time without becoming burned out. 

    Don’t Underestimate the Time it Takes to get Things to a Done State

    Sometimes engineering teams only look at the development stage, but the full cycle required for the software to get to the end user might take longer. Allotting the right amount of time to get the job done across all phases of development will help avoid unexpected surprises. 

    When You Get to Mid-Sprint

    Monitor Unplanned Work

    Initial planning doesn’t necessarily take into account the bugs and fire drills that will likely arise after the sprint starts. Pay close attention to any mid-sprint additions and adjust as necessary. There may be team members who have cleared their sprint queue and are capable of taking on this work, but being aware of team members’ workloads at every stage is critical. 

    Do Daily Stand-Ups and Raise Flags as Early as Possible

    This will help anyone encountering roadblocks so a small issue doesn’t turn into a huge bottleneck. If you look closely at your PR cycle time, you will find a ton of insights about where roadblocks often happen. Using historical data during sprints can also go a long way toward helping identify potential bottlenecks, allowing you to proactively avoid friction by delegating reviews or setting out additional time for approvals. 

    Get Ahead of Burnout

    The tech industry has a turnover rate of 13.2%—pretty high when compared to other sectors. But the reality is that it can be really difficult to identify burnout without hard data. Don’t wait until people start speaking out about being overworked: Burnout prevention should be a full-time focus. Before sprints, make sure people aren’t coming in with high levels of fatigue and make sure that overtime doesn’t routinely increase throughout.

    Use Sprint Progress Estimations to Reprioritize

    Each sprint starts off with a set workload, but in reality, every sprint is dynamic. Take a look at each day’s progress and evaluate if your team is ahead of or behind schedule. If you are on track to finish a majority of the work, you can anticipate a successful sprint end. If not, don’t worry; you can always recommend that your team recalculate priorities. Engineering managers can take this time to load-balance some of the heavier work and shift goals to the next sprint as needed. Staying flexible while maintaining a clear view of what is actually happening during the sprint, will inevitably result in success. 

    At the End of the Sprint

    Do a Thorough Sprint Retrospective 

    As a team leader, you should constantly be thinking about how things are going and how people are feeling. If you can, use hard data to look at things like time allocation, PR throughput and any items added mid-sprint. Taking notes throughout the sprint will help remind you of any issues that came up, and you can discuss ways to improve for next time. Each sprint is a chance to learn; the more you learn, the better the sprint and the better the product will be for end users. 

  • Assembling the Key Components of Continuous Delivery

    Assembling the Key Components of Continuous Delivery

    As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

    This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

    Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

    Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

    Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

    In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

    These building blocks of continuous delivery are:

    • Continuous development & integration,
    • Continuous testing. and
    • Continuous release.

    Continuous Development and Integration

    When it comes to delivering quality apps faster, every second counts.

    That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

    This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

    Fig 1: Continuous Development and Integration

    Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

    The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

    Continuous Testing

    Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

    After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

    Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

    Fig 2: Continuous Testing

    It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

    After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

    Continuous Release

    Continuous release matches release velocity to development velocity through controlled and scalable deployments.

    The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

    As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

    Fig 3: Continuous Release

    After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

    This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

    In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

    Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

    — Anand Akela

  • Best Practices to Prevent Scrum Failure

    Best Practices to Prevent Scrum Failure

    In my years of experience as a scrum master, I’ve encountered numerous situations where scrum has resulted in less-than-ideal outcomes, a Scrum failure if you will—not because the agile framework is flawed, but because the company didn’t understand, or disregarded, how scrum is supposed to work.

    For example, I was once a scrum master for an e-commerce website production team where a new feature was considered so critical that it was prioritized over everything else in the backlog. Minimal time was taken for the development of user stories and my team had to make assumptions because the business stakeholders were unavailable. When we were nearing completion, the stakeholders came out of hiding and identified more business rules that required not only additional work, but some re-work of things that were already completed, including global changes to the company’s customer-facing website. The impact to the business had not been appropriately analyzed, and when the new feature was rolled out, the value delivered was negative, causing refunds and ultimately financial loss.

    Sadly, scenarios like these are not uncommon. The scrum framework is ideal for situations where priorities change often, but many companies struggle with finding the right rhythm to implement and manage those changes. Scrum fails when companies don’t build a shared consensus on which principles should form their definition of agile delivery, or fail to educate everyone involved on how the agile processes should work. One very common example involves the most basic of agile artifacts: the sprint plan. I can’t tell you how many times I’ve completed a long day of planning only to run into an executive who wants to add something to the sprint. This is where understanding the methodology and sticking to it are important, especially because changing the sprint plan will impact your team’s morale, as well as its productivity. As much as we love our stakeholders, they should not swoop in at the last minute and bypass the product owner.

    For those unfamiliar with scrum terms, the product backlog identifies the longer term priorities for a project or product team. The sprint backlog determines current sprint priorities and sets a shared goal for delivery team execution. Product backlog priorities can (and should) change all the time, but sprint backlog priorities should be locked down for the duration of the sprint. At the beginning of each sprint the team participates in a planning meeting where the highest priority stories are pulled from the product backlog and reviewed. The final output of a planning meeting is a prioritized sprint backlog that represents the plan for the sprint. Once the sprint plan is determined, it should be protected. There are always exceptions, but to ensure scrum works, the scrum master must protect the plan as much as possible.

    So, how can you make sure your team moves as fast as possible but can still address changing priorities? Below are a few lessons I’ve learned:

    1. Determine the Appropriate Sprint Length

    First, and most importantly, determine a sprint length that is appropriate for your organization. I would recommend that companies new to scrum should avoid one week and four week sprints. One week sprints move too fast for new teams and are too heavily burdened with meetings. Four week sprint teams have a hard time staying with the sprint plan, especially new teams who don’t fully understand the impact of changing priorities mid-sprint. I’m not saying that four week sprints never work, but I find that a four week sprint length makes it difficult to keep the team on track. Two week cycles have traditionally been the preferred length for agile enthusiasts. When I’ve worked on project teams where code will not be moved to production at the end of the sprint, a two week sprint duration works well; however, my production teams seem to prefer three week sprints because they can develop new features in the first two weeks and use the last week to do production preparation work. Whatever length is chosen, it needs to work with your product environment. For example, if you’re currently running three week sprints but your scrum master is constantly having to battle to protect the sprint plan, then maybe a two week plan would be more appropriate.

    1. Educate Your Stakeholders

    Once the organization finds the appropriate sprint length, educating stakeholders is essential. How can we expect stakeholders to work with implementing scrum when we don’t help them understand how it should work? Actually communicating the sprint calendar is a good first step. Stakeholders also need to understand the product owner’s role and how they will assist them in assigning their requests the appropriate priority in the product backlog. This can be quite beneficial as many stakeholders who desire to add to the product backlog don’t realize that other higher priority features may not have been completed yet. Working with the product owner provides an impact analysis for the overall product. Sometimes it’s as easy as saying, “Is this more important than x?”  Just that simple question has saved me many times as a scrum master. Sometimes stakeholders just want to get the request on the backlog and don’t mean for everyone to stop work on current priorities. If the request is determined to be the highest priority item at the time, then analysis of the desired behavior can begin. By the time the next sprint planning meeting happens the team will have a much better idea what the request is about and will be more likely to complete the feature with the value envisioned by the requestor.

    1. Build Trust

    Lastly, and perhaps most importantly, the team must build trust among the stakeholders. This has had a huge impact on my scrum teams and has stopped most emergency requests. Teams build trust by setting realistic sprint goals for themselves and then accomplishing those goals on a consistent basis. If the stakeholders know what is planned will get done, they have much more confidence that their request will be completed in a timely manner. This is not an easy task but can be accomplished by improving sprint planning.

    The most effective way to improve sprint planning, and one that I find is often ignored, is utilizing the sprint retrospective. This is where the entire team reviews their performance during the sprint and discusses what went well and should continue and what areas need improvement. The team then decides what one or two things will make the most impact on the next sprint and brainstorm for ways to improve. The retrospective works well because the team decides what to change and begins to build a culture of continuous improvement. As far as agile benefits go, this is one of the most impactful to organizations.

    Another way to build trust is to communicate changes to the plan early and honestly. Let stakeholders know why there was an adjustment to the plan. Was it due to a bad estimate? A delayed approval? Changing priorities mid-sprint? Once stakeholders start seeing the impact they have on the progress, they can assist the team in moving faster too.

    The Result

    When properly implemented, scrum can realize amazing benefits, but scrum teams and stakeholders have to work together to understand and implement the scrum procedures.

    Here’s another true story: When I was a scrum master for another website project team, we had to halt development based on a third party delay. Because we were using scrum, this was no problem—we closed out the last sprint, complete with a proper demo, and the next day held our sprint planning meeting. We started a completely different project that was estimated to take approximately three months, matching the estimated delay for our primary project. We worked with a new product owner and successfully implemented the new feature as planned. The revenue generated from the feature was estimated to pay back the development costs in less than a year, and when completed, the team was able to return to the primary project.

    That’s how scrum is supposed to work.

    About the Author

    Kathy Loveless is an AIM Consultant specializing in agile coaching, agile project management, scrum process improvement, and strategic development. She has an impeccable background in effective agile coaching and transformation and is passionate about immaculate communication and delivering results. AIM Consulting’s expertise in application development and product and project management covers the entire software lifecycle, from architecture to optimizing processes that ensure high quality outcomes with the most efficient delivery. To get in touch, tell us about your challenge.