Tag Archive for: Modern Agile

Tag Archive for: Modern Agile

In 2001, gathered together in Snowbird, Utah, a group of 17 like-minded software developers brainstormed ways to quickly build software and get it into the hands of end-users. Out of this meeting the Agile Manifesto was born.

The iterative and incremental methodology of Agile has generally been accepted as a modern approach to software development and has high adoption rates across many industries. However, with fluidity and responsiveness to change at the forefront of Agile’s methodology, many organizations believe that Agile is not compatible with highly regulated industries. Lack of planning and documentation, they wrongly believe, are reasons why Agile cannot work for those building products under regulatory compliance.

The truth is that using Agile for product development within regulated industries is actually true to the Agile Manifesto. Here’s why:

Agile is a Set of Values, Not a Set of Rules

The full Agile Manifesto is a succinct and comprehensive overview of the framework’s principles, and the gist is quite simple. Agile is a methodology that encourages teams to iterate; to communicate with stakeholders, customers and suppliers; to not go crazy with documentation; and to be good human beings at work. Pretty simple, right?

So why do many organizations in regulated industries believe that Agile is not feasible?

While dealing with audit requirements and regulatory compliance, the idea of fluidity and “responding to change over following a plan” may have those in regulated industries cringing. But where in the Agile Manifesto does it say that planning and documenting have no place in your software development process? It doesn’t.

The truth is, adopting Agile values just means you are agreeing to open communication, iterating and focusing on delivering a product. Values are just one part of the product development process – organizations in highly regulated industries can adopt Agile values but still select a stricter framework and strategy to adhere to regulatory standards and document their processes.

And while documentation is not discouraged in Agile, teams are encouraged to view working software as a better indicator that the product meets requirements rather than reams of documentation.

Why Choose Agile for Regulated Industries?

Waterfall has traditionally been a popular choice for highly regulated industries. And yet, the number of organizations adopting Agile now due to very low success rates with Waterfall is rising. With fixed requirements and rigidity as the basis for Waterfall processes, there’s very little room for change and flexibility as requirements evolve.

On the other hand, teams who have adopted an Agile methodology are highly focused on creating products that meet end-users’ needs. And Agile gives them the flexibility to be both iterative and fluid.

Agile methodologies also allow for (and encourage) communication between customers, stakeholders and suppliers. You’ll be able to see in real time what’s working and what’s not and, in turn, keep tabs on what your customers want. By constantly reexamining customer needs and wants, Agile teams are more likely to deliver a product that meets users’ expectations. This, simply put, can be your competitive advantage.

Agile not only makes good business sense but may also help your employees feel happier and more fulfilled at work. Adopting the Agile methodology empowers your engineering and product development teams to change as they need and to use their professional judgement. It allows them to have open communication, to know that what they’re building is useful, and to feel that they are being respected and heard.

Leveraging Jama Connect™ for Agile Documentation

When adopting Agile in highly regulated industries, it’s important that you work closely with auditors — internal or external — to clearly communicate your documentation processes. This is where Jama Connect™ comes in.

Jama Connect is your single source of truth when it comes to complex product development. It allows you to document and communicate your requirements and what you’re setting out to build, and gives you a record of who, what and why things changed along the way. Plus, if you decide to make a change or switch directions, everything is fully reversible.

Real-time collaboration within Jama Connect gives you a platform to discuss change by connecting comments, decisions and reasoning throughout the project. With closer communication (in accordance with Agile methodology), teams experience increased productivity, a shorter design process and critical context for improved decision-making.

Jama Connect provides your team with valuable information to help them decide when and how to make changes.

Is Agile Right for Your Team?

While Agile is compatible with all industries — even those with strict regulatory standards — it all comes down to choosing a methodology that is right for your team. A good place to start is by identifying what values are most important to you and your organization and examining your processes to understand what you want to achieve.

Download our whitepaper, Agile for the Enterprise, to learn more about successfully implementing Agile in regulated and governed industries.

How do you create responsive teams that deliver better products faster? This organizational shift is hard – and requires change across people, process and technology. Last week, during Jama’s webinar: The Agile, Customer-focused Organization: How to Evolve, Forrester Research guest presenter Kurt Bittner walked  through actionable steps that lead to this evolution. In this webinar, questions about enabling organizational collaboration surfaced.

Kurt Bittner answers them today.

Webinar Participant: Does technology affect the people and process dimensions? Some people in my organization say we should focus first on the cultural and process changes and then look for technologies that support them.

Kurt Bittner: All three dimensions need to change in unison. The reason for this is that the processes that people perform are affected by the technologies that they use, and therefore people work differently depending on the process and tools they use. As a simple example, smart phones have changed our culture in important ways. With technology at our fingertips, we now expect to be connected all the time. Older technologies like email are giving way to newer technologies like chat and video. As digital technologies make new things possible that were unimaginable before, people adapt to interacting in new ways that change the culture.

In the business context, widespread adoption of social media technologies has changed the way that people interact as well. Circulating lengthy and complex documents for review has declined as people expect more interactive conversations using chat-like interfaces. None of these behavioral changes would have been possible without changes to technology that lead to cultural and process changes.

WP: Our company is in the process of adopting Agile for some teams. How does what you’ve talked about related to Agile?

KB: One of the defining characteristics of Agile is the dedicated cross-functional team. There are several reasons why this is one of the most important Agile practices, but they include improving collaboration and reducing time spent waiting for resources to become available to work on a task. Reducing wait time and improving collaboration improves delivery velocity.

In the broader context I presented, organizations expand the membership of the cross-functional team (which I have referred to as an integrated product team) to include other skills, including User Experience (Ux), Customer Experience (CX), operations, security, and architecture, among others. The goal is the same, however: To eliminate waste and improve throughput by improving collaboration and reducing unproductive wait time.

Beyond that, the second major aspect of Agile is that delivering working software in small increments increases cross-role collaboration and reduces waste by improve the speed at which teams obtain feedback on the quality and suitability of their work. Doing so tends to break down organizational silos and change both the behavior of team members and the culture of the organization.

WP: My organization hasn’t had very good luck with large-scale change initiatives. Everything we hear about Agile is that it’s a huge cultural change. How should we get started, and what pitfalls should we know about so we can avoid them?

KB: We have observed that organizations who are successful in their adoption of these practices get started by changing a team at a time. They choose a product area that is experiencing pressure from customers and competitors to improve delivery speed and product quality, and they use this pressure to motivate change. They let team members “opt-in” to avoid the negative effects of coercive pressure, and they support the change with training, coaching, and hiring/acquiring resources with the new skills, where necessary. Leaders support the change by removing obstacles and impediments, and they promote and celebrate successes when they occur. When there are setbacks, leaders encourage the team to learn from the experience rather than punishing mistakes. As teams become successful, they expand the adoption by sharing what they have learned with other teams also on the journey. Peer pressure tends to drive the adoption over time, as other product leaders and potential team members see the results of the new way of working and want to achieve similar results for their own products or teams. Leaders also change the measures of success to reinforce customer-driven goals. In short, culture tends to change bottom-up, supported by leaders who encourage and support the change.

WP: How do I take this information back to leaders in my organization to get them to help with the changes we need to make?

KB: First, help them understand that there is a better way to organize for better customer results. Help them to understand that the change proceeds product-by-product, team-by-team. Help them understand how cross-functional teams break down barriers between functional roles and enable better collaboration that results in less waste and less time spent waiting. And help them to find a product where your organization can experiment and learn – one where customers are demanding better experiences, faster, and where competitors are threatening to take those customers away. Finding such a product makes the change less risky – everyone knows that the old way of working is sure to fail so they are open to working in a new way.

Learn more on how product organizations enable collaboration that results in efficient integration of customer feedback, less meetings, faster real-time reviews and decisions:

https://jamasoftware-1.wistia.com/medias/gla54mbxl6

This is the seventh post in a series examining the changes that have occurred since the Agile Manifesto was published and the implications they have on how we might consider the Manifesto today. Find the first post here.

In 2001 the notion was that documentation should be replaced by working software. Of course, back then ‘software’ was a simpler concept. Certainly some was very complex, but overall, software products have grown greatly in complexity. The mindset at the time often was to document everything upfront, then go build, the result was that teams built the wrong thing.

Alistair Cockburn, signer of the Manifesto, has spoken about the word “comprehensive” and the decision to use it. According to Cockburn, this software term was highly debated. The creators didn’t want people to think that documentation in and of itself was unnecessary because they did believe it was important. The intent was to call out exhaustive documentation as overkill.

Today we have more complex software. We also have realities of Minimum Viable Product (MVP) and continuous delivery. The idea of working software is much more of a reality. This does not change the importance of documentation. What does change is the idea of the word ‘document.’ A white board, sticky notes, wiki, or collaboration software, these are all documentation. This is a critical and necessary aspect of the process. The ability to respond to change, to interact, in fact everything the Agile Manifesto believes in relates to communication and collaboration around something – the ideas, stories, epics, and decisions written and made everyday.

Read the next post in this series, “Rethinking the Agile Manifesto: Customer Collaboration and Contract Negotiation.”