Enterprise Agile Requirements

1,019 views

Published on

Summary:
- There are ways for Agile to work NOW on large, complex, distributed IT software projects
- ‘Requirements’ is one of the key areas to focus on to make Enterprise Agile work
- Layered approaches to let development teams be ‘agile’ while giving business what it needs.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,019
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
45
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • I first want to provide some context for the talkGartner releases regular hype cycleFor those unfamiliar – this tracks the evolution of any technology in terms of expectations over time… From < read axis >This is their 2012 report the 2013 report is out and things have moved along somewhat<click to highlight ‘project’> project-oriented agile … in other words agile as we’ve more traditionally known it on and where it has proven itselfMost if not all ISVs – companies like Google, Microsoft for example; And its making inroads into IT – certainly in small to mid-size projects within IT depts.<click to highlight ‘enterprise’> but it is struggling as IT organizations attempt to use it on larger, more complex, often distributed projects.This is all about ‘scaling agile up’ and Analysts call it “Enterprise-Class Agile” or Agile at ScaleAs you can see on the hype cycle .. Compared to ‘project-oriented agile’, enterprise-class agile is just at its beginnings of climbing the cycle<click to highlight legend> And – as indicated by triangle – will take a long time to transition through itIn other words they predict it will be some time before it becomes sorted out
  • <click to show agile box> Agile has many characteristics – certainly more than I’m going to list here According to XXXX there are 196 agile practices in factSome of the characteristics just to give a flavour .. <read>All of which are great principles when your focus is mainly on the end-user community, and the application being built.But something happens when you apply this to (a) larger more complex projects, and (b) they are IT projects, and (c) in regulated industriesAs the projects get large the agile reaction is to slice them into a set of smaller projects, but then we need governance across them to ensure they’re alignedWhen we deal with IT projects there is now generally a whole host of business constraints and considerations which often aren’t prevalent in ISV projectsWhen the industry is regulated there’s yet another layer of constraints – typically non-negotiable constraints that have real business implications for not meeting them – like fines or worse<click to show the business box>So in the large, complex IT project environment there are business realities such as <read> .. Just to name a fewagile practices don’t really provide any guidance for how to deal with these – but they must be dealt withSo business falls back to the traditional ways they’ve used to manage them These traditional ways are not aligned with agile practices and …<click to show gap>the result is a ‘clash’ or ‘gap’ with how the development team is workingFrom our experience and consultation with industry analysts, there are two aspects which are really starting to emerge as “keys” to solving this dilema <click to show Requirements>One is how you deal with REQUIREMENTS on enterprise-class application projectsRequirements touches on just about every one of these business issues and more in some way or anotherSo how you deal with them will clearly influence these outcomes <click to show EA >and the other is how you deal with ENTERPRISE ARCHITECTUREArchitecture determines the long term viability of the solution and therefore needs to have a long term perspective It is often at odds with development whose design evolves incrementally to support short term objectives as is found in agileEven having a great solution for both of these doesn’t eliminate the grinding gears – but one expects the situation would be dramatically better.Today’s talk focuses on the REQUIREMENTS part of this.
  • Requirements & Agile to some sounds like oil and vinegarSo first let me make a few points …There is nothing in the agile manifesto or principles or serious agile books that says “don’t do requirements”, quite the contrary in fact Agile is all about ‘doing what’s appropriate for the situation at hand’. For small, less complex projects detail requirements analysis and modeling is often not appropriate – so … don’t do itFor larger, complex, distributed, business-critical, often regulated IT projects … they are entirely appropriate and you need to do themWhen determining what is “appropriate” you may want to refer back to Lean development philosophy which is in a similar spirit to agileBasically in Lean it’s all about removing activities and practices that don’t contribute to the value-chain … in other words … that don’t add value.Choosing not to do the things that DO add value is plain irresponsible.So the real point I’m trying to make is that you shouldn’t think “requirements” are “anti-agile” because they aren’tAnd the need for more rigorous requirements and requirements practices INCREASES with the complexity of what you’re buildingThis is summarized in this very simple graph from Sherif Mansour of Atlassian – the makers of JIRA and a leading product company in the agile space.
  • As with anything that’s evolving there are a lot of opinions. Innovators find fast and efficient techniques that work in certain situations which is great.The issue comes when they attempt to scale to the Enterprise.Some of the issues experience when trying to use just Stories in larger, more complex, often distributed IT projects include …<click and read through the list>To build a truly enterprise-scale approach requires leveraging those project techniques but also needs some new thinking and innovation on top of that in order to address these types of issues.
  • Although Enterprise-class Agile is in its early stages of maturity – as I showed in hype cycle …Frameworks are already emergingTwo of the most prominent are … Disciplined Agile Development (or “DAD”) by Scott Ambler – former chief Methodologist for Agile & Lean at IBM and Scaled Agile Framework (or “SAFe”) by Dean LeffingwellBoth have significant web sites and communities around this and both have Books on their frameworks with those namesBoth of these frameworks are ways to make agile work at scale – in an IT group – within a Business environment.Just to pick one to discuss briefly .. Here is the picture for Scaled Agile FrameworkIt is a three layer framework ..The TEAM layer will be pretty familiar with those who recognize the SCRUM agile approachThe other two layers focus on managing and aligning the work beneath it – first at the Program level, and then at the Portfolio levelWhen we speak of Requirements … or the ‘definitions’ of what we’re building … there is ‘definition work and artifacts at every level, each being derived from the one above.We have a Portfolio backlog that feeds the Program Backlog one layer down that feeds the Team Backlogs beneath that.In terms of requirements .. The things we’re dealing with in these backlogs can be Epics (which evolve out of Themes), and then Features, and Stories, and these can be elaborated by expressive artifacts like use cases, UI mockups, storyboards, and more.Again … reaching out and leveraging whatever provides value … whatever makes it more clear about what we need built.
  • When you look at the Scaled Agile Framework …If we just focus on the items used to define what’s to be built – in other words ‘requirements information’ …..It describes those things using a UML meta-model shown hereNot everyone is familiar with reading UML so ………
  • This conceptual diagram may be a bit easier. Not necessarily as accurate – but it makes the point.At a business level we have to make high-level decisions on what areas to invest in and these are called “Themes”< 5 clicks to bring in the stack >They then get decomposed into chunks of capability called Epics, which are then broken into Features, and then into user stories, and ultimately tasks owned and performed by developers<click to bring in the non functional>All the way down this stack there might be non-functional requirements that need to be considered and met by the solution … these can be at any level<click to bring in ‘business analysis’ artifacts>But also … there might be any combination of other kinds of artifacts like - business processes or information models to help analyze the problem being solved<click to bring in the system level artifacts> - or things like use cases, uimockups, storyboards, and other things that help analyze and specify the solutionThese things can be … - used at any level as needed<click to bring in the title> - can be used to either provide higher-level context (for example for a collection of features) - OR can be used to elaborate and provide more clarity for any of the levels
  • Just to show you a couple of examplesWhen you get into very large, complex projects a backlog of user stories tends not to instill a high-level, overall picture of what the system is supposed to doThis get’s back to one of the deficiencies I mentioned at the beginning of user stories lacking an ability to abstract upUse Cases happen to be a great mechanism for abstracting up<click to bring in left pic>They can be used to express how the system is to function at a higher level and user stories can be derived from them<click to bring in left title>There’s a few publications talking about the technique on how to do this It is based on one or more use case scenarios being the basis for a user story essentially<click to bring in right pic>Another example is to use use-cases as a way to provide additional detail and elaborate on any of the more complex user stories<click to bring in right title>In this way they can be used to help clarify reduce miscommunication, and often provide an early indication of whether a story is too big and needs to be splitBOTH of these by the way are consistent with the Scaled Agile Framework by LeffingwellIn his framework you can leverage use cases in concert with Epics as well in a simular fashion.
  • To give you a quick real-world example of what one of our customers is doing ….They derive User Stories from Epics, and then Tasks from the Stories as you might expect But then <click to show use case>they have MANDATED that every user story must have a use-case. I wouldn’t necessarily mandate it, but just telling you what they’ve done.Then <click to show optional box> OPTIONALLY if it helps, <click to show UI mockups> they can create UI mockups, <click to show Storyboard> string those into one or more storyboards, or <click to show simulation> run Visual Simulations based on all thisOur Product “Blueprint” allows them to do all of this and relate it all together with traceabilityFinally … they use another feature of Blueprint – <click>its ability to automatically generate ALL the tests from the use cases.This essentially becomes for them the acceptance criteria.
  • Based on experience of many customers – like the one I just showed you – Blueprint has created something called Blueprint for Enterprise AgileIt is an approach specifically for how to do requirements on an enterprise-scale Agile projectIt is totally consistent with DAD framework and the SAFe framework – those frameworks talk about much more than just requirements,and for that matter it is compatible with Scrum and other agile approaches as wellIn very broad terms .. It describes how to leverage requirements to give Business the things it needs … compliance, business cases, release planning, and so on … While at the same time allowing the development team to be ‘agile’.If you’re interested – drop by our booth
  • Finally I thought I’d leave you with an example.This example is actually … ourselves.We at Blueprint build and sell a software product. And the way we do requirements is comparable to what I’ve been talking about.Our process could best be described as agile but with a layer of more traditional governance wrapped around itSome call it ScrumFall<click to bring in first gates>We currently have a gated process with go / no-go Gates that require the buy-in of different stakeholders before proceedingUp front there are three gates we go through that end up essentially providing … - the scope of the upcoming release - a base set of ‘commits’ or ‘guarantees’ by the team called ‘base scope’ – which allows the business to carry on with confidence - an extended set of prioritized features that are not committed to but done on a best efforts basis<click to bring in Dev Start>Then the dev team proceeds in a pretty classic SCRUM process. During each iteration is when the stories are elaborated as needed. Sometimes one before but try to keep as tight as possible so as not to waste timeThe last sprint – sometimes two if big release – reserved for stabilization to hit quality levels<click to bring in last gates>Toward the end there is a series of gates used as part of our managed release process to take the product to marketJust as a point of reference, this particular process is somewhat analogous to DAD
  • We use Blueprint for defining what needs to be built, and Microsoft TFS for managing the implementation of that Instead of TFS substitute Rally, JIRA/Greenhopper, VersionOne, ….In our agile process the work is driven by stories .. So everything built came from a story. They are defined initially in Blueprint, but the backlog is held and managed in TFSAs needed and as appropriate, we augment stories with use cases (high or low), mockups, storyboards. We leverage simulations to review and communicate.Where we have use cases we will generate tests<click to bring in arrows>All this is transitioned to TFS. When things change, it intelligently updates.As mentioned TFS then used by the teams to manage the work during sprints.Up in Blueprint we also keep our long term roadmap content, larger product backlog of features for future releases, baselines for all the gates I mentioned, For any research or experimentation we have those definitions in Blueprint as well. Some of this may transition into the main dev stream as appropriateIn other words Blueprint holds our more strategic and longer term vision which is persistent over time so we can see where we’ve been and where we’re goingTFS is our ‘tactical’ engine for running the current release implementation.
  • Here is a shot of Blueprint … in fact this shot is of the definitions for our actual product<click to highlight artifact type list>A quick glance down the types of artifacts you can see epics & stories … but also use cases, UI Mockups, storyboards, and so on<click to highlight project structure list>A quick glance down the structure on the left you can see ‘Releases’, ‘platform and admin’, our functional areas (editors, simulation, etc.) - also enhancement requests where we keep a summary in here - and all of our baselines and reviews.
  • Here is just a quick shot to show actually working on something .. In this case a user-interface mockup illustrating the desired feature
  • < read >
  • Enterprise Agile Requirements

    1. 1. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved.
    2. 2. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved.Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Enterprise Agile Requirements 2
    3. 3. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Enterprise-Class or Agile-at-Scale 3
    4. 4. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. REQUIREMENTS ARCHITECTURE Business Clashing with Development 4 Business Need • Regulatory Compliance and Audit • Business Case and Funding • Portfolio Prioritization and Management • Release Planning • Requirements persistence (remembering ‘why’) • Abstracting solution definition • Change Impact and Costing Agile Practice • Focus forward • Just enough detail • Stories are transient - answers are in the code • Limit work in progress – maximize the work not done • Fast pace, maximize delivery, minimize ceremony Gap
    5. 5. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Requirements in Agile 5 - Sherif Mansour, Product Guy, Atlassian Confluence
    6. 6. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. The Problem with “User Stories Only” in larger, complex, distributed IT projects • User stories facilitate developer work and are transient (discarded when done) • There’s little or no organized abstraction. • No auditable tracing to higher level business objectives/needs/rules .. • No “analyzing of the business” • No good solution for portfolio/program-level needs (prioritizing, tracking, managing releases, …) • No record of ‘why’ once the work is done • Some people believe they are not needed 6
    7. 7. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Frameworks are evolving … 7
    8. 8. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Requirements Taxonomy 8
    9. 9. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Business Process Information Model problem analysis Requirements Taxonomy 9 FeatureTheme Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement Non-Functional Requirement constrain constrain constrain Use Case UI Mockups UI Mockups UI Mockups Storyboard Simulation Other Forms solution analysis / specification FeatureFeatureFeatureEpicFeatureFeatureFeatureUser Story FeatureFeatureFeatureFeatureFeatureFeature FeatureFeatureEpic FeatureFeatureFeatureEpicFeatureFeatureFeatureTasks Provides Context or Elaboration At any level
    10. 10. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Enterprise Agile Requirements – Examples: 10 Tasks User Stories User Stories User Stories Tasks Tasks Tasks Tasks Tasks Tasks Use Case • Used to provide high-level perspective • Scenario(s) basis for stories • Used to elaborate on stories • Provided as additional info to team Tasks User Stories User Stories User Stories Tasks Tasks Tasks Tasks Tasks Tasks Use Case
    11. 11. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. optional Enterprise Agile Requirements – Examples: 11 Tasks Epics User Stories User Stories User Stories Tasks Tasks Tasks Tasks Tasks Tasks UI Mockups UI Mockups UI Mockups UI Mockups SimulationStoryboard Use Case mandatory Tests
    12. 12. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Blueprint for Enterprise Agile 12 Product Owner; Agile ALM; Transient Business Analyst; Blueprint; Persistent Discovery & Scoping Iteration 0 Iteration 1 Analyze Business, Stakeholder Input, Define Scope, Business Case, Funding Product Backlog New Requirements Update, Add, Refine Groom Burn Down Initial Product Backlog Demo Iteration n Requirements Product Backlog New Requirements Groom Burn Down Demo Plan/Create Plan/Create Update, Add, Refine Update, Add, Refine Update, Add, Refine Requirements Initial Requirements Iteration Backlog Iteration Backlog Update Update Update, Add, Refine
    13. 13. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Case Example … 13 Concept Interlock Feasibility Interlock Plan Interlock Release Interlock ~9 weeks before Dev start ~6W before Dev start ~3W before Dev start ~3W before RTS PM Lead Assigned – Each Release has a PM Lead PM Lead Presents Base, Extended Scope items Development/QA Lead Assigned Leads Present Status and release recommendation Executive Team Product Management Team Chief Architect Quality Lead SE Lead Services Lead Executive Team Product Management Team Chief Architect Quality Lead SE Lead Services Lead Executive Team Executive Team Chief Architect Quality Lead Concept Interlock ~9W Feasibility Interlock ~6W Plan Interlock ~3W Feature Freeze RTS – 6W Release Interlock RTS - 3W RTS GA RTS + 1W Code Freeze RTS – 3W Dev Start 18 weeks Gated Process
    14. 14. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. BLUEPRINT Case Example 14 Epics User Stories User Stories User Stories UI Mockups UI Mockups UI Mockups UI Mockups Simulation Storyboard Use Case Tests MICROSOFT TEAM FOUNDATION SERVER
    15. 15. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Case Example 15
    16. 16. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. Case Example 16
    17. 17. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. In Summary … • There are ways for Agile to work NOW on large, complex, distributed IT software projects • Solutions: DAD; SAFe • ‘Requirements’ is one of the key areas to focus on to make Enterprise Agile work • Solutions: Blueprint for Enterprise Agile (within DAD, SAFe, …) • Layered approaches to let development teams be ‘agile’ while giving business what it needs. 17
    18. 18. Copyright © 2013 Blueprint Software Systems Inc. All Rights Reserved. 18 Contact Us Call us and speak with a Business Development Specialist. +1-866-979-2583 (BLUE) / info@blueprintsys.com Video Product Overview Watch the informative video demonstration of Blueprint in action. Watch Product Demo Register Live Demo Request a complimentary consultation with a Blueprint representative. Live Demo Request

    ×