Friday, December 12, 2008
Thursday, December 11, 2008
First let's take a look at why RD.SP3.1 is even in the model.
Sometimes it's difficult to visualize the feasibility or reasonableness of a requirement without putting it in context. This is one reason prototypes are so popular - they literally paint a picture of what the implementation might look like. When they see this users often say "no, that's not what I meant" or "what would happen if we tried this?" This is a form of requirements validation.
RD.SP3.1 is asking you to validate requirements by putting them into some context.
The simplest and most useful way to do this is with a Use Case, User Story, or Storyboard. They require only a marker and a whiteboard, or software like Visio, to implement. They're extremely valuable at putting requirements in context, and they're low cost, low effort.
Developing a prototype for a more complex requirement, or a proof-of-concept (a "spike") is another way, albeit more costly, to drive out pesky requirements defects.
The other artifacts you've listed seem more like they belong in the Technical Data Package (design documents from TS) rather than in RD, with the exception of non-functional requirements, which need to have RD SP3.1 performed against them to be completed.
Wednesday, December 10, 2008
Anyone who has worked with me knows that I scoff at the idea of implementing tools when a process improvement program starts up. Too many companies see a tool as their salvation and end up creating a monster that helps them do the wrong thing – only faster.
We had this experience in the Broadsword Labs once when our sales staff, without consulting us, decided they needed a new “tool” for expense processing, went out and bought one, slammed it in, and it wreaked havoc with the client base because . . . you guessed it, they didn’t have a solid process behind it. The clients started seeing all these new forms and reports, no one knew how to use the system, there were errors in the expense reports, it was conusing what the roles were . . . . sounds like some GPs doesn't it?
It’s natural for a company to start to see opportunities where a tool could indeed be helpful after they've deployed some stable processes. Early in the "proces improvement" cycle these tend to be tools related to REQM and CM, then later MA, estimating, and then finally life-cycle management tools like Borland’s CALIBER product line.
I would expect a ML3 company to implement some tools, and to manage that implementation in the SPIP. This is an absolute MUST for ML5 (OID) where piloting and deploying “innovations” is spelled out in the SPs.
However you do it, the deployment of tools should be governed in your SPIP and under the guidelines spelled out in OPF.
Friday, November 28, 2008
"Agile" is a generic term that refers to a loose set of methodologies that include Scrum, XP, Feature Driven Development, and other iterative AND incremental methods. You are correct in that it is not a methodology in itself.
You often hear very loose descriptors like "trust," "iterative," "low documentation" etc used to describe "Agile" but these are pretty nebulous. To be more precise:
1) Agile methods are iterative, where the complete lifecycle (plan, reqt's, design, test, build) happens in short durations, often 30 days or less. These activities are usually not linear, but empirical, and do not always occur in a specific sequence
2) Agile methods are incremental, where a small set of features is developed, followed by refinement or another set of features. The methods don't espouse the "big bang" but more like small bits at a time
3) Agile methods negotiate scope, not time and budget. A "waterfall project" usually has a fixed scope, and a fixed budget. If a major change is requested, the timeline and budget is negotiated. Agile methods EXPECT change, but negotiate each release (or iteration) to contain a certain amount of "features" (or functionality). If they don't get it all done, they execute another release.
4) Agile methods MUST have buy-in from the end-user or customer, because this type of negotiation is not IT or engineering driven, it's driven by the business, so it's not for everybody.
The different Agile methods have other specifics (XP uses Pair Programming as a form of real-time validation, Scrum has "stand-up meetings and "sprints" for instance) but these are ornamental - not core to the concept of "Agile."
For more information (and for a discussion of CMMI and Agile methods) you can download an SEI Technical Note (CMMI and Agile: Why not Embrace Both!") which I co-authored with several other very talented individuals.
Friday, November 21, 2008
So what's wrong with guessing?
I'm not sure your problem is as much about "Scrum" as it is about the inflexibility and lack of experience within your SEPG! The CMMI does not speak to specific estimating methods and while "planning poker and calling it a day" may not be enough to satisfy the CMMI, there isn't a requirement to perform more "traditional" methods such as SLOC, KOKOMO, or the like either.
There have been whole books written on high maturity and estimating, so now is not the right time to get into all of the glorious and fun-filled detail but I'll touch on some of the concepts.
As to Wideband Delphi being "akin to guessing" I guess I would say "it depends" (I'm not saying it's a "high-maturity practice" either). To say that is akin to saying that a design that has been put together by an expert software architect, and then peer reviewed by other experts, and then prototyped is akin to guessing on a design. It isn't. We call all of those things TS, VER, and VAL don't we?
But, on to the meat of it.....
The difference between a ML2/3 organization and a ML5 organization isn't in how they do things, but it is in the data used to make the decision on how to do things. The essence of ML5 is trying new and innovative techniques to improve performance based on data gathered through the execution of the process (like Scrum for instance).
Someone in your organization should be gathering appropriate data, developing baselines (determining the natural bounds of process performance), and performance models using various statistical methods. That data should be used to estimate and plan projects as well as select potential innovations (such as the use of Scrum) for piloting and eventual deployment.
So, if I were to use historical performance baselines as input into a wide-band delphi process that was intended to "feed" a scrum project, and I was doing so because I had identified Scrum as an innovation that could improve performance (supported by data that told me that phase and cost overruns were a problem we a problem) then I would be behaving exactly like a High Maturity organization was supposed to perform.
Of course, that's a hypothetical situation. You'd have to determine your own thread for getting value from Scrum and ML5, but if you read our latest SEI Technical note "CMMI and Agile: Why not Embrace Both" you'll learn a lot more about it. Get it at: http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html
Wednesday, November 12, 2008
Agile or CMMI: Why not Embrace Both! has been released by the Software Engineering Institute.
A new SEI technical note has been published. Please visit the following page to download the PDF version of the report. http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html
CMMI® or Agile: Why Not Embrace Both!
Hillel Glazer (Entinex, Inc.)
Jeff Dalton (Broadsword Solutions Corporation)
David Anderson (David J. Anderson & Associates, Inc.)
Agile development methods and CMMI (Capability Maturity Model® Integration) best practices are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using both and exploit synergies that have the potential to dramatically improve business performance.
keywords: Agile, Agile methods, CMMI
cover: November 2008
publication date: November 2008
editor: Sandy Shrum (email@example.com)
Thursday, October 23, 2008
Furthermore, if you delve into OPP (or any of the HM PAs) you realize quickly that it is these very measures that give you the most valuable information about process performance – enabling you to make course-corrections to your process to improve performance. Lacking that, there is way to understand what needs to be improved!
M&A is the PA that you would use to manage and execute those GP2.8 measures. M&A is simply an infrastructure PA, which is why it is described in the model as a “support” PA. It does not speak at all to “what” to measure, only how to build and execute a measurement infrastructure. M&A must be “fed” by measures that are the result of process execution, so the other process areas are M&As “customer.”
So, IMHO, I stand by my original assertion – GP2.8 exists to help us understand process performance, and measurement is an effective way to do this. The trick, and I fully advocate this, is to keep it light and useful.
Tuesday, October 21, 2008
"Encapsulated Process Objects"
Grand Rapids, MI
November 5th, 2008
Agile Development Practices
November 12th, 2008
National Defense Industry Association (NDIA) CMMI User Group
"Encapsulated Process Objects: How Object Orientation and Agility can supercharge your process improvement program"
November 17th - 20th
- 2009 -
SEI's SEPG 2009
"MORE Notes from the Blogosphere"
"Agile and CMMI: Why not embrace both"
"Johnson Controls: an Agile CMMI experience report"
San Jose, CA
Tuesday, October 7, 2008
Thursday, October 2, 2008
Tuesday, September 30, 2008
Sunday, September 28, 2008
Lot's of people are moaning about the SEI's new interpetation of High Maturity - what does it all mean?
Tuesday, September 16, 2008
Hey Jeff! Some of the process areas seem redundant. Why do we have Requirements Management AND Requirements Development?
Monday, September 15, 2008