"Enterprise Agile": No Longer a Contradiction of Terms
by Jiri Walek
The benefits of Agile development are widely known and embraced these days. But, just in case it’s new ground for you:
- Agile processes are focused on delivering the most business value in the shortest time.
- Agile shortens time-to-market significantly.
- Agile embraces inevitable change: the customer can change the priority of not yet implemented requirements any time.
- Agile teams are open to collaboration across boundaries: business people and developers work together.
- Agile development enables fast and repeated checks on the real status of development.
- Agile development teams deliver working software every two to four weeks.
- At the end of each Agile iteration, the product is implemented, tested, accepted, and potentially deliverable to a Customer.
- The Customer decides if the Agile-developed product will be released, or further improved in another iteration.
The ability to handle change, even late in the development cycle, is now widely accepted not merely as a “best practice”, but as a prerequisite to success in a world ofever-increasing competition and shrinking resources.
Agile is easy for some companies. A simple task board with sticky notes on the wall, a daily standup meeting, and maybe an assessment meeting following each iteration does the job and brings success… no other management or communication tools needed, thank you very much. If that’s your situation, smile, count yourself lucky, go get some coffee and skip the rest of this article!
But what if you’re in a highly regulated industry like aerospace, automotive OEM, or medical device manufacturing? Is it possible to map Agile to the more formal requirements management needed in areas like system engineering and embedded software in such industries? How to leverage the benefits of Agile and still meet quality and implementation constraints? At Polarion, we’ve been helping companies large and small in a variety of industries do exactly that for quite some time.
In the rest of this article, I will share some practical tips that can help “Agile development” and “Enterprise development” to coexist.
Challenges Facing the Agile Enterprise
By “Enterprise”, we mean companies of any size, which face the necessity of compliance with governmental regulations and/or international/industry standards.The challenges include:
- How to map regulatory requirements to Agile “user stories”?
- How to track and verify requirements to prove compliance with regulations like ISO 26262, FDA 21 CFR Part 820 or IEC 62304, or standards like CMMI?
- How to map teams to components when you manage a broad spectrum of your product portfolio and variants of your product?
- How to map the quality assurance process with different test automation tools in the loop, and process all the issues in the same way?
- What if multiple stakeholders are involved in the decision making process and you need to track the approvals?
Clearly, meeting such challenges requires tools that go far beyond the simple task board and daily scrum. And for an ever-increasing number of companies, one single, unified solution is the answer: Polarion ALM.
5 Reasons to Deploy Polarion ALM for Enterprise Agile Development
#1: Agile Development and full-featured Requirements Management in 1 solution
No need to acquire, install, configure, and use different solutions for RM and Agile development. (Actually this would make the collaboration much more difficult!) Your full organization can use the same tool. Change is instantly propagated and visible to all the team members, and end-to-end traceability happens as a matter of course. Agile:
- Iteration support built in
- Epics, user stories, tasks, issues ready to use “out of box”
- Reporting: burn down charts with real prediction, visibility across projects; export to office formats or PDF
- Easy multi-level prioritization
Requirements Management:
- Easy document-like interface for writing specifications
- Artifact-aware specification documents
- Round-trip with Microsoft Office (off-line editing) facilitates collaboration with many stakeholders
- Branching and reuse for easy management of requirements (and test) variants
- Version management and baselining
#2: User Stories describe Increments, Requirements provide the big picture
User stories describe the scenario, and they might contain the acceptance criteria. But mostly – typically – they describe the increment. You cannot get the “big picture” from reading the user stories. User stories describe each tree, while requirements describe the forest. There are various reasons why a consistent product specification is needed:
- Industry regulations require everything documented.
- Product is so big that understanding the impact of the change is not possible just from studying the source code.
- Full Regression Exploratory tests are required, and they cannot be fully automated.
With Polarion, the Requirements specification is an outcome built either before (but why would one work on the full specification for all the user stories if they are not yet built?), or together with work on user stories. The requirements specification is an artifact that results from Agile teams working on the stories. The stories and the requirements are fully traceable to each other. This provides the possibility to easy reuse of stateless requirements when you start a variant of a component – one to be implemented in different environment, for example. You don’t need to go through each increment, you can learn from the overall product specification you already have.
#3: Easier to manage compliance with regulations and standards
If you are affected, then the benefits are clear:
- You need proof that changes were tested. With Polarion ALM, changes in source code are traceable to user stories or requirements, which in turn are traceable to test cases. Test cases (including test results) can be also imported from most of the 3rd party test automation tools.
- The solution provides features required by different standards. For example, electronic signatures for FDA CFR 21 Part 11.
- Polarion ALM provides out of the box project templates for various standards: ISO 26262, DO178c, and others.
If you don’t see your standard in the list of those we support, don’t worry. Standards-supporting project templates are implemented as extensions of the core product. It’ simply a matter of customizing artifact types and linking, or adding additional workflow functions and conditions built on top of the Polarion API. Polarion can support any process and standard. But you don’t need to wait for us to support a given standard. Our customers frequently customize our templates to suit their specific needs. And the Polarion community provides more templates and apps on our fast-growing extensions portal.
#4: Information reuse and variant management
We already touched this briefly, but let me highlight it again. Many of our customers are managing huge, complex products such as aircraft, high-speed trains, and medical devices. They have component that are built from components. Components are often reused with small modifications in different product lines. To manage such projects you need to create a proper project structure. This will help provide a clear understanding of the components you have, the variants of the components, and the status of the development. We have a common understanding with our customers that Agile still helps with such a complex problem. You just need to be open to adapting the process to the real needs. With Polarion you are able to keep the specification and increments separated, but still connected so that everything is just one click away. You can do planning and reporting across any number of projects. This gives you the full freedom to create a project structure that follows the logical structure of your development. For example:
- Dream Car
- Engine Controller
- Test Specifications
- Requirements Specifications
- Media Center
- Air Conditioning
- …
- Engine Controller
- DC 123 (Variant of Dream Car)
- Car Media v3
- Requirements (branched from requirements library)
- User stories related to media center requirements that are linked to requirements
- Manual test suites reused from the component library, fully synchronizable
- Air Conditioning
- Car Media v3
#5: Handles complexity, but still easy on users
Software has been changed a lot in the last 15 years. There’s been much buzz about usability, ease of use, user experience, etc. We fully agree that to have a successful deployment of any Enterprise Agile solution, it must be easy on users. But at the same time, it can’t be simpler that the job it needs to do. Therein lies a challenge for us. We constantly revisit existing product features looking ways to improve usability and make sure that our (and your) users feel good and work productively.
- We provide different tools for different roles, but we keep data the same, no synchronization. Example: business analyst is writing a specification document in a MS Word-like interface, and Agile product owner is mapping the granular requirements from this document using a tree-table object interface.
- We make it possible to provide different portal views for different roles. You can set up multiple views for, e.g., manager, developer, and stakeholder, and assign them to user roles. You can even switch from one view to another if you work in different roles. The view configuration makes sure that you are not overwhelmed with information you don’t need.
- We automate as much as we can by our workflow engine. If the “Detection” statusof an issue is changed from Normal to Expert, the priority is adjusted. If a requirement is changed, the test case is marked as suspected. If a user story is created, a task for technical documentation writers is created to document it, QA tasks are assigned, etc. Workflow is completely customizable… whatever you need to happen when something changes is easily set up.
Of course, taking the Enterprise to Agile development is something that reaches far beyond the scope of a short article. We would enjoy hearing from you about your experiences doing (or attempting) Agile in an enterprise/regulated environment.
FREE WEBINAR! Learn how Polarion ALM can help your enterprise be more Agile
- DATE: Thursday, August 1
- TIME #1: 10:00 am San Francisco, 1:00 pm New York, 19:00 Berlin SIGN UP…
- TIME #2: 10:00 am Berlin, Paris, 1:30 pm Mumbai SIGN UP…
About the Author Jiri Walek is Product Manager for Polarion ALM and Polarion REQUIREMENTS. He frequently works with enterprise customers to make sure that Polarion solutions deliver the features and capabilities they need most, and with Polarion’s own Agile R&D team to implement the best solution.
