7 Misconceptions of Enterprise Agile: What They Are and How to Avoid Them 7 Misconceptions of Enterprise Agile: What They Are and How to Avoid Them In virtually every industry, larger enterprises are struggling to adapt an agile approach that fits their environment. The root of the problem is that “pure” agile approaches don’t address enterprise realities, including: • • • Creating business cases with a well-defined scope to secure funding; Considering the broad range of stakeholders beyond the user, such as legal, marketing and operations; and, Accounting for audit and regulatory compliance regulations. This white paper helps IT and business leaders separate myth from reality, when it comes to making agile work in the enterprise. You’ll learn how to pragmatically and incrementally introduce Enterprise Agile practices that are right for you and your organization. Misconception #1) Enterprise Agile will free you from having to do requirements up front Enterprise Agile doesn’t mean a departure from requirements. Critical discovery and scoping up front is still required, though the level of detail can be scaled back to only what’s necessary to make business-level decisions. But make no mistake – there are critical elements that require explicit definition up-front, such as: • • • • • • • Determining and articulating business needs and objectives; Identifying business rules; Conducting stakeholder analysis; Capturing and analyzing business processes; Defining the scope of the solution; Creating and defending a business case; and Securing funding for the project. Enterprise Agile doesn’t mean a total departure from requirements. Critical discovery and scoping up front are still required. These elements provide information that the business needs to make key decisions and are the foundation for the requirements that will evolve during the course of the project. A Business Analyst in an Enterprise Agile implementation can provide just enough detail (and no less) to establish the scope and business needs ‘up-front’, while deferring the remaining detail for later iterations. This directly supports the agile principle of ‘simplicity,’ which is to maximize the amount of work not done. Misconception #2) You can define business needs with well-defined user stories User Stories User stories offer a very powerful way to look at the granular pieces of the application, but only from a user’s viewpoint. While crucial, it’s not the only perspective. Other stakeholders such as product managers, executives, finance staff, and those who will maintain, operate and support the application have different needs. And many of these needs manifest as non-functional requirements or constraints on the application. In addition, user stories lack ‘abstraction’ – the ability to provide the different views that the business needs, either by abstracting up many levels to get the ‘big picture’, or drilling down many levels into the details. User stories alone are limited in their ability to do this, compared to other approaches and techniques. © 2013 Blueprint Software Systems Inc. User stories are limited in their ability to provide both ‘big picture’ and granular details that many business stakeholders require. 1 7 Misconceptions of Enterprise Agile: What They Are and How to Avoid Them Misconception #3) User stories alone are adequate to support compliance and audit There are two primary reasons why user stories cannot be relied on to ensure that what is developed and deployed will meet or exceed audit and compliance requirements. First, user stories are temporary. Once implemented, they are discarded. Second, user stories lack any inherent traceability, meaning even if they were kept, there is no direct, easily identifiable link between user story content and specific application features. Audit and compliance – whether driven by internal or external forces – are reason enough to mandate persistent, traceable requirements in the enterprise. One effective way to accommodate this is with requirements technologies that deliver traceability and auditability in an automated fashion, ensuring proof of compliance – and visibility – at every stage of the project. User stories alone add little value to the enterprise’s ability to meet audit and compliance requirements. Misconception #4) Enterprise Agile will drastically change the way you manage your business There is a pervasive belief that managers must dramatically change the way they do business to accommodate Enterprise Agile development. But this isn’t true. Most management decisions are the same in Enterprise Agile as they would be using traditional approaches. Executives are still comparing project costs to value across a portfolio of projects and making decisions within that context. Project managers are still looking to measure progress against expected outcomes and reduce risk. Each level of management will simply use different data to make the same decisions. For example, a Project Manager may use a Work Breakdown Structure as the basis for making decisions for a traditional project. However, in an Enterprise Agile environment Product Backlog Burnup Charts will be used as the basis to make the same decisions. Most management decisions are the same in Enterprise Agile as they would be using traditional approaches Misconception #5) Business Analysis is an “organizational drag” Underlying the labeling of Business Analysis as an “organizational drag” is the misconception that business analysis equals requirements definition. And the error in thinking that ensues is: “If, with agile, we are to do away with requirements up front, then we can do away with business analysis as well.” Business Analysis isn’t simply the “gathering” of requirements, like the picking of berries off a bush. It involves understanding the business strategy and objectives; finding and eliciting ‘raw’ information from a multitude of sources at different levels; separating the relevant from the irrelevant; and, conducting analysis to deduce a set of business needs and have them validated. Only then can the requirements definition work begin. Throughout this critical work, important questions arise that must be answered: • • • • • • What workflow should be automated and what should remain as is? What is the business case to support the application being developed? What is the value to the business if we change this feature? What is the cost to the business if we don’t deliver the plan? How can we improve the way the business operates by automating this task, and at what cost? How will the application be rolled out and supported? Business analysis involves critical, strategic thinking to understand business needs, not simply the ‘gathering’ of requirements. The work of the Business Analyst is to define and manage requirements and understand their relationship and impact to the business before development resources are consumed. In Enterprise Agile, this work remains as important as ever. © 2013 Blueprint Software Systems Inc. 2 7 Misconceptions of Enterprise Agile: What They Are and How to Avoid Them Misconception #6) Business applications can be understood from code and tests alone A popular – but very dangerous – assumption is that application code and tests contain the complete breadth of information needed by stakeholders, – and in a form that everyone can consume. For example, a Program Manager who is considering a change to an application, would be at a loss to assess the business impacts of all changes if all she had to reference were thousands of tests. What’s more, code and tests don’t tell you ‘why’ certain applications, or components were implemented. Consider all the emails, meetings and important conversations where people explain ideas, answer questions, and make key decisions; none of these details are captured in code and tests. All that is captured is the result of all these decisions, embodied as code. This is where the value of business analysis and requirements work (and the tracing amongst the different views of this work) becomes plain to see. Code and tests alone aren’t helpful when it comes to understanding ‘why’ certain applications or components were implemented. Insight into the ‘why’ provides tremendous benefit to the enterprise. For example, requirements technology that captures a complete ‘history’ of not only the decisions, but also the basis for them, lets organizations reuse and repurpose requirements, minimize rework, and bring projects to completion faster by not having to re-live old conversations and debates. Misconception #7) Enterprise Agile will free you from having to use requirements software Enterprise Agile processes have the best chance of success when they are supported by a requirements application that integrates the agile development group and the rest of the business. Agile doesn’t equal “no requirements”. It should instead be supported by a purpose-built application configured specifically for agile environments. One that allows BAs to analyze the business and to evolve a set of system requirements iteratively over the course of the project, always in advance of ‘sprinting’ development teams. This way, it’s not just the Business Analyst who derives value from requirements tools, but also the business stakeholders and development team. Make Enterprise Agile WORK in Your Organization with Blueprint Look for a purpose-built requirements application configured specifically for Enterprise Agile environments. Don’t let these 7 misconceptions take you down the path toward a major agile failure. It’s time to make agile WORK for all stakeholders in your enterprise. Make project failures, missed deadlines, rework and overruns a thing of the past with Blueprint— requirements definition and management software that’s purpose built to help IT build what business needs. Contact Blueprint for a live demo today. About Blueprint Blueprint develops requirements definition and management (RDM) software purpose-built to resolve the errors and inefficiencies encountered in business application development today. Blueprint solves many of the time-consuming, costly, error-prone elements of defining requirements, resulting in better business applications with far less rework. Headquartered in Toronto, Blueprint has global sales, operations and partner presence. To learn more about Blueprint please visit http://www.blueprintsys.com. © 2013 Blueprint Software Systems Inc. Contact Blueprint 1-866-979-2583 [email protected] 3