I'm taking a Myers Briggs test right now. My whole team is taking the test this week. I learned alot from doing the test in grad school; it helped many of us adapt to our different approaches to working. But that's for another blog entry.
One of the questions: Are you more likely to
a) see how others are useful
b) see how others see
My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus1 to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.
I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.
1Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.
Tuesday, February 26, 2008
Monday, February 18, 2008
Agile versus Discipline (sic)
I recently gave a presentation: "Introduction to Agile" at a .NET CodeCamp in South Florida. One of the attendees commented that Barry Boehm had written a book called something like "Agile vs. Discipline".
My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.
Wow.
Wow.
First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.
That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.
Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?
Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.
Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?
I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.
Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:
One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.
Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.
Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.
Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.
In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.
My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.
Wow.
Wow.
First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.
That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.
Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?
Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.
Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?
I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.
Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:
- Personnel. Essentially Mr. Boehm says you need smarter people to do agile. This is probably true. I would argue, however, that you’d rather pay one person $90K who can do the work of two people at $60K and that the diminishment of communication costs between people adds to the economies of scale beyond the numbers. This is true in any environment that you wish to consider. The best programmers, it is said, are 10 times more productive than the average. Why not pay twice the going rate for someone who’s only, say, five times as good?
- Dynamism. (%Requirements-change/month). If your requirements don’t change as much, agile is not right for you. What a silly statement. They probably meant to say that if your requirements don’t change as much, you can hire cheaper help who can’t adapt to change. Agile works well in dynamic (i.e. most) environments. You might be able to get by in the rare “stable” environment with excessive documentation, and delay between idea and working code.
- Culture (%thriving on chaos vs. order). I love this statement: “[disciplined devotee] thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures”. When’s the last time you heard someone say “I am particularly empowered when somebody tells me exactly what to do and when to do it”? I’d much rather have a team of thinking, adaptable, empowered developers than drones who simply follow the process. Am I way out there?
- Size. This is the big knock on agile… that it doesn’t scale. I’ve seen it scale… well… fail to scale. I’ve yet to see a successful large-scale agile project up close and in person. But this should not be interpreted to mean that I discount the possibility. I believe it can be done. I just think that it requires enlightened leadership. That’s where the dearth lies.
- Criticality. Really, this is plain stupid. Sorry Barry, but this dimension really irks me. When’s the last time you worked as a leaf-node part of a team on a project in either a waterfall… umm, I mean, disciplined… approach or an agile approach. This dimension alone conveys to me that you have lost touch with software development reality. Agile is not the antithesis of discipline. You probably think that agile means “no documentation” – like many ignorant folks out there. Fortunately they’re not writing about it; alas, you are.
One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.
Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.
Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.
Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.
In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.
MoSCoW Squared
Agile business analysts are well aware of the MoSCoW framework. That is - the classification of requirements as "Must Have", "Should Have", "Could Have" and "Won't Have". The beauty of this classification is that it clearly defines the stories in understandable terms of importance - rather than 1, 2, 3, 4.
A colleague of mine - David Smith - recently pondered the importance of several stories across two dimensions. There were features that had high importance to one party but not the other, and there were stories that appealed to both constituencies. He plotted the requirements on a two-dimensional grid, assigning their importance across the two dimensions representing those constituencies. It was so informing and illuminating that I thought other agilists would benefit from the idea. Here's an anesthetized version:
Ultimately, the value of the story stems from its radial proximity to the root. In other terms, you could probably draw an arc reflective of the relative importance of each axis (or constituent).
I hope you find it useful. I know that, for us, it provided an "aha" moment.
A colleague of mine - David Smith - recently pondered the importance of several stories across two dimensions. There were features that had high importance to one party but not the other, and there were stories that appealed to both constituencies. He plotted the requirements on a two-dimensional grid, assigning their importance across the two dimensions representing those constituencies. It was so informing and illuminating that I thought other agilists would benefit from the idea. Here's an anesthetized version:
Ultimately, the value of the story stems from its radial proximity to the root. In other terms, you could probably draw an arc reflective of the relative importance of each axis (or constituent).
I hope you find it useful. I know that, for us, it provided an "aha" moment.
Subscribe to:
Posts (Atom)
