Practically Agile
Using Agile in less-than-perfect situations since Y2K
Embrace Failure
I just can’t say how much I agree with this. One of my favorite things about Agile methods is their ability to find problems quickly. The problem is that it makes it very difficult to sell to folks who are used to methods with slower feedback loops. I can think of several projects over the last two or three years where the team exposed significant problems very early on in development.
In one case, we were able to pinpoint a major domain modeling problem early on. The customer kept phrasing things as though the application centered on one concept. Through a very early (iteration 2 or 3) demo, we were able to discover that this was due to thinking of how the system being replaced worked. In fact, what the customer’s business really needed was to be able to focus the system on a completely different concept. Because we found it early, we delivered a much better and more valuable system.
That said, the point of the linked post — and this one — is that software projects will fail, Agile or not. While we often sell Agile as a way to get to value quickly, we should also sell the other side — it also is a way to get to failure quickly. And that is a good thing.
It occurs to me that we talk about something similar in Episode 1 of Improving Podasts. What? I haven’t mentioned that yet? Hmm…
. 14 Jul 09 | Uncategorized
Did you hear about the article you mentioned through @codebetter?
I read the CodeBetter post this morning, and I was thinking that one of the aspects of Agile that the author ignored almost completely was communication.
We love to talk about technical risk until we are blue in the face. I wonder how often failure to communicate is masquerading as “technical risk”.
“We don’t know what we don’t know” seems to be a problem endemic to software development. Sometimes it kills projects, others it simply makes them late or arrive with less than expected functionality.
Many people strongly advocate prototyping the high risk pieces of your architecture early on in a release. I think this is just good engineering practice. Who recommends working on your communication skills?
I am almost constantly surprised at my capacity to leave my wife looking at me with a strange and distant expression when the conversation turns technical (always my fault). Obviously we are capable of understanding each other. We’ve been in a relationship for over 7 years. We can clearly express our wants and needs one to another.
Why does technology entering the picture constantly befuddle conversation both at work and at home? It seems like there is a missing skill in the technical trades, how to make technology make sense to the non technical. Shouldn’t this (not prototyping or whatever other engineering hoopla) be our most sacred responsibility and central job function?
Sorry this is such a delayed response, but I just noticed this comment.
I do not think that our most sacred responsibility is to make technology make sense to the non-technical. It is to make technology that is of value to users. That the users (technical or non-technical as they may be) must be able to understand it to get value is key, but is still corollary to the main goal. In other words, users don’t have to understand TCP/IP to use their web browser.
That said, a team (including stakeholders) will fail if they cannot communicate. And in places where I have worked, this has been a key aspect of the interview process. In fact, there is usually an entire session with the explicit goal of evaluating “soft skills” even for the most technical of resources.
So… who recommends working on communication skills? Certainly I do. And I think that is one of the precepts of a lot of the camp that was saying the only way to save your technical job is to learn (and be able to communicate to) the business.
You see rapid prototyping (building a demo) as the way to validate the business object model and client requirements quickly?
Monty, I’m not sure if this was directed at me or at Robert, but I’ll take a stab…
There certainly can be value in a prototype/demo. The question is whether that value is greater than what could be achieved by instead building a thin slice of functionality “for real.” In the anecdote I use in the post, we might have discovered the same thing with a prototype, but we would have then had a lot of code to throw away by the time the prototype could have been complete enough to discover it. Because we were developing the real product, only incrementally, we had very little that was actually thrown away.
In my mind there is no quantifiably right answer to how much should you prototype vs. digging into the real product. An agile/lean mindset tends to tell me that prototyping should be as minimal as possible. That said, recovering from problems when you are building the real product can be risky, especially if you do not trust your design/architecture to be resilient to those kinds of changes.
My own preferred tactic would be to do whiteboard or paper prototyping of key features before green-lighting the project. Then, just in time, do similar paper prototypes of the features when defining acceptance criteria. That said, every project/product is different.