Well, after more emails than I care to think about, and after being tempted to give up on the entire concept, Agile Software Requirements: Lean Requirements Practices for Team, Programs, and the Enterprise is now (again) available in native Kindle format from Amazon.
Order native Kindle format from Amazon
Thanks to Chris Guzikowski, the Addison-Wesley team and Amazon for finally making this happen.
Of course, it is also available in Ebook format from InformIT.
While I was thinking about my then-upcoming presentation entitled Five Keys to Building the Lean Agile Enterprise for Agile 2011, I was contacted by Joe Dager, owner of Business901, about doing a podcast on essentially the same topic. Joe did an excellent job of interviewing me and framing the discussion in pragmatic terms that are directly relevant to most every leader, manager and executive contemplating, or in the midst of, a substantial Lean|Agile enterprise software transformation. A reader just pointed me to the podcast which is posted here. (The title, Lean Agile Software Train Description, is a little different, but the content is even broader than the Agile 2011 presentation.)
This is a pretty far ranging discussion, and on review, I thing it does a fair job of covering a number of critical topics, including:
➵Not Everything is a User Story: Scalable Agile Requirements
➵Think Agile Programs, Not Just Agile Teams: The Agile Release Train and Program Kickstart
➵Enterprise Systems Require Intentional Architecture: Rearchitecting with Flow
➵Portfolio Management Must be Agile Too: Addressing Legacy Mindsets and the Agile PMO
➵Your Enterprise Can Be No Leaner Than the Executives Thinking: Lean Education and The Big Picture
as well as a discussion of lessons learned in a number of larger scale transformations.
I’m happy to finally announce that Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, is again available in ebook form from InformIT.
With the purchase ($31.99 at this writing) you can download it in PDF and EPUB format. PDF files work just fine on Mac and PC, and the EPUB format is compatible with a number of mobile readers including iBooks on Ipad. This is the version I use as it provides adjustable fonts and decent navigation.
The watermarked PDF files are also compatible with the “Latest Generation” Kindle, 2nd Generation Kindle, or Kindle DX.
Note on the native Kindle ebook format: unfortunately, we are still working with Amazon to restore the native Kindle version. There were problems with the large graphics in the book which we are still attempting to resolve. In the meantime, however, there is a converter available at http://www.informit.com/store/ebook-formats/kindle.aspx which you can use to convert the EPUB or PDF files to a native Kindle format. (However, I haven’t tried it, as I gave up my Kindle for my Ipad sometime back).
I was recently interviewed by Yvette Francine of the on line magazine techtarget.com with respect to some questions regarding Agile Software Requirements. She asked some interesting questions about the book, the method and some opinions on related topics. Part I of the interview can be found here.
Background: In this series of posts, I’ve been using medical device development (as Regulated by U.S. FDA via CFR 820.30 and international standard IEC62304) as an exemplar for suggesting ways to develop high quality software in regulated (and other high assurance, high economic cost of failure) environments in an agile manner. This series is sponsored, in part, by Rally Software Development, with special thanks to Craig Langenfeld for his contribution.
=====================================
A note on V&V: As we described in earlier posts, while there is no perfect discriminator between verification and validation activities, in agile verification (…providing objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase) occurs primarily and continuously during the course of each iteration. Validation (… confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled) typically occurs primarily in the course of special iterations dedicated to this purpose. Generally, the testing of nonfunctional requirements occurs during these special iterations, and it is therefore probably sensible to think of this testing as a primarily a validation activity.
=====================================
The first 90% of the software takes 90% of the development time. The remaining 10% of the code takes up the other 90% of the time.
— Tom Cargill, Bell Labs
In the last post, we described testing the features described in the Product Requirements Document as an important verification activity, which is largely independent of the testing we perform for the individual stories. In this post, we’ll describe the other dimension of product requirements the nonfunctional requirements (which are typically also contained in the PRD) that describe the “ilities” of the subject device or system. If we are not careful, these special “quality requirements” will take up the “other 90%” of our total development time.
In Agile Software Requirements, I described nonfunctional requirements, and their even uglier stepsister, design constraints, as the “URPS” part of our FURPS (Functionality, Usability, Reliability, Performance and Supportability) acronym and noted the following discriminators:
| Functional requirements. | Express how the system interacts with its users —its inputs, its outputs, the functions and features it provides |
| Nonfunctional requirements | Criteria used to judge the operation or qualities of a system |
| Design Constraints | Restrictions on the design of a system, or the process by which a system is developed, but that must be fulfilled to meet technical, business, or contractual obligations |
It can be useful to think about the major categories of NFRs via the “URPS” acronym:
Usability – Includes elements such as expected training times, task times, number of control activities required to accomplish a function, help systems, compliance with usability standards, usability safety features
Reliability – includes such things as availability, mean time between failures (MTBF), mean time to repair (MTTR), accuracy, precision, security, safety and override features
Performance – response time, throughput, capacity, scalability, degradation modes, , resource utilization.
Supportability (Maintainability) – ability of the software to be easily modified to accommodate planned enhancements and repairs
Note: A more complete list of potential nonfunctional requirement considerations can be found in my book, Agile Software Requirements and even on Wikipedia (http://en.wikipedia.org/wiki/Non-functional_requirement.)
Design Constraints can also be particularly relevant in the development of high assurance systems. These can refer to items such as: follow all internal processes per the companies Quality Management System, and use only components which themselves have been validated, adherence to comprehensive safety standards such as IEC 60601-1 (which covers generic safety requirements for medical devices including a list of hazards and their tolerable limit of risk) as well as a potentially long list of other such requirements.
No matter their nature or source, these requirements are just as critical as the functional requirements we’ve described in user stories and features, for if a system isn’t reliable (become unavailable on occasion) or marketable (fails to meet some regulatory requirement) or isn’t as accurate as the patient/user requires, then, agile or not, we will fail just as badly as if we forgot some critical functional requirement.
As seen in the requirements metamodel below, we’ve modeled them a little differently than we did features and user stories, which from an agile implementation perspective were all modeled as transient backlog items.
This is because the implementation of features and stories tend to somewhat transient in nature, and (subject to automated testing and verification infrastructure), you can discover-them, implement-them, auto-test-them and “almost-forget-them”.
Such is rarely the case with NFRS as many of these must be revisited at every increment to make sure the system — with all its new features — still meets this set of imposed quality requirements.
To assure that the system works as intended, and is illustrated by the metamodel:
Nonfunctional requirements and systems qualities tests
most identified NFRs must typically (0..*) be associated with some “System Qualities Test” which is used to validate that the system is still in compliance with that specific NFR. (And perhaps some system qualities tests may test multiple NFRS (1..*))
These types of requirements are indeed “special” in the way we need to think about them, for example:
As we can see, the testing of many NFRs is simply not automatable, and therefore some amount of manual NFR testing is left to the validation sprint. If the items can be automated, the teams should surely do so, but either way, comprehensive regression testing (and documentation of results) of these “system qualities” is an integral part of the validation process.
In this post, we’ve described how full regression testing of a systems nonfunctional (quality) requirements is a validation activity typically required at each increment (PSI) boundary, and how some of this effort will likely be manual. To this point, we’ve described most of the testing activities required for building systems of high assurance. In the next post, we’ll take an even broader look at agile testing practices in the context of high assurance development.
Phew! As with any good agile release, where the availability of incremental and valuable content precedes the big event, the actual release of my new book, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, feels a bit anti-climatic. However, after a period of — well basically it felt like forever — the book is now available on technical bookshelves across the country. And as with every good release, one is always reminded to take a pause to celebrate, and especially to thank the contributors.
Well, that was the pause. Now, I sure hope some people read it.
To (hopefully) initiate a bit of that, and for overview purposes, here is some of the front matter that describes the book.
I was walking through some blog posts in the requirements category today looking for a later version of the full “agile requirements metamodel”. (Some readers commented that “enterprise backlog model” might be a better descriptor, and I tend to agree). The model has evolved and been refined based on peer reviewer feedback (thanks Gabor and others….) of Agile Software Requirements. Evidently I didn’t track that evolution here on the blog, so here is the updated graphic of the final, (at least for this book version) full model as it will appear in the appendix of the book.
Full agile requirements metamodel (Enterprise backlog model)
Note: This metamodel is also integral to the work I’m currently doing with Craig Langenfeld on applying agile development to high assurance systems, so I’m tagging this post to that category as well.
While the book Agile Software Requirements: Lean requirements Practices for Teams, Programs and The Enterprise, is still going though final production edits and artwork revisions at Addison-Wesley, it is now available for pre-order on Amazon. It should be available for shipment in the next 60 days.
Here’s a few praise quotes from the inside pages.
“Dean captures the essence of Agile in entirety, all the way from the discrete user story in the “trenches” to complex software portfolios at the enterprise level. The narrative balances software engineering theory with pragmatic implementation aspects in an easy to understand manner. It is a book that demands to be read in a single sitting.” —Israel Gat. Cutter consortium.
“This book presents practical and proven agile approaches for managing software requirements for a team, collaborating teams of teams, and all across the enterprise. However, this is not ‘only’ a great book on agile requirements engineering; rather Leffingwell describes the bigger picture of how the enterprise can achieve the benefits of business agility by implementing lean product development flow. His “Big Picture” of agile requirements is an excellent reference for any organization pursuing an intrinsically lean software development operational mode. Best of all, we’ve applied many of these principles and practices at Nokia, (and even helped create some of them), and therefore we know they work. ” —Juha-Markus Aalto, Agile Change Program Manager, Nokia Corporation.
Thanks to all who contributed.
I’ve been using a “Release Predictability Metric” (RPM) on a number of larger agile programs. The goal of this key metric is to help the teams achieve a level of program predictability that their enterprise stakeholders can count on, while still allowing for taking on the reasonable risks that are necessary for innovation , as well as stretching to the maximum potential achievements in a PSI time box. In describing it to a colleague, I realized I had never blogged about it, so I’m posting this excerpted content from the new book to address that oversight.
=====================
If you ask top executives what they would most like to see out of the software development process, many will answer “predictability”. And that is one of the many challenges in agile. We can reliably predict quality (by fixing it and adopting effective technical practices) and date (by fixing it) and cost (by fixing the team size and the PSI date) – but we can’t actually predict functionality – at least in the longer term. If we did, we’d be right back in the iron triangle that has served us so poorly in the past. Moreover, if we predicted and controlled functionality long term, then we’d have to temporarily ignore the variability and new opportunities the market presents. That isn’t agile.
However, as professionals, we must be able to provide our enterprise with a reasonably reliable predictor of upcoming events, at least near term, as well as some sense of the future product Roadmap that we intend to execute.
When implemented properly, the Agile Release Train can provide just such a predictability measure, at least for the next PSI (or maybe two). That gives the enterprise from 3-6 months of visibility into upcoming release content – enough to plan, strategize and support with market communications, release launches, etc. The release objectives that we established during release planning are our primary means to do this.
At release planning time, each objective is given a business value, assigned by the business owners for that program or subdomain. During each release retrospective, the teams meet with their business owners to self-assess the percentage of business values they achieved for each objective. This can be done both at the team and program level. For example, a program might rate its accomplishments as follows:
Actual Vs Plan Release (PSI) Objectives
In the example above, the program accomplished 79% of its release objectives. The questions arises – how good, or bad, is that? To answer this, we must return to our lean principles and the context for the enterprise program itself.
On the surface, at least, it might appear that accomplishing 100% of release objectives is the only worthy goal. Closer analysis, however, tells us differently. In order for a team to routinely accomplish 100% of its release objectives, they must either
1) drive all risk out of the plan by eliminating or curtailing innovation and risk taking
2) back off so far on objectives so as to assure completion
Neither of these optimizes the economic impact of our efforts. To achieve that, we need to operate successfully in some acceptable process control band, so that the program has reasonable predictability, and yet allows for the variability, “optionality”, and stretch goals inherent with software development.
In our experience, a program that can reliability achieve most of its release objectives is a trusted program that is an extraordinary asset to the enterprise. In this case, the release predictability measure should fall in a process control band something like that in the following figure over time.
Managing uncertainty with a release (PSI) objectives process control band
In this figure, Team B is predictable, even though they do not routinely hit 100% of their release objectives. They can’t, otherwise there would be no room for innovation and risk taking. However, the enterprise can depend on the fact that they will do most of what they said they would do. Team A, however, is all over the map. It’s hard to manage any program or enterprise with the characteristics of Team A. You simply can’t depend on them to deliver anything like what they predicted.
By creating and measuring this predictability measure at every PSI, the enterprise can eventually achieve the right balance of predictability and risk taking, thereby achieving the optimum economic outcomes.
Last night I presented to the local Agile Denver group. This was a variant of my Agile 2010 presentation, but one with a heavier focus on the scalable requirements (backlog) model. The title is:
The content and flow is:
1.Lean and Scalable Requirements Model
Applying the Model
2. The Agile Release Train
3. Rearchitecting with Flow
4. Agile Portfolio Management
I promised to post it, so here it is:
Agile Software Requirements (Agile Denver).pptx
Thanks to Brad Swanson and Bob Hartman for arranging this opportunity.
Scaling Software Agility 