devopsy.kinsta.cloud

Tag: scrum master

  • The Top Benefits of a Scrum Certification

    The Top Benefits of a Scrum Certification

    The Scrum framework is a staple part of many businesses – and for good reason. The agile process is used to construct, deliver and iterate products and has proven to boost cross-functional teams’ productivity, as well as product quality. And, like most processes, Scrum can be mastered with the right training and commitment. Specifically, a Scrum certification teaches the fundamentals of the framework and serves as proof of qualification for a particular role within that framework.

    Scrum certifications vary, but are typically awarded for the roles of Professional Scrum Master, Product Owner and Scrum Developers. These positions have become increasingly more popular over the years; one report reveals that 24% of organizations have ten or more Scrum Masters or Agile Certified Practitioners, while in a sample of 500,000 certified people, 85% correspond to a Scrum certification program.

    Having a Scrum certification opens many doors, both professionally and personally, as it provides a competitive edge and demonstrates an in-depth understanding of contemporary workflows. Whether you’re considering taking a Scrum course through your company, or pursuing a class independently, here are a few of the top benefits.

    Adapt to Changing Conditions

    Throughout the COVID-19 pandemic and its significant disruption to businesses, organizations had to swiftly adapt to new ways of working. Operating remotely, adopting new digital tools, complications in supply chains, just to name a few, are all challenges met with patience and proactivity. People who work under the tenets of the Scrum mindset tend to be more resilient and better able to respond to unexpected events in a practical manner.

    Rapid fluctuation in personnel, technology and working practices have less of a negative impact on employees, and especially leaders, that are Scrum certified. In shifting environments, the larger organization can be confident that their teams are being guided by Scrum principles and constantly progressing.

    What’s more, people with a Scrum certification can help their teams better adapt to sudden changes without compromising business goals. Scrum emphasizes prioritization of tasks in order of importance; placing the task with the biggest impact on ROI at the top of the list. This method not only maintains productivity but can actually increase it, despite external disruptions.

    Master all Things Scrum

    A Scrum certification highlights that a person is dedicated and hardworking, and is committed to continuous learning and improvement. It is a reflection of the certificate holder’s expertise in helping others and meeting goals. On a more granular level, the certification can help people discover and become familiar with concepts like product backlog, sprint backlog and burndown charts – elements that are common across businesses and industries.

    A Scrum certification can also boost personal communication skills, as it forces people to regularly produce and share relevant reports, deadlines and calendars with their team. These exchanges demand clarity, timeliness and emotional intelligence, which are core soft skills that contribute to the collective success of a team.

    Certified Scrum holders also benefit from their inclusion in a network of qualified Scrum authorities where they can leverage others’ exclusive guidance and knowledge. They can subsequently bring innovative ideas from fellow Scrum experts to their workplace, and leave a powerful legacy through the changes they implement.

    Gain an Advantage in the Hiring Pool

    A Scrum certification also makes a person a much more appealing candidate in the recruitment process. In a competitive hiring landscape, a Scrum certification demonstrates that a candidate is willing to devote time to solving complex, adaptive problems – a quality that will always catch employers’ eyes.

    In fact, 87% of people agree that Scrum improves the quality of work life for teams, while 81% of people believe certifications improve their use of Scrum. A certification shows that someone knows how to manage dynamic priorities, how to deliver products to market in a short space of time and how to increase project visibility. The Scrum qualification is particularly useful for managing large, cross-functional teams. For these reasons, a person with a Scrum certification will be a prime applicant in any hiring pool.

    There can be financial benefits too. Possessing a Scrum certification can lead to higher salaries, because these credentials are so highly sought-after. Certified Scrum Managers tend to earn more, on average, than their non-certified peers, so Scrum candidates are in a stronger position when negotiating compensation.

    The COVID-19 pandemic has presented new opportunities for professionals to invest in their careers on a long-term basis. Scrum techniques and methods prepare workers to generate ideas that make sense in an uncertain sphere, and those who invest in Scrum are making themselves invaluable in today’s workplace.

    A Scrum certification is a way to develop business ideas, projects and services in a smarter, more agile manner. But more than that, a Scrum certification also leads to heightened personal skills, employment desirability and resilience.

  • DevOps Job Titles Emerging in Enterprise IT Organizations

    DevOps Job Titles Emerging in Enterprise IT Organizations

    IT job functions and, by extension, individual titles inside the classic enterprise have been relatively constant. Various hierarchies of developers labored separately alongside IT operations teams that focused mainly on infrastructure. However, the emphasis on continuous integration and continuous development (CI/CD) within the context of a modern DevOps environment is starting to blur the lines separating who does what inside these organizations. In fact, Phil Guido, general manager of IBM Global Technology Solutions in North America, says new titles such as DevOps engineer and Scrum Master, which better reflect new roles many IT professionals taking on, now are emerging.

    At the crux of this shift is the rise of programmable infrastructure coupled with a need for IT organizations to be more agile. Instead of rolling out a few applications and associated updates a year, IT organizations today are being urged by business leaders to roll out more applications and updates at a pace associated more often with web-scale companies than the classic enterprise. Much of that demand emanates from shareholders and Wall Street to accelerate investment in digital business initiatives that generate higher-margin revenue.

    To achieve those goals, enterprise IT organizations are trying to emulate as many of the DevOps processes employed by web-scale companies. For example, web-scale companies make extensive use of CI/CD technologies and processes to roll out as many new applications as fast as they possibly can. Overseeing those processes are developers who now are accountable for not just writing but also maintaining the application. The theory is that if developers are held accountable for the quality of the application, they will focus more on making sure that application attains a level of quality. The trick is to empower those developers to own everything from the code itself to the programmatic infrastructure it runs on. Because of that requirement, many of those developers adopted a “cloud first” mentality because deploying applications on a public cloud such as Amazon Web Services (AWS) eliminated the need for those developers to engage with IT infrastructure professionals altogether.

    However, most traditional enterprise IT organizations have a much smaller number of application developers. Every minute those developers are not writing code reduces the number of applications an enterprise can roll out. Because of that issue, many enterprises have been trying to find a way for existing IT operations teams and developers to work together hand in glove.

    That requirement, Guido says, is creating a lot of demand for advice from IBM about how to manage DevOps. IBM advises organizations to go slow to ensure they have a few quick successes under their belts before propagating DevOps across the entire organization, he notes. If an organization tries to do too much or move too fast, there’s a good chance that employee resistance to change will only increase. Above all, Guido says, organizations should avoid being too prescriptive in how they define DevOps.

    Of course, not everyone agrees that changing job titles is always the best way to go about fostering change. But human nature being what it is within large organizations, some job titles will have to be reclassified to bring about permanent change.

    — Mike Vizard

  • Demystifying Scrum for the Ops Crowd

    Demystifying Scrum for the Ops Crowd

    Scrum is, by far, the most popular way development teams are organized and work. In fact, well over 70 percent of Agile teams around the world use Scrum. But for those unfamiliar with the structure, Scrum may look like a strange collection of rituals and oddly named designations, such as the “Scrum Master.”

    However, behind that collection of ceremonies, roles and rituals, Scrum is a huge opportunity for Operations teams to streamline development and delivery, improve productivity and create a strong sense of team within the group. Not only does Scrum encourage DevOps, but because it is empirical, risk and visibility are first-class citizens.

    Scrum Basics, and More

    For those wondering how to get started, here are eight things that every operations professional needs to know about Scrum:

    1. Scrum is not focused solely on developing software; it’s about delivering software. The Agile Manifesto describes it as “working software” and Scrum describes it as being “Done,” but ultimately, Agile encourages teams to deliver working software to production frequently. With that in mind, it becomes clear that Scrum is not just about software development, but includes everyone involved in delivering working software to customers.
    2. Definition of “Done” is a DevOps artifact. “Done” describes what it means to be finished with a product backlog item (PBI). Ideally, it describes all the steps necessary to release the PBI to production, or highlights the gap between what the Scrum team thinks Done is and Operations’ idea of what it means to be complete with a piece of work. Operations professionals need to get involved in the formation of the definition of Done (DoD) and work with the team to both improve its reach and validate its use.
    3. The increment should be integrated and deployable. In Scum-speak, the increment is the working software the team produces during a Sprint (a set time frame, from start to Done). If multiple Scrum teams are working on the same product, then it is crucial that the increment be integrated across those Scrum teams. And, when I say integrated, I really mean integrated—as in, tested with processes and practices that are consistent with delivery to production. Thus, the increment is “ready to go.” By regularly integrating the increment, many of the problems that historically have plagued Operations are removed, as teams are, by design, forced into falling in sync much earlier in the life cycle.
    4. The Sprint Review is not a phase gate to production. When moving from waterfall to Scrum, many organizations confuse the Sprint Review with a phase gate to move to production. Rather than being a phase gate for production—or the next phase of the process—the Sprint Review is a mechanism for the team and stakeholders to inspect and adapt at the boundary of the sprint. Ideally, the Sprint Review is executed on software that is being used by real users, in production. This increases the value of the review, as the team and stakeholders get to inspect how real people are using the software.
    5. Continuous integration and continuous delivery automate Done. At the heart of Scrum is the idea that teams deliver working software in small batches to better understand the risks, requirements and solution. Adding delivery to continuous integration (CI) ensures they not only are integrating the software, but also formalizing the deployment processes to ensure there are no surprises. This is a great place for Operations to get involved and help ensure that aspect of Done is consistent with how it views delivering software. This might mean additional steps—or at the very least—a better understanding of operational versus development systems.
    6. Scrum is an empirical process which helps reduce risk. The idea of delivering small chunks of functionality to support learning is at the heart of Scrum. Ultimately, Operations cares about risk. By delivering software in small batches, it is possible to surface risks early and mitigate them. By frequently delivering software, Scrum teams demonstrate they understand the processes necessary to deliver software, thus removing friction from traditional release processes. However, all of these benefits are undermined if the team does not use “production ready” deployment processes or include risk as part of their prioritization of what to work on next.
    7. The Scrum Masters are Operations’ friends. The role of the Scrum Master is to both protect the team from outside distractions and help them to identify and remove impediments. To deliver Done, the team needs to work effectively with Operations and thus, the Scrum Master often will be the person who helps build those relationships. By working closely with the Scrum Master, Operations professionals will gain better insight into what the Scrum team will need from them and how they can deliver Done software.
    8. Helping the Product Owner understand risk. The Product Owner (PO) manages the backlog, which is the place where all work exists. This means the PO is prioritizing the backlog and deciding on what should be done next. Normally, this is accomplished by looking at business value and negotiating with the Development team to determine what can be most effectively completed next. Operations has a great understanding of risk and, by working with the product owner, can add that context to the backlog, allowing the PO to make informed decisions and about value and risk.

    Ultimately, Scrum provides a great framework to build bridges between Operations and Development and can act as a catalyst to drive fundamental improvements to the way teams collaborate and deliver business value. However, both sides need to stop hiding behind the “mystery of agile” to avoid each other and embrace the desire to break down things into small chunks, incrementally manage risk and get to repeatable Done software as fast as possible.

    About the Author / Dave West

    west-daveDave West is the product owner at scrum.org. He is a frequent keynote speaker and is a widely published author of articles, along with his acclaimed book, “Head First Object-Oriented Analysis and Design.” He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI. Then managed the software delivery practice at Forrester research where he was VP and research director. Prior to joining Scrum.org he was Chief Product Officer at Tasktop where he was responsible for product management, engineering and architecture. Follow him on Twitter.

    — Dave West

  • The Forgotten Fourth Question

    The Forgotten Fourth Question

    A very well-written paragraph about DevOps appears in Mike Loukides’ book, “What is DevOps”:

    … Modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in “platform as a service” environments. Operations doesn’t go away, a good part of it becomes part of the development. And rather than envision some sort of Uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away – it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as DevOps.

    These days, recruiters to managers, engineers to analysts and, of course, CXOs all are interested in DevOps. They have questions such as, “What is DevOps?” “What are the DevOps requirements?” “What are DevOps implementations challenges?” But the key question is, “Why does DevOps remain difficult to implement?”

    Adopting DevOps does not simply mean adopting new processes or toolsets. “Why DevOps” can be understood better by focusing on the benefits it will give you. So let’s dive deeper into one of the key best practices we discovered in our journey into DevOps.

    Agile to DevOps

    Business challenges, complexities and competition pushed companies to innovate and solve their existing business problems in a better way, adding more features and integrated solutions. Ways of implementing solutions vary from organization to organization, adoption of tools and technologies also differ by small and large organizations based on complexity of problems, but it’s clear that many have adopted agile practices in the past two decades. Agile was made clear by a few well-defined processes such as iteration planning, daily scrum meetings, scrum of scrums (in larger enterprises), iteration demos, retrospective meetings and small, empowered teams.

    One of the key mindset changes most of the IT world went through while transforming themselves into agile execution was to have more verbal communications and daily scrum meetings. Daily scrum meetings required the scrum master to ask three questions:

    • What was completed yesterday?
    • What will be completed by end of today?
    • Any blockers?

    These three simple questions kept things simple and quick.

    As agility is extended to Ops now, there is a need to revisit whether these three questions are enough. There is a need to revisit the attendees in scrum meetings too. There is a need to add some more responsibility to the role of the scrum masters’ communication radius.

    Before we look at the fourth question, lets let look at the key reasons to adopt DevOps implementations in organizations:

    • Achieve higher speed of time to market without compromising Ops stability
    • Better resource utilization across Dev, Test and Ops
    • Be more responsive to customers

    Why would speed of delivery hamper stability in Ops? In our firsthand experience, the communication between Dev and Ops is not that rich in most of the organizations today. If one studies the root cause analysis of problems faced by Ops in trying to keep the environment stable and healthy, one will find some if not all the following issues:

    • Developers are not deployment-aware
    • Developers do not think of exposing or exporting the right controls for allowing Ops to configure app dynamically (Unintentionally. They simply don’t know.)
    • Many configurations are embedded deep inside the app
    • Adding specific third parties, changing their versions is sometimes missed in Ops communications
    • Ops is unable to clearly articulate what they require from Dev, even when everyone is co-located
    • Continuous firefighting in Ops results in fast fixes, better debugging, but not proactive processes
    • Even if weekly meetings between Dev and Ops happen, they do not have a clear agenda or metrics

    While there are many more symptoms and their causes, and while there are multiple solutions to fix processes and problems, we have found particularly one solution that seems effective.

    We added a fourth question to daily scrum meeting. That fourth question is: “Are you blocking Ops?”

    This question is a direct question to each developer in daily scrum meetings. This question essentially means to ask:

    • Have you written in any code that requires a new configuration?
    • Have you written any code that requires change in existing configuration?
    • Have you written any code that is creating a new binary or file that needs to be installed in production?
    • Have you recompiled existing code with new third party libraries because older ones are unsupported, even though there may be no other change in functionality?
    • Have you hard coded any IP address or other configurations into the code which cannot be changed without rebuilding?
    • And so on…

    Ask the Fourth Question

    The above list of questions is developed based on the root cause analysis of app stability in Ops. This list will be different for different developers/teams. The scrum master communicates the appropriate actions to developers based on the answers to these questions. The scrum master also alerts the Ops team and gives them a heads up on what’s coming their way, and provides timely feedback to the developers.

    Is this question important enough to be the fourth question in scrum meetings?

    Or is this question covered as part of the “Any blockers?” already being asked? One can debate either way. The blocker question in scrum meetings is thought of in a limited Dev/QA scope, and that scope has not included the Ops team until now. Given that Ops team faces customers, given that the DevOps movement is about improving synchronization between teams, this Ops question needs to be a first-class citizen in daily scrum meetings.

    Lastly, it’s critical to to look at root cause analysis-related Ops problem as early as possible. The scrum master becomes more mature as he asks this question to his team while interacting with Ops on hearing them out. If teams are funded enough to have someone from Ops into the scrum meetings, then he/she can be the primary representative for Ops and can steer the delivery to be Ops-friendly.

    Irrespective of how one achieves it, taking care of configuration issues proactively in daily meetings, and thinking about Ops on a daily basis in Dev meetings is key to successful DevOps adoption. Configuration issues are not the only focus, but they do form a large chunk of Ops issues.

    From our metrics, customers have seen following benefits after adding the fourth question their scrum meetings:

    • Shipping code 7x more frequently
    • 45 percent fewer failures
    • 12x faster ability to recover earlier in the tool chain

    Please feel free to share your findings with us @ info@opexsoftware.com.

    Happy DevOps!

     

    About the Author/Sanju Burkule

    sanjuSanju Burkule, a pioneer, visionary and creator of Products in the DevOps Space @OpexSoftware. He writes about automation and strong, connected, integrated IT and tweets often about these topics.