March 2009 Azrug Everything Old


Published on

Recycling Old Tools to New Uses…

Some say everything old is new again. This is true with requirements management regardless of the type of project methodology you adopt. You have to identify them, gather them, prioritize them, and essentially manage them. The new agile methods like SCRUM require that for your projects you define, collect and manage your requirements just as you did before, but in new ways and new formats.
So why not use proven tools and methods to do so? I will examine the benefits and shortcomings of managing requirements for an agile project method (specifically SCRUM) utilizing the Rational Requisite Pro tool. We will look at the opportunity to manage burn down lists and user stories as two of the important SCRUM process elements, and see how this “Old” tool can support “New” tricks.

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Note the emphasis on “Valuable Software” as a delivery objective Welcome changing requirements requires that early in a project you delay decision making by exploring the problem and the potential solutions rather than drilling down into a solution quickly. It is a balancing act. By attempting to attack the “breath” of a system problem rather than the “depth” you can defer making too many detailed decisions and mitigating the risk of locking into an incorrect or useless solution Another strategy – iterative delivery – get a quick feedback loop going through deliveries. Find out if you can “fail fast” if you are going to do so.
  • So, what motivates you? Face to face – how do we do that if we have geographically distributed clients? What communications points do you have, and how often do you use them? OK, so here’s a challenge – how long has this project been underway, and how often have you delivered software by this point in time?
  • How often do you visit with your clients? Again, what communications points or vehicles do you have and with what frequency or regularity do you use them? (ICG example – visit once a day whether I liked it or not) In order to maintain a constant pace indefinitely, you must practice delivery and measure “ velocity ” (A SCRUM TERM) to determine what you are capable of as a team. How do you measure “ velocity ”? # of requirements completed, Function Points, Use Cases delivered, # of defects removed, high risk requirements accomplished? Technical excellence – Risk based Architecture centered design and delivery – make a resilient and quality architecture implementation. Barry Beohm recommends all tasks not related to analysis and coding are overhead and waste… Deliver Valuable, Workable software to the customer.
  • I ALWAYS recommend “be Practical and Pragmatic” Keep it Simple (KISS) – Don’t make a [problem more complex than it needs to be. How do you decide that? A Zen-like analogy – “how long does a piece of sting need to be?” Long enough to do the job – no longer.
  • So, is our methodology agile or not? Let’s review the point again that there are actually a lot of “Agile” methodologies out there. Agile is a point of view, a means of organizing effort around certain principles and driving work based on those principles. What work gets driven, is hat we understand as a “Methodology”
  • Summary: Many organizations struggle with how to capture and communicate requirements. While documents are still dominant, more agile approaches favor discussions and prototyping. In this presentation, an approach for starting with the simple "agile" backlog, and then applying other techniques as needed, is outlined and explained. Criteria for choosing techniques and strategies for blending techniques are highlighted. Examples and demonstrations will be used to illustrate the approach.  Abstract: Attendees will come away with strategies for effectively blending a variety of different approaches to capturing and communicating requirements, including backlog entires (change requests, work items, and even defects), declarative requirements, use cases and scenarios, prototypes, business rules, and even test cases. An additional dimension, the level of detail to which the requirements need to be described, is also explored. In addition to documenting the requirements, strategies for reviewing and approving the requirements in an iterative lifecycle are discussed. Topics discussed include: - Capturing business needs and desired outcomes - Using the Backlog to capture requirements - The role of scenarios and the Use Case Model - The role of sketching and visualization to elicit and capture requirements - Capturing business rules - Using a domain model to capture data requirements - The role of declarative requirements - When and how to write fully-described use-case specifications - Working with requirements iteratively - Reviewing requirements and gaining agreement
  • March 2009 Azrug Everything Old

    1. 1. Everything Old is New Again… A look at repurposing existing tools to new uses… June 22, 2009
    2. 2. Agenda <ul><li>Some level setting, What does “Agile” mean? </li></ul><ul><li>A focus on SCRUM and its elements </li></ul><ul><li>Using RequisitePro for SCRUM Elements </li></ul><ul><li>What worked well… </li></ul><ul><li>What didn’t work so well </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    3. 3. What is Agile? <ul><li>Methods and Techniques </li></ul><ul><li>Organizational Keys </li></ul><ul><li>How do we compare? </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    4. 4. Agile is… <ul><li>A State of Mind … </li></ul><ul><li>A concept – a set of techniques </li></ul><ul><ul><li>Social engineering </li></ul></ul><ul><ul><li>Project Principles </li></ul></ul><ul><ul><li>Tactics for accomplishing speed and agility </li></ul></ul><ul><li>Versus Methodologies that promote Agile techniques </li></ul><ul><ul><li>SCRUM </li></ul></ul><ul><ul><li>Crystal </li></ul></ul><ul><ul><li>OPENUP </li></ul></ul><ul><ul><li>RUP / AUP </li></ul></ul><ul><ul><li>LEAN Development </li></ul></ul><ul><ul><li>DSDM </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    5. 5. Agile is not… <ul><li>“ Code and fix” </li></ul><ul><li>An excuse not to document </li></ul><ul><li>An excuse not to model </li></ul><ul><li>An excuse to short-change quality </li></ul><ul><li>An excuse to ignore enterprise concerns (Architecture / Governance) </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    6. 6. M anifesto for Agile Software Development <ul><li>We are uncovering better ways of developing software by doing it and helping others do it. </li></ul><ul><li>Through this work we have come to value: </li></ul><ul><ul><li>Individuals and interactions over processes and tools </li></ul></ul><ul><ul><li>Working software over comprehensive documentation </li></ul></ul><ul><ul><li>Customer collaboration over contract negotiation </li></ul></ul><ul><ul><li>Responding to change over following a plan </li></ul></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul><ul><li>(source: </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    7. 7. Principles Behind the Agile Manifesto <ul><li>We follow these principles: </li></ul><ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software . </li></ul><ul><li>Welcome changing requirements , even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    8. 8. Principles Behind the Agile Manifesto (2) <ul><li>Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation . </li></ul><ul><li>Working software is the primary measure of progress. </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    9. 9. Principles Behind the Agile Manifesto (3) <ul><li>Business people and developers must work together daily throughout the project. </li></ul><ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely . </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    10. 10. Principles Behind the Agile Manifesto (4) <ul><li>Simplicity--the art of maximizing the amount of work not done--is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    11. 11. Is Our Methodology Agile? <ul><li>How do you measure up to the principles in the Manifesto? </li></ul><ul><li>How many of the practices do you regularly engage in? </li></ul><ul><li>Are we Agile? </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    12. 12. MYTH: Agile is a methodology <ul><li>Lots of people claim “We‘re doing Agile!” </li></ul><ul><li>What they (hopefully) mean is we’re using agile practices in our project and we’re following “ fill in the blank with your favorite ” methodology </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    13. 13. Teamwork Ground rules... <ul><li>Think Iteratively </li></ul><ul><li>Compromise </li></ul><ul><li>Collaborate </li></ul><ul><li>Add Value </li></ul><ul><li>Negotiate </li></ul><ul><li>Be Results Oriented </li></ul><ul><li>Help Stop the Churn </li></ul><ul><li>Drive for Decisions </li></ul><ul><li>Take Ownership </li></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    14. 14. SCRUM Introduction <ul><li>Scrum is an empirical Agile project management framework used to deliver increments of high value to the customer iteratively </li></ul><ul><li>Scrum relies on self organizing, empowered teams to deliver the product increments </li></ul><ul><ul><li>It also relies on a customer, or Product Owner, to provide a team with a list of desired features using business value as the priority mechanism. </li></ul></ul><ul><li>A Scrum is a mechanism in the sport of rugby for getting an out-of-play ball back into play </li></ul><ul><ul><li>The term was adopted in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi to describe hyper-productive development. </li></ul></ul><ul><ul><li>Jeff Sutherland developed the Scrum process in 1993 while working at the Easel Corporation </li></ul></ul><ul><ul><li>Ken Schwaber formalized the process in the first published paper on Scrum at OOPSLA 1995 </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    15. 15. Scrum Roles, Artifacts and Meetings <ul><li>Scrum defines roles, artifacts and meetings that provide a framework for the high value increments to be developed. </li></ul><ul><li>Roles </li></ul><ul><ul><li>There are three roles in a Scrum project: </li></ul></ul><ul><ul><ul><li>The Product Owner (or customer) owns the product and prioritizes the list of desired features. </li></ul></ul></ul><ul><ul><ul><li>The ScrumMaster owns the process and ensures that teams remain unhindered and productive. </li></ul></ul></ul><ul><ul><ul><li>The cross-functional Team self organize to build the product. </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    16. 16. Scrum Roles, Artifacts and Meetings(2) <ul><li>Artifacts </li></ul><ul><ul><li>Scrum defines three artifacts that the roles interact with during the life of the project: </li></ul></ul><ul><ul><ul><li>The Product Backlog is a prioritized list of desired features. </li></ul></ul></ul><ul><ul><ul><li>The Sprint Backlog is a prioritized list of tasks that the team have identified for the current Sprint (iteration). </li></ul></ul></ul><ul><ul><ul><li>The Increment of Product Functionality which is delivered at the end of each Sprint. </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    17. 17. Scrum Roles, Artifacts and Meetings(3) <ul><li>Meetings </li></ul><ul><ul><li>There are four meetings, or collaboration points, that are used during each Sprint: </li></ul></ul><ul><ul><ul><li>Sprint Planning allows the team to elect what work they will be taking on for the Sprint. </li></ul></ul></ul><ul><ul><ul><li>The Daily Scrum allows the team to review the status of the Sprint and adapt to discoveries. </li></ul></ul></ul><ul><ul><ul><li>The Sprint Review gives the Team an opportunity to show the Product Owner the increment of product functionality. </li></ul></ul></ul><ul><ul><ul><li>The Sprint Retrospective allows the team to provide feedback and adapt the process. </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    18. 18. The SCRUM Process… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    19. 19. Epics to User Stories… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    20. 20. SCRUM Team Product Backlog 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    21. 21. SCRUM Team Sprint Backlog 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    22. 22. SCRUM Team Sprint Backlog(2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    23. 23. How the Sprint Backlog is Normally Conveyed… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    24. 24. How the Sprint Backlog is Normally Conveyed… (2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    25. 25. How the Sprint Backlog is Normally Conveyed… (2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    26. 26. So what works… <ul><li>Human Glue </li></ul><ul><ul><li>Spreadsheets don’t match boards </li></ul></ul><ul><ul><li>Spreadsheets don’t match each other </li></ul></ul><ul><ul><li>Traceability not provable </li></ul></ul><ul><ul><li>Yet… the right work gets done </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    27. 27. Translate to Requisite Pro… <ul><li>Here is a Demonstration of usage… </li></ul><ul><ul><li>Lets look at the Epics that contribute to the Product Backlog </li></ul></ul><ul><ul><li>Here’s the Product Backlog </li></ul></ul><ul><ul><li>Now, Lets look at the Sprint Backlog </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    28. 28. Things that Work Well <ul><li>Traceability </li></ul><ul><ul><li>Business Process to Epics </li></ul></ul><ul><ul><ul><li>Epics to User Stories </li></ul></ul></ul><ul><ul><ul><ul><li>User Stories to Test First Design Tests </li></ul></ul></ul></ul><ul><li>Prioritizing </li></ul><ul><ul><li>Business can plan ahead sprints </li></ul></ul><ul><ul><li>Mix Match Velocity Points </li></ul></ul><ul><ul><ul><li>(Velocity – the speed at which the team builds) </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    29. 29. Things that Work Well(2) <ul><li>Support for Daily Stand-ups </li></ul><ul><ul><li>Note “progress” on SPRINT mini-SDM </li></ul></ul><ul><ul><ul><li>Waiting </li></ul></ul></ul><ul><ul><ul><li>Development </li></ul></ul></ul><ul><ul><ul><li>QA </li></ul></ul></ul><ul><ul><ul><li>Done </li></ul></ul></ul><ul><li>Quick response to changing project priorities </li></ul><ul><ul><li>Simple changes to Progress or Sprint or Backlog values by anyone </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    30. 30. Things that Work Well (3) <ul><li>Communication with Business Customer </li></ul><ul><ul><li>Metrics reports </li></ul></ul><ul><ul><li>ReqWeb access for remote users </li></ul></ul><ul><ul><li>Access to what’s happening on a sprint </li></ul></ul><ul><ul><li>Opportunity to add Functional level tests </li></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    31. 31. Things That Don’t Work Well <ul><li>Calculating Stuff </li></ul><ul><ul><li>Team Velocity </li></ul></ul><ul><ul><ul><li>No way to facilitate this inside the product skin </li></ul></ul></ul><ul><ul><ul><li>Could be an interesting programmed add-on </li></ul></ul></ul><ul><ul><li>Traceability </li></ul></ul><ul><ul><ul><li>Is still tedious </li></ul></ul></ul><ul><ul><ul><li>Still only links two levels together </li></ul></ul></ul><ul><ul><ul><li>Leg bone connected to thigh bone reports difficult </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    32. 32. Questions <ul><ul><li>If you need to reach me or have questions: </li></ul></ul><ul><ul><ul><li>Tom Weinberger </li></ul></ul></ul><ul><ul><ul><ul><li>The Nimblestar Group, Inc </li></ul></ul></ul></ul><ul><ul><ul><ul><li> </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Tel. 312-805-0470 Fax. 815-838-9896 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul></ul><ul><ul><ul><ul><li>[email_address] </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Come join me on LinkedIn </li></ul></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    33. 33. FYI – If you are attending the 2009 Rational Software Conference… <ul><ul><li>Kurt Bittner (CTO of Ivar Jacobson, Consulting, Inc.) and I are giving a joint presentation: </li></ul></ul><ul><ul><ul><li>“ Software Development Worst Practices: Cautionary Tales from the Front” </li></ul></ul></ul><ul><ul><ul><li>Please join us for a slightly humorous look at Worst Practices – kind of a take off on Tom Wolfe’s book “The Right Stuff” – Well, we are going to cover “The Wrong Stuff”! </li></ul></ul></ul>06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
    34. 34. Software Development “Worst Practices”: Cautionary Tales From the Front <ul><li>Kurt Bittner </li></ul><ul><li>CTO - Americas, Ivar Jacobson International </li></ul><ul><li>[email_address] </li></ul><ul><li>Tom Weinberger </li></ul><ul><li>General Manager, The Nimblestar Group, Inc </li></ul><ul><li>[email_address] </li></ul>IBM Rational Software Conference 2009 NPPM01 NPPM01 © 2009 IBM Corporation