Appropriate Agile Measurement

Here is a really interesting paper on the whole topic of metricds and how they apply to Agile from Deborah Hartmann. The infulence of Mary Poppendieck and Eliyahu Goldratt come through strongly. A very interesting read.

http://www.berteigconsulting.com/AppropriateAgileMeasurement.pdf

Mainstream justification for Agile?

Dave Murphy at the On Be(come)ing Agile Blog talks here about a Harvard Bussiness Review article by Nitin Nohria and Thomas A Stewart title "Risk, Uncertainty and Doubt" available here I haven't read the article but Dave has an interesting take on how this article supports the justification for an Agile approach. I think it's interesting to see an article like this in such a mainstream publication that is so widly read at the top levels of management. Maybe this is the start of management seeking out Agile practisioners to help manage their risk rather than than the othe way round. Perhaps not. Still an interesting read.

Trust is the foundation of Agile Work

I came across this on the Agile Advice blog. I agree with Mishkin wholeheartedly. The need for trust is one of the least understood aspects of agile processes as far as I’m concerned. I constantly think about how developers can earn the trust and how they break the trust of both management and customers. Here’s the quote from Agile Advice:

Trust is the Foundation of Agile Work

Technology, tools, process, even good ideas and good organizations do not create trust. People create trust by being trustworthy: honoring their commitments, striving for excellence, truthfulness, courage. One of the fundamental problems afflicting organizations is the lack of trust: between management and employees, between business and IT, between experts of various sorts, between coworkers.

This lack of trust is institutionalized in many ways including bureaucracy and legal frameworks. The only way to change this state of affairs is to build trust. And the only way to build trust is to embody trustworthiness in yourself so that by example and by your words you can help others to become more trustworthy. Agile methods put in place mechanisms that assist in building trust. But those mechanisms are merely a means to an end. Let us never forget that.

http://www.agileadvice.com/archives/management/index.html Posted by Mishkin Berteig at 12:27 AM

Explaining Agile to Customers

I came across this on the Agile Blog. It’s something I’ve struggled with in the past, how to explain the Agile approach effectively to your customers

Explaining Agile to Your Customers

Many software companies use Agile techniques but still use fixed-price, fixed-scope contracts because it seems too hard to explain Agile to the your customer. This is a shame, because a lot can be gained by bringing your customer into the Agile process. Here's a way to explain Agile to the person who's buying your software, in plain english, with no jargon.

What do you mean, you're Agile?

We’ll ask you for a high-level list of features you’d like to see us build, and the date you need your first release.

We’ll ask you to sort that list in rank order most valuable features first.

We’ll give you a good-faith estimate of how many of those features we think we can deliver by that date, and we’ll absolutely guarantee you’ll get working tested software that includes your highest-priority features on that date

We’ll work through this list in priority order, asking you for the additional details along the way.

We’ll give you working fully tested software every 2 weeks. You’ll pay for each two-week chunk you get, when you get it.

You can change priorities for features we haven’t started on yet, but we ask that you only do that future 2-week chunks, not work in progress.

Sometimes your idea of a feature is bigger than what we were thinking of. We’re confident we can deliver close to your list of features by your date, but if you have very specific needs around some features, they may take more time than expected. We’ll still meet the release date, but we may need to delay work on some of the low-priority features. We’ll work with you to figure out whether there’s a simpler version of features that might meet your needs. Of course, sometimes features will be easier than we thought, too. We’ll work with you continually to make sure you get the most important features by your date.

If you discover you’ve forgotten to include a critical feature in your initial list, just insert it into its appropriate rank position in the list. Usually this means one or two of your low priority features will fall off the list.

If you discover before your release date that we’ve given you all the features you need, you can cancel future work and release what you’ve got.

If you need more features after your release date, you can request that we keep working on your list, 2 weeks at a time.

Because we’re working with you throughout to make sure we’re building the software you need, we’ll need you to be accessible to answer questions throughout, at least by phone.

Posted by Alex Pukinskis on March 13, 2006 11:21 AM | Permalink

Contracts

I came across this post with a quote from Penn from Penn & Teller which really made me think about what contracts are for and why companies need them when developing software.

Make Deals With People, Not Paper, PENN JILLETTE, magician, author, and producer

This was the hardest thing to learn when I was 19. When we first started doing Penn & Teller shows, I thought that if you had a contract, it was enforced. I thought there were the contract police -- so you'd sign a contract that says you're going to give me a million dollars, and if you don't have a million dollars, someone will step in and give me my million anyway. Right.

That's one of the hardest lessons for a guy like me who has no interest in business but now runs a multimillion-dollar enterprise. A contract is not much of a legal document. It's just an agreement that two people who trust each other have made. You can't enter into a contract with anyone that you wouldn't make a handshake deal with, because everything comes down to a handshake deal. The more experience I got in showbiz, the less I read the contracts. Now I don't bother. If I can't make the deal in a phone call, and have them understand it, then it's not a worthwhile deal. You're making a deal with the people, not with the contract. That's a mistake that people make a lot: "We've got it in writing now." The contract is clarification, but it's not enforcement.

What is the Agile Experience?

Hi,

Welcome to the 'Agile Experience '. I'm Pete, an Agile developer currently working in Scotland. I've started this blog to document my experiences with Agile Software development. I'm working in a company which is trying to be more Agile and I have the lucky job of being their process guy.

My background is software development, not management. I've been working in Software for the last 10 years both in Scotland and in the US. I spent 3 years working in Phoenix Arizona as a consultant. I've been interested in Software methodologies for about 8 years now and Agile in particular for 6 or so. In that time I've experienced a lot of projects both good and bad. I've worked with lots of different technology and seen ideas for software come, go and return. I've been a contracter, I've run my own company and now I'm trying to help others run theirs.

I get so much information about Agile passing through my hands and so much input from working in an Agile company, being part of an Agile group and reading everything I can get my hands on that I needed somewhere to collect my thoughts, links and experiences. I hope that's what this blog becomes. If nothing else it may form the notes for a book I hope to write (don't we all :) )

Feedback is essential so please tell me what I can do to improve my blog.


I hope you enjoy what happens here and we all learn from the experience

Pete