This year all we've heard from the folks over at the Federal Government is that we have to start being "agile." My guys are really talented, are doing daily meetings, and they've always been collaborative. Isn't that agile? ~Name withheld (so people don't think I'm dumb)
Dear "He who shall not be named,"
I don't blame you for withholding your name! We work in an industry where both sides of the coin, customers and engineers, are both passionate about agile without much good information. Whenever I give a speech about agile I say to myself "keep your head down, Jeff, there's gonna be fruit flying!"
For some reason, discussions about agile generate a lot of passion. Bring it!
Last week I was speaking to such a group of "agile evangelists" and every time I said the word "requirements" a young woman corrected me by screaming "VALUE!" Throughout my speech she insisted that there were no requirements in Agile, only VALUE. I could have suggested she consider re-factoring her concerns so that the "most valuable" comments came first, but I held my tongue.
When the government says "be more agile," they may be thinking "give me stuff faster and cheaper." When engineers say they want to "be more agile," too many of them seem to be thinking "no one watches over me and there is no evidence that I followed any process at all.
As far as what the government ACTUALLY means when they say "be more agile," your guess is as good as mine! I do know that in the battle between Government and Agile, the victor is predictable.
In order to unravel the meaning of "Agile," it helps to think of it as a three-tiered architecture.
Tier 1 - Values
This tier defines the values that dictate the way we work. Values are the agile equivalent to "policies" in the CMMI (although the implementation of so many of the "CMMI-style" policies have distorted this to mean "the rules). The values tier defines the things that are most important to us, and the things that, presumably, the organization would like us to keep focused on. You see? Policies.
Some of these agile values inspire transparency, collaboration, hiring the right people, fail-fast, inspect and adapt, share the work, and others.
NOTE: (or rant, however you want to interpret it). "Traditional Waterfall" style projects can easily have these same values! And guess what? When they do, they are called well run projects!
Tier 2 - Methods
Tier 2 defines the WAY we do work, and that WAY is derived from the values in Tier 1. All of the methods selected must adhere to the values. In this way we adapt the concept of "traceability" to process improvement (thank you again, CMMI!).
Clients who work with Broadsword often hear me talk about "the WAY." Your "way" is derived from the values and methods use choose to create and adopt.
Methods describe the sequence, interfaces, style, and the workflow of much of what we do. In this context, I use the words "method" or "framework" while I'm working with our clients. I think of them as synonymous.
In an "agile" environment, the most common methods (frameworks) are Scrum, Extreme Programming, Spiral and Crystal, with the first two being the most common. If I've left one out, please don't throw tomatoes . . . this isn't a user guide!
For example, Scrum defines ceremonies, artifacts, and roles, and presents a sequence (Releases, Sprints, et al) for us to deliver our service or product in the context of values.
See Rant above.....this can ALSO be done in a Waterfall world.
Tier 3 - Techniques
Techniques are the things we do everyday, within the selected method, in adherence with the values. There as some techniques that are unique to methods, and some that span the entire family of methods.
Use of the retrospective, backlog grooming ("story time"), User Stories, Story Points, Planning Poker, Fibonacci cards, the Sprint Review (Demo), and others are examples of techniques that are normally associated with agile methods.
Rant again . . . (see above rant).
So, adoption of techniques without the corresponding methods and values (such as "we do a daily meeting") does not make you "Agile." If you think about it architecturally (as the CMMI does), you'll find that true "Agile" is a heckuva lot more robust than most people think, which is one reason that Agile, when executed with integrity, works.
By the way, do you know what we call all three of these tiers together? PROCESS.
Like this blog? Forward to your nearest engineering or software exec!
Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.
Visit www.broadswordsolutions.com for more information about running a successful CMMI program.
Copyright (c) 2012 Broadsword Solutions Corporation
No comments:
Post a Comment