devopsy.kinsta.cloud

Tag: agile transformation

  • 4 Ways to Overcome Agile Transformation Obstacles

    4 Ways to Overcome Agile Transformation Obstacles

    If an organization desires a successful Agile transformation, the first step is to shift its thinking from ‘doing Agile’ to ‘being agile.’ Unfortunately, a commonly shared belief that Agile is just a software development methodology keeps too many companies stuck in the ‘doing Agile’ mindset.

    This belief ties back to the principles of Agile thinking from frameworks like Scrum or Lean. Most of these methodologies were focused on teams of developers. Naturally, the vocabulary and tools derived from these methods are unique to software development. While development has evolved away from waterfall approaches, the rest of the organization tends to run into cultural challenges downstream because the vocabulary and ways of working are foreign.

    When an organization begins to lose progress downstream, it is too focused ‘doing Agile’ rather than ‘being agile.’ In order to shift the mindset toward ‘being agile,’ a new mindset must be adopted across the organization. These four insights offer ways to overcome obstacles along the way:

    Instill Agile Thinking Across the Organization

    The first step toward instilling agile thinking is to establish common vocabulary and define what it means to be agile. A common vocabulary and understanding of agility helps teams across the organization understand and see that agility is more than doing sprints.

    As an organizational strategy, agility equates to flexibility – the ability to adapt to changing business requirements. It also means being collaborative and making complex processes more lightweight. Instilling this type of agile thinking into everyone at the organization leads to success. DevOps, for example, successfully instills this type of thinking through value stream management.

    Essentially, this hurdle boils down to setting common goals and creating a common understanding of what ‘agile’ means across the organization.

    Achieve Autonomy Through Self-Organization

    Agile frameworks encourage self-organization. When teams self-organize they are given a task to do. However, no one tells them how they’re going to accomplish it. A self-organizing team gains a certain amount of autonomy, which leads to empowerment.

    With self-organization also comes risk. The organization must learn how to embrace risk, how to look at failure as an opportunity to improve and how to empower teams in a more self-regulating way. When teams self-regulate and self-organize, it’s a team win when they are successful. This develops a sense of communal pride.

    When breaches or too many failures do happen in a self-regulating system, the policies and consequences naturally occur. However, the key differentiator is that these environments are not driven by the policies. Rather, the objectives drive the behavior. When objectives are being met, empowerment stands.

    Agile software development, DevOps and site reliability engineering (SRE) are intended to be self-regulating systems, but all first require leadership to create psychologically safe environments, blameless postmortems and more. There is no room for a blame culture in a self-regulating system, and the organization must be agile enough to meet the demands of the system.

    Leverage Intelligent Lightweight Process

    Agility does not equate to a complete absence of process. It means there is enough process in place to ensure consistency, improve flow between people and teams and that automation replicates the process simply and effectively.

    IT organizations must understand that it is possible to move away from complex and authority-based processes and continue to leverage an element of process.

    Intelligent Process Means Intelligent Automation

    Although humans are the driving force behind agility, automation helps them go faster with more consistency. However, there is no such thing as ‘being agile’ with automation alone. Agile cannot be bought, and it’s important to get teams thinking that way. Automation should complement Agile, but not define it.

    When investing in automation, a cost/benefit analysis is critical. When considering automation, think in terms of two key metrics: time and quality. With two equally important metrics, the organization cannot become dependent on one aspect or another.

    For example, you can’t go faster with a manual process. You also can’t go faster with only automation, because the automation alone doesn’t replicate your intelligent lightweight process. And, you can’t go faster just by having a process, because the process can become very bureaucratic.

    Process is just a means of getting there, but it needs people and automation to make the processes come alive. People, process and automation all play an essential role in creating an intelligent process.

    Successful Agile transformation is more a way of thinking and behaving than simply following a framework. From a human perspective, an organization that experiences true agility, as we’ve defined it today, allows humans to exercise their competencies, grow skills, collaboratively celebrate success and learn from failures.

    If you’d like to learn more about Agile Transformation, especially in regards to Agile Testing, you can register for the next SKILup Day on April 22. Please register for SKILup Day: Agile Test Management for the Enterprise here.

  • These Three Approaches Will Help Your Enterprise Be More Agile

    These Three Approaches Will Help Your Enterprise Be More Agile

    Nearly every organization that tries to change its culture to be more agile and better adapt to changing environments discovers that it’s harder than it looks. Agile transformation can’t be superficial or only embraced by the IT department–it needs to be completely pervasive throughout the business.

    There is no one-size-fits-all approach or playbook that can be used to fit any organization’s unique situation. Yet, there are some common takeaways and best practices that can be gleaned from organizations that have successfully undergone agile transformation. Here are three common themes I’ve come away with from talking with organizations at various stages of their agile journey.

    Creating an Agile Enterprise Relies on Successfully Orchestrating Change in Culture, Organizational Structure and Technical Capabilities at the Same Time

    Changing enterprise organizational structure without changing culture and technology will lead to factors that drag down any potential transformation. It’s equally true when addressing any one of the elements in a vacuum. Instead, enterprises must address all three at once, which makes for a tricky prioritization exercise. 

    In many cases, new solutions will lead to new problems that organizations must address as they arise. Agile teams enabled to self-organize and pursue customer problems with greater freedom may find themselves hamstrung by inflexible legacy technology. Changing technology to enable agility may uncover additional organizational difficulties, and so on. Agile transformation is a long journey, and enterprises must adjust on the fly to their own unique circumstances.

    When Making Changes to Drive Agility, Think About What Scarf Everyone Wears

    Missy Lawrence-Johnston, a principal consultant from ISG’s Organizational Change Management practice, suggests that leaders should remember a warm and fuzzy acronym when working toward change: status, certainty, autonomy, relatedness and fairness (SCARF). The SCARF model was developed by neuroscientist David Rock, and explains how individuals react to change based on perceived threats and rewards. 

    If a change negatively impacts someone on one of the dimensions they consider important, they’re more likely to push back on it. For example, a manager who cares a great deal about their status will probably have difficulty embracing an organizational shift that works to cut down on organizational hierarchy. But that same change could be highly valued by a rank-and-file employee who prefers greater autonomy. How people react is individual, which is why the SCARF everyone wears is unique to them, as Lawrence-Johnston points out.

    As enterprises make the changes necessary to embrace agility, keeping this concept in mind will make it easier to navigate the threat responses employees inevitably have.

    Measure Culture by the Behaviors People Exhibit at Work Every Day

    ISG research shows that culture and team enablement are the most important factors when transforming into an agile enterprise. While culture can seem like something nebulous and difficult to pin down, it’s best evaluated by noticing what people do every day. Odds are, any employee of a firm has at least one story that illustrates what they see as the culture of the organization where they work. An enterprise’s culture is the sum of these stories.

    Agile transformation requires some fairly radical changes for businesses that are used to working in a waterfall mindset. This often looks like a shift from a hierarchical, rule-driven culture that focuses on command and control to a collaborative, self-organizing culture with servant leadership. Implementing this degree of change takes significant work. 

    When changing culture, it’s not enough to put up a fresh set of posters with new values. Living those values and building organizational structures to support them is the key to success.

    — Blair Hanley Frank

  • Agile and DevOps Success Needs Continuous Testing

    Agile and DevOps Success Needs Continuous Testing

    One of the central ways to progress an agile transformation is to introduce continuous testing. With all such changes, it is cultural as much as technical. The expected outcomes are less broken builds and reduced time from break to fix, as well as a yardstick for measuring the team’s ambition for improvement.

    The Testing Bit and the Continuous Bit: Testing should be part of any agile developer’s skillset; the shift is to apply it to the whole build pipeline. Continuous implies automation, with the build featuring as a living thing whose state is always changing. The infrastructure options have expanded with the advent of cloud computing and virtual containers.

    Let’s say your teams’ developers work on components, independently buildable and testable chunks of the whole app or service. They receive stories and tasks to improve a customer journey and then add functionality to implement these. And when done, they check their work into your team’s code repository.

    Starting with One Developer, One Laptop and One Test

    The initial testing focus for a single developer (or pair) working on code will be the unit test and the coverage test. Whether writing the test first or code first, the unit test pokes the bounds of the new code and the coverage test checks that all code paths are exercised.

    As an example, maybe the developer has implemented the “customer wants to deposit money” story on an accounts component of a banking system. The tests should check what happens if a user deposits zero, negative or fractional money and the coverage confirms the tests have wandered down all possible the code paths of the new feature. In this way, coverage tests also prevent a developer from adding code without introducing the corresponding tests.

    At this point, it is worthwhile making sure tests are run as part of the build so every time the developer builds the code all the unit tests are run. This is a fairly standard thing for most build systems to do. The bottom line is the chance of checking-in breaking code is greatly reduced.

    Now the Bigger Picture

    The new code worked on your developer’s laptop, the tests passed and they checked-in the code. But in a busy enterprise team, other developers are also working on the same component, maybe even on the same file. This is no different from working on a book chapter with several authors. Your developer worked with a stable snapshot of the code. It is quite possible changes were made by others that conflict with the changes your developer just made. So how do we proceed?

    This is the purpose of the central build. The job of the central build is to check out all code for that component, build it and run all associated tests whenever new code is checked in. In today’s world, the likely path would be to create a container on a cloud server, where the component can be built from scratch, and then all the tests run against it. Traditionally, a tool such as Jenkins would watch for git check-ins and kick off a build. The result is the team always knows if the overall build is green (working) or red (broken). A developer must understand the central build is the true source of truth, not what is happening on their laptop. So, the latest check-in leads to a correctly built component. What next?

    There are three general types of testing needed to develop a software system. Tests that make sure new features work correctly and don’t break the component, tests that make sure the components still work with each other and those confirming the customer journeys your component participates in all work as expected. There would be no point in making a deposit function without a customer journey test that proves a customer can deposit cash with the system.

    The second type of testing, usually referred to as integration testing, needs an environment where all current successfully built components can communicate with each other. Today, that may mean some form of container orchestration with the system’s components placed and managed in their containers. Tests of a customer journey may involve emulating the customer’s manipulation of a website or mobile app, depending on how the application or service is accessed. These are the tests stakeholders are most interested in as they confirm what has been requested in the stories actually work. As with integration testing, these tests may be run less often.

    I Mock Thee

    Mock (or fake) services and data are a necessary part of the testing process, and usually, must be maintained and extended as part of the testing. A feature story may require a developer to spend more time developing or extending a mock service than writing the code it helps test. For example, a mock account with some transaction history is needed to test a new deposit function.

    Live environments can never be entirely simulated in test environments. Sometimes a live service uses a paid for third-party service, and it would be too expensive to use in testing. It is usually the case that the development staff are not permitted to work with live customer data.

    The Build Is Alive

    All the structures mentioned are just products of one simple attitude: “How do I know if this works?” For continuous testing to thrive, engineers should always question whether every part of the system is being tested and whether the tests are being evolved at the same pace as feature development. When tests or mocks are missing, an agile team refers to technical debt. This is as it implies, something that must be paid for later.

    When team members realize they cannot just check-in code and go to lunch without checking the central build, that is a good sign. Information radiators such as large screen displays of the build state should be used to get the extended team to understand the state of the build is everyone’s concern, throughout the lifecycle.

    — David Eastman