Practically Agile
Using Agile in less-than-perfect situations since Y2K
Great Teams and Great Rock Bands
Have you ever thought about what makes great bands great? One of my favorite bands to listen to on and off in this decade has been The New Pornographers. After listening to them for eight years or so, I finally decided to find out something about them and discovered that AC Newman, the leader of the band had put out a solo album a while back. I’ve listened to snippets several times, but never bought it. More recently I found that one of the other singers/songwriters, Dan Bejar, has a band called Destroyer that is more or less his solo venture. Listening to the snippets of Destroyer’s album on Amazon.com, I realized why I hadn’t bought AC’s album. Before I lay that out, let me digress a bit… then I’ll tie it all back to software development management for you.
The Beatles were a great band. Amazingly great. As Zaphod Beeblebrox might say, “amazingly amazing.” The success is attributed to Lennon/McCartney, right? So, why weren’t John Lennon’s albums as popular? What about Wings? Pink Floyd is my all-time favorite band, but I’m not a big fan of Roger Waters’ stuff. (The Final Cut is low-down on my Floyd ranking.) I like the Gilmour-led albums, but I can certainly tell the difference.
That same difference is there between The New Pornographers and their solo efforts. In all three cases, one songwriter (Newman, McCartney, Gilmour) has a musical aesthetic that is focused a bit more on the melodious and harmonious and softer emotion. The other (Bejar, Lennon, Waters) brings a complexity and depth from cacophony, the unusual, and harsher emotion. Neither one works as well on its own as the pair do together. McCartney’s work comes across as audio candy. Some of Lennon’ work was great, but a lot of it was pretty much impossible to listen to. I happen to enjoy the melodious/harmonious more so I like a lot of Wings stuff and the Gilmour-led Floyd. Because of that I’ll probably buy AC’s album before Bejar’s, but I know I still will miss the other’s influence.
So, I promised to tie this back to software development… I have been working with a partner on a new feature for my current project. He and I have a tendency to agree, but to come at problems from different, often opposite, directions. I wanted to build bottom-up; he thought top-down. I wanted to be strict here and willing to let things slide there; he wanted the opposite. What I’ve found is that while we may discuss things for a bit longer than we might like, we eventually come up with a better overall product because we’re looking at it from those different angles.
So, is what we’re building worthy of comparison to Sgt. Pepper’s or Dark Side of the Moon? No, probably not. But it is better than it would have been if either of us had designed it alone.
And that is the moral of the story… good teams are made up of people who can work together and respect one another. But the best teams (and bands) are made up of people who are not identical. They compensate for each another’s gaps and even resonate to amplify their abilities beyond what would be possible if each worked as an individual. When building a team, don’t try to find people just like you or even just like your favorite developer. Find people who are different — just make sure they are willing to bend enough that the band doesn’t break up due to “creative differences” before the end of the project.
Rock on…
. 19 Dec 08 | Management | Comments (3)
Joel on Commissions
I generally like reading what Joel has to say. I respect that he is running a reasonably successful software shop and doing it in what he believes is the best way possible. Even though I often find my own version of the “best way possible” a little different, his writings are thoughtful and good fodder for further discussion. However, I have a bit of an issue with his latest article in Inc.
I agree wholeheartedly with the majority of this article. I have heard of Robert Austin’s work before, and agreed with it then. I have personally seen incentive programs fail for numerous reasons. No, it’s not the overall article I have a problem with. It is the very last paragraph. Joel spends the entire article building up a great case for not using traditional incentives because they can’t be set up to work and then, just when you expect a sage solution, completely backtracks and says in essence, “Forget all that. They will work if you set up the right rules.”
Huh? No they won’t. People often don’t even realize they are gaming the system. The problem is not that the right rules are not in place. The problem is that the right thing to encourage is the overall success of the company or (maybe) the project, not success in a single dimension or even of some set of “key performance indicators”.
First and foremost, do not give individuals bonuses at all if you can help it. For example, provide a team with a bonus based on working software delivered to production that has been bug-free for 30 days. If that won’t work for some reason, make sure the bonus is tied to long-term effects. Tie the sales bonuses/incentives to customers that are sold profitably and still happy and profitable 30, 60, or 90 days after delivery.
Frankly, better yet, just pay people a good salary and forget the bonus. Or, if it makes you feel better, go back to a Christmas bonus, but base it on the health of the company as a whole.
Tags: compensation, joel, Management, pitfalls
. 13 Oct 08 | Management | Comments (0)
Aligning Agile with Enterprise Architecture
A mailing list pointed me to a recent post by Jeremy Miller on Agile design and an older one by Joe Ocampo. Both discuss how design happens in an Agile project. Both are great posts. Jeremy’s post sticks largely to what is considered the Agile “party line”: design is done all the time rather than up front. Joe’s post talks about using Domain-Driven Design to develop the “ubiquitous language” that teams need for communication. Jeremy admits in the comments that a bit of up-front establishment of a domain is useful as context, but distinguishes it from design. Presumably he is equating it with analysis. Having written a book that, in part, shows how use of consistent domain modeling patterns can inform design and implementation, I would say it’s both. But that’s not what I want to talk about….
Reading these posts and exploring a bit further, I began to relate the establishing of a domain context for stories with establishing an architectural context.
One of the main challenges I have faced and hear others describe is how to maintain agility when there is a scope of multiple Agile projects (what the PMBOK would call a program) or an enterprise portfolio that really needs consistent architecture. I am generally a believer in simple, evolutionary design. However, as Jeremy points out in his post, it requires people with the proper skills to maintain an open design/architecture and who know how to tell when they have reached the last responsible moment. What I have discovered is that as the scope of systems under development scale, the last responsible moment for certain architectural decisions tends to shift earlier.
As such, a reasonable step would be to include a (short) architectural analysis session for each release that would mirror the domain modeling exercises Joe mentions late in his post. In that way, those with architectural knowledge could get involved and discuss what architectures support the features required and which decisions need to be agreed up front. Provided this is timeboxed and the group puts appropriate emphasis on postponing that which can be, this is in line with Agile values as well.
I should also note that I would only add this practice if the team found it necessary. As a coach, I might recommend it upon seeing the following things either in a retrospective or during planning or other working sessions:
- multiple components, libraries, and/or frameworks in use that accomplish the same goals
- “not invented here” syndrome
- lack of integration testing between project teams’ output
- failure of or difficulty with coordinated deployment (usually preceded by the lack of integration testing)
- no or limited consideration of nonfunctional requirements (performance, stability, etc.)
- failure to meet nonfunctional requirements
I’m sure there are other smells that would indicate a need for architectural planning. If you think of others, let me know in the comments.
Tags: agile, design, domain modeling, streamlined object modeling
. 08 Jul 08 | Architecture | Comments (6)
Iterative and Incremental: Part 2 – 1+1>2
This is the second part of a long post on iterative and incremental development. In Part 1, definitions were provided to distinguish both practices from the general term “iterative development”. This part describes some pitfalls of doing one without the other and how each adds value to the other.
The pitfalls of only iterating without incrementing are simple to summarize: nothing new is added. That is, if iterating is the practice of improving what already exists, then it provides no facility to add functionality to a system. While — in theory — the product and/or process would eventually be as near to perfect as humans can make it, the overall value would not increase.
Though it seems contrived, this happens in real projects. For example, assume that a new project starts its first iteration with requirements that are not properly thought out. The product that is created will not make the customers happy. They will want changes: improvements. They iterate on the requirements themselves, resulting in iteration on the product. The project team then discovers that the new implementation could support the changed requirements better with a change in architecture. They convince the customer to allow them to make the improvements. Meanwhile, the customer has spent so much time thinking about this one requirements set that they start to “need” more bells and whistles. Soon, updates to the requirements are created, and the cycle begins again.
The pitfalls of only incrementing without iterating are a little more complex. If incrementing only adds to what exists, then it is not spending effort to improve what is already there. At an extreme, this would be like sealing each iteration result in a shared library file (DLL, jar, etc.) and requiring each subsequent iteration to only use those pre-compiled artifacts. In a more realistic example, this is simply not allowing time for refactoring. Another version is skipping the retrospective or not implementing any of the improvements suggested by the retrospective. Both result in creating or failing to remove hurdles that slow or block progress.
Incrementing without iterating is more common in my experience. It is somewhat easier to see the lack of value increasing when nothing new is being created. It is more difficult to tell when the rate of value increase is stymied by technical, project, or other debt.
If you spend a portion of each period of work improving what has been done before, you can remove those hurdles that prevent progress. By making sure that a portion of each period of work is spent on adding new features or practices, we reduce or prevent unnecessary gold-plating and particularly wasteful forms of analysis paralysis. In short, each practice fills gaps left by the other.
At some point (1994 according to Alastair Cockburn’s article), the project management and process community made the interesting decision to combine these to in the single term “iterative”.
Was it, as Alastair says, because they were just happy to be “repeating the cycle”? My hope is that it is more because they saw the need for both to work together. The term may have been a poor choice, but combining them is a great choice.
Tags: incremental, iterative, pitfalls
. 13 May 08 | Process | Comments (0)