Agile Wikipedia update...

Jon Strickler has been working for months on a better clarification of agile to the open world. He recently took it upon himself to update the wikipedia page on Agile software development. In reviewing his work I also realized it might be good to call attention to the PM Declaration of Independence.

70% accuracy + Speed is better than perfect...

Artemgy has an interesting post about agile decision making.

"...it is important to make the right decision… …or is it?
Not according to Percy Barnevik’s “7-3 formula”! The man who ran Swiss engineering giant ABB for a decade insists that you can still be successful if you make nearly half as many wrong decisions as you make right decisions!"

I think a big part of embracing agile is understanding the fail quickly mantra. You have to accept the boundaries of your day, iteration, and release and use them to force forward progress instead of falling into an analysis paralysis state. This is a by-product of all the feedback loops found in agile (pick your agile denomination). It's okay to make bad decisions sometimes if you can recover quickly.

The more transparently you can do this, the more trust you build with your customers and users that you will always do the right thing for them in the long run. This creates loyal followers.

Sustainable pace...

I ran across this from another site. It's about productivity and overtime. It wasn't intended to be agile focused (actually, if you are truly agile, then this isn't relevant), but it's good ammunition for an agile team when arguing with management about sustainable pace.

Enjoy!

Rules of Productivity - Upload a Document to Scribd

Read this document on Scribd: Rules of Productivity

Update: Today InfoQ published an article about sustainable pace. OpenView Venture Partners has announced that overtime is detrimental to scrum. There is a reference to Clinton Keith's discussion on this also.

Rant about Agile Certification...

If you hadn't noticed, the title of this post notes that this is a rant. I know I will upset certain people in the community, but I believe in this and I've got to speak up.

I endorse scrum as a good approach within Agile to pursue. It is one option of several and I've had success with it. I'm also a CSM, certified scrum master. This was paid by my prior employer and I was trained by one of the original 40 CSTs, certified scrum trainers.

//rantbegin

At Agile 2007, I talked to someone in the Scrum Alliance booth and found out that there is a great money sucking scheme behind this certification thing. First of all, it expires after a year. Secondly, you can renew it by simply paying for it. Back then, they sent you a new sticker for the new year to place on your certificate. They didn't even take the time to print and send you a new one.

So basically, the certification is a scam. It certifies that you sat in a class that has no test at the end. It doesn't require you to have experience. It doesn't require anything for renewal but money. Oh yeah... now that everyone has it, they offer several other upgrade certifications: CSC, CSP, CSPO, CST. Why not a CSBSer?

What triggered this rant a year after I gained this knowledge at Agile 2007? Recently, Bob Sarni did an awesome thing by creating a LinkedIn group for the Scrum Alliance. It was one of the few LinkedIn groups that had some real discussion. Recently, he handed the baton off for the group to someone else. After a few weeks, there is an announcement that members of the group should divide themselves by the above acronyms and join new groups. Oh yeah, and-

Each requires active membership in the Scrum Alliance and appropriate certification. Please feel free to join any of the other groups you are certified for...

So, now they are using LinkedIn to milk money out of the certification machine.

It's a shame because its stuff like this that helps people lump agile into the same bucket as all the other has-been process certifications over the years.

Agile is supposed to be an inclusive community. We are all supposed to be striving together for higher understanding. We are all supposed to be helping each other. This smells like an old boys club.

I'm not alone in this thinking... here is a post on InfoQ, a second one, and the formal Agile Alliance stance on certifications.

//rantend

I am glad I have the certification. The training was valuable and helpful for my education in Agile. I am honored to have worked with some of the people in the Scrum Alliance. I'm just opening a real debate around how it sets a perception of elitism.

In related news, there is a driving movement towards peer certifications that I do endorse (assuming it continues in the direction it is currently heading).

Invitation: I seriously welcome any thoughts on this topic. I will let them all through... I only moderate comments to block spam.

Update Nov 2008: this post got a lot of traffic... there is good news... they are adding a test to this certification! I don't know how well it will work, but it is a start.

Retrospective accountability...

There is a post on InfoQ about insuring the changes proposed during retrospectives are followed through. This triggered a comment from me that focuses on the need for accountability in retrospectives.

Retrospectives are for the team to improve. The team should collectively own the meeting and not look at the scrum master or other leader to own the retrospective just because they are the facilitator. This is part of the self-empowered, self-managed team mantra.

When ideas come up in the retrospective, this same attitude should apply. Ideas aren't to be pitched over the wall for "somebody" to solve. The point of a retrospective is to uncover and improve. The team is doing something that can be improved, and unfortunately (Mr. Teammember) this means you have to be part of the solution.

Below is the comment I placed on the thread at InfoQ:

A by-product of working agile in a FDA regulated company was addressing this issue with documentation and therefore leading to a solution to this problem.

In retrospectives I ran then and still run today, each idea/topic is given an owner by the end of the conversation. Normally this is someone who volunteers, but sometimes we have to assign the closest person. The only time this wasn't true was if everyone agreed to do something, then the group was the owner.

In the next retrospective, we quickly review the prior retrospective topic list and review the outcomes. (Did we do it? Is it working?) If items are considered closed, we remove them. Sometimes items flow another iteration cycle or cause new conversations. The point is that there was an owner that should have run with it for the good of the team.

I call it the accountability cycle.

Shorten your iteration...

You can't allow the implementation of agile to be a 30 day version of waterfall. All you do in this scenario is take that over-worked / over-stressed window that you have every release and make it happen more frequently. This is a great way to make agile fail. Instead think that about how to reduce that pain and improve the situation. Allow your cycle to happen more easily, so that the business and customer can resteer priorities before what you are working on is out of date.

If it was painful to release every year, fix that problem so that you can release every quarter. As your pain tolerance decreases and you realize that it is painful to release every quarter, then fix those problems and release every month.

Every time you shorten your iteration length, your team will realize that there are things that are time-consuming and painful. They will argue that doing it more frequently is less productive. Instead of deciding not to shorten the iteration, decide to fix the pain point. Each time you challenge yourself to do this, you will find yourself in a better place.

This is one way to force yourself to achieve true agility.

For example:
Your team will allow deployment to production to take 2 days if you are releasing quarterly. Mention a monthly iteration and suddenly people notice that you are losing 2 days 3 times as often. Instead of fighting the monthly iteration, fix the problem and make deployment take one day or less. Everyone wins.

Martin Fowler has been overheard saying "If it hurts, do it more often"

Product management...

This article has a little but of mud to work through, but check this out if you're interested in product ownership and management within agile.

My favorite point that it makes: "The top determinant of a product’s revenue success is whether it meets real customer needs and is targeted at appropriate market segments."

Also amusing, they challenge (and apologize) for questioning Ken Schwaber on ranking backlogs based on ROI.

What type of leader are you?

Mike Cottmeyer talks about how "Project Managers, Agile Project Managers, and ScrumMasters tend to fall into one of three camps... ...The Tracker, The Remover, and The Anticipator".

It's a really good post about how the value of a leader is in shifting from helping a team overcome problems and keeping them focused on work to helping the team predict and remove problems before they happen.

My comment is that we can't expect a new leader to immediately be an anticipator, but they need time to assess the culture and understand the domain first.

How do you hire?

Interesting post and conversation about the hiring process for an agile team. I've seen this topic several times recently, but I didn't think to keep the other links around.

The real key is balancing the need for hiring people that fit your culture. This can mean hiring young and molding them or finding the right experienced people. In agile, the second is a small challenge. In small companies, the first option is a risk when that is all you can afford (no senior people to mold them).

Click through to read the details.

Typing faster makes you more productive...

I'm channeling JB,
JB is channeling a concept from Alistair Cockburn.

I highly respect both, so I'm not going to unnecessarily add anything more. Read about microtechniques and productivity to find an ingredient in the secret sauce.

I used to be faster, but here is today's result

77 words

Typingtest

Improve your testing with 5 for 5...

Someone sent me this link on the Search Software Quality site about the differences of agile vs waterfall related to quality and testing. It's not written in a style that normally lands in my reading list, but there are some interesting tidbits contained inside.

One great little gem deep inside the article is about building respect on the team around peers and testing. This link led to a great blog post about the "five bugs in five minutes" game that is a fabulous idea.

In case you don't want to follow the last link, here's the summary:

• I (developer) think I'm done
• I challenge a peer to review my work
• If they find 5 bugs in 5 minutes... I buy them lunch

Why?

• TDD and auto-testing is good, but it's not creative like the human brain
• 5 minutes is quick
• I learn from my peers (like pair programming)
• It's cocky (I challenge the best because I believe there aren't any) and therefore fun
• It encourages your team to have lunch together and build stronger relationships.

Check it out... I'm going to see if I can convince my team to try it.

Pit Bull for a moment...

To understand the pit bull reference, read my post about pit bulls vs. puppies that focuses on extreme personality types in the work environment.

Many of us have had a work day where we are facing a major problem. We stayed up all night trying to fix the problem and we are tired, grumpy, or even downright nasty. We go into a standing meeting and vent. We might even talk about how we should have seen the problem coming months ago and shouldn't find ourselves in this situation. Grumble, grumble, GRUMBLE.

STOP!!!

You are asking for help. You are attempting to point out a problem. You are calling attention to a cause that should rally the troops. Is your current attitude the best way to achieve this goal?

We all do it. Take a breath. Point out that you were venting and apologize. Start over on the topic.

If you want to solve a problem, it is important that you communicate things in a way that empower people to help you. Don't create a situation where they leave you alone for the day.

If you are the leader in the group, speak up. Don't let the temporary pit bull deflate the team's energy for the day. Protect the team, and provide the disgruntled support. They aren't grumbling for nothing. Remember, it is a frustrated cry for help.

Culture affects your team...

Many people in the agile community agree that success rides on the team's ability to work well together more than on following agile. Communication and teamwork are critical to a successful environment. The question is, how much should we focus on individual differences when coaching a team?

As an American, I've only worked in the states; but I have worked with people from many countries (Germany, Austria, Romania, India, Russia, China, etc, etc). I've been fortunate that while working for Siemens I went through cultural awareness training to understand the differences between US, German, and Indian cultures. Through all of this, I've learned that culture affects your team dynamics in ways you'd never realize.

For example:

• There are cultures where saying "I can't" to a request from a higher level person is not acceptable even when the request is impossible.
  
• There are cultures where management isn't to be questioned.
  
• There are cultures where people are trained to not think for themselves, but to follow mandates and structure.
  
• There are cultures where everyone talks about their salary honestly and use it to measure who has seniority in a conversation.
  
• Some cultures focus on academics, engineering, and striving for perfection while others focus on copying others and surviving.
  

The philosophical concepts of accountability, responsibility, quality, success, and DONE can vary by cultural group.

Don't throw a problem at a newly formed team hoping they will solve it on their own without thinking about whether there are any cultural differences influencing this new group.

The next time you have two people on your team experiencing repeated friction, think about whether they have different backgrounds that might lead to different unintentional interpretations of each other. This may provide insight to a problem caused by misunderstanding instead of an actual difference of opinion.

Note: before I'm flamed for endorsing stereotyping, let me set the record straight. Stereotyping is a horrible thing when used in a position of power to control or demean another person. But stereotypes form based on commonalities, and they can be helpful when looking for reasons behind something you don't understand. They can be used to create alternate viewpoints to investigate and improve a situation for the good of the team.

For more information/advice: If you are a LinkedIn user and a member of the Scrum Alliance, there is an interesting discussion about this in the related group.

JUnit starter guide...

For anyone trying to figure out TDD, especially unit testing, JB posted his JUnit starter guide for free today.

UX and Agile, how do they mix?

So there has been some discussion lately about usability and agile, and whether the two work well together. Alan Cooper's keynote at Agile 2008 was a rally for the agile community at large to start folding in the UX role and taking advantage of it. I spent 7 years in the usability field, and hearing him speak on this almost made me want to get back into it. This topic has also come up recently in LinkedIn group discussions and also with Mike Cottmeyer at VersionOne.

I commented to Mike's blog post about Agile and UI Design with this summary: "Agile engineering practices (especially TDD) are supposed to reduce the time between writing code and finding functional bugs. User experience skills are supposed to reduce the time between writing the code and finding usability bugs..."

Something we have to recognize is that user experience is a greatly misunderstood and undervalued field. Like Agile, UX folks have been struggling for a few years (since the '70s in software) to get the masses to understand the need for a user advocate and user modeling. Agile has started to push the concept of getting close to the customer, but some people think that this is enough to bridge the void when in fact it is not.

If you are working on a simple commercial website, then there is a good chance that you can be a follower of others and simply borrow from the best. This assumes that your leaders either lead because they have the most usable product, or because they spent a lot of money on usability studies.

If you are working on a true application, say an operating room management system (something I did for 4 years), you have a different view to usability. It is one where a system can functionally do exactly what it should, but a human might make an error using the software that can lead to a patient death. A decimal point error in medication dosage can equal death. A unit of measure error can equal patient death. This is a place where usability is imperative to the process. Most systems/projects fall somewhere in between these two points and usability is a differentiator and an added value, but not necessarily a requirement for entry.

UX folks are experts at understanding what the user can't understand themselves. Just like agile teams are taught that customers can't explain all the requirements up front, UX folks know that users can't understand how the screens should look/work. But there are scientific ways to figure this out by working with and observing users. Remember that the "customer" might be the head of the OR in a hospital making the decision to buy your software, but they won't be using your system like the nurses and surgeons directly in the OR. The UX person quickly realizes that the colors on the screen need to be changed for the lighting in the OR, even if during the sales demo they look ridiculous. UX is about uncovering user behaviors that aren't obvious to the developers, product owner, or even user themselves.

Can these folks fit into an agile team? Definitely. They are kind of like an SEO expert that reviews everything going out the door and mentors the team on certain standards and consistencies that need to be met. They are also like the lead architect that needs to look across the backlog and start creating a high level plan for system flow and structure. They can't just whip out screens on the first day of the sprint and reach perfection. UX sometimes requires focus groups and real user testing (think one-way mirrors and mouse recording). These are the sessions where the size and color of a button can be changed slightly to reduce error and increase efficiency.

My summary is this: there's a lot of gray area today on how much up-front design should be done on an agile project. I believe that same issue will arise with UX resources. UX people are going to struggle to fit in the agile culture because of the nature of their role and difference in speed between the agile team velocity and the delay of setting up controlled user tests. But, they will figure this out over time. It's more important to involve them early and let them see as much as they can so they can start adding value.

Update (11/26): Here's a great example of what usability can add to the process. Here's a great example of specific tasks the usability role can add value to.

Low Hanging Fruit...

I've worked with product owners or customers that complain that marking an item on the backlog as low priority instantly sends it to the graveyard to live for eternity and never return. They know that the branding, design, and usability issues on the site are cheap to fix but are not important enough to prioritize in isolation.

Solution?

When you have enough, group them together. Have a story that is "improve the experience of your sign-up process". Lump all those design, usability, and branding bugs into one story and make the team bang through them. (Of course, maybe they shouldn't have gotten through acceptance in the first place, but I needed an example and this reflects reality in a couple places I've worked.)

Another option: When the team picks work for a sprint, they pick up a few big stories and typically have a point or two of left over space. Make them pick up some cheap stuff off the bottom. Have them pick based on closeness to other stuff they are touching. Or have them pick based on value. After all, getting $10 of value for 30 seconds of work is slightly better than getting $1000 of value for over an hour of work.

This was the idea behind the first part of my comment about backlog prioritization on vikramadhiman's agile diary blog.

Screw the Practices...

I was at Agile 2008 with several people in a session with J.B. Rainsberger (past Gordon Pask Award winner). He threw out a very interesting theorem, which I will try to channel here (apologies to JB for stealing and tweaking):

Every agile adopter is going through a journey of stages, and we might observe the maturity of an agile coach or practitioner by this path or even predict where the agile community is going. It points out that we continuously evolve our view and flip between pragmatist and purist views (the topic of the session we were in).

1. The Agile Convert attempts to learn an Agile Practice.
2. The Agile Purist follows the Practice to a fault.
3. The Agile Pragmatist starts to realize that the Practice doesn't work in all situations and pursues the Agile Principle molding the Practice to their specific environment.
4. The Agile Purist follows the Principle.
5. The Agile Pragmatist starts to realize that the Principle doesn't work in all situations and pursues the Agile Value molding the Practice and Principle to their specific environment.
6. The Agile Purist follows the Value.
7. The Agile Pragmatist starts to realize that the value doesn't work in all situations and pursues the ??? molding the value, principle, and practice to their specific environment.
8. The self-actualized Agile Follower realizes that Agile is the embodiment of some higher understanding that can be applied in part or whole to any environment to help deliver more value… they forget the boundaries of values, principles, or practices… these are just simple mechanisms to enable the education of agile to others.

Having communicated this to a few people since then, the one piece of feedback I find that people agree on is that this path happens at different rates for different topics in agile. You might be at step 2 for TDD and step 6 for iterations.

J.B. was predicting it won't be long before various agile leaders start bringing up ideas that go against where the community would have initially expected to go. I wonder if Arlo Belshee might have already done this with his "Promiscuous Pairing" and "Naked Planning" concepts (which is why he won the Gordon Pask award this past year at Agile 2008).

Interesting theory. It resonated with me. It reinforces that it is not about the name of what you are doing, or even how you are doing it. Agile is a philosophical approach to delivering a better working environment that produces a better outcome.

Agile 2008 was over a month ago... why am I writing about this today? Because Jeff Langr reminded me of it when he recently pushed back against the Chicken, Pig concept for standing meetings.

Another note: steps 3, 5, and 7 above remind me a lot of the "Ha" level of Shu, Ha, Ri as conveyed by Alistair Cockburn awhile ago. Step 8 feels like Ri.

Iteration/Sprint != Waterfall...

This discussion about code reviews has triggered a bunch of thoughts in my head. For now, I'll stick to the loudest one.

Sprint boundaries are supposed to provide transparency to the customer and the business, not be a scramble for shippability. The end of the sprint shouldn't create a flurry of check-in activity leading to a pile of new tests to find previously unknown bugs (which can't be fixed in time for review).

Instead, the daily meeting/scrum should provide a heartbeat for the team and every day or so, stories should be completed. Adopting agile should convert you from yearly releases to quarterly releases, to monthly releases, and maybe even weekly releases.

Have you ever flipped a rock in the woods and watched all the critters scramble and disappear? This is not what the day before sprint review is supposed to be like!

Instead of thinking of the sprint review as a point in time to have stuff working for demo and approval; you should be thinking of it as a time to have the customer, product owner, and team assess progress and determine if the upcoming plan, priorities, and communicated delivery dates are still realistic.

Here is another great list you can use to spot an agile team.

Story Points and Estimation...

It's hard enough to get the developer, analyst, customer combination to work together as an agile team if they aren't used to it. It's even harder to mature to a point where creating a backlog with properly authored stories comes naturally. (Remember that stories are supposed to be independent, negotiable, valuable, estimable/small, and testable)

What about estimation?

Estimation can be a tricky thing, but the agile community has come up with a structure called story points to simplify this and normalize the human error. I was recently involved in some good conversation in the VersionOne user community around how to sell the story point concept to others, and I found a great explanation of how poker planning contributes to this process.

Note to Ulisses Courel, I'd rather my infinity card over your coffee card any day! ; )

Improve yourself...

In a few weeks I transition from coaching our tech group within agile values, principles and practices, to training the "product" groups on many of the same concepts and starting to fold them into the agile culture. I realized pretty quickly that it was a good time to reflect on my past two years and think hard about how I approach this effort. Rather than easing into it, we're taking a more formal approach... and as a coach, I need to get along with people as I spend more time with them than I have in the past.

So, time for a personal retrospective.

At the end of a team retrospective I facilitate each month, I handed 3*5 cards out to each member of the tech team and asked them to honestly and brutally tell me at least one good thing and one bad thing about me. They looked at me funny, but after I explained why I needed this they asked for several more cards (funny, ha, ha).

What I got back was insightful. I'll spare you the 34 individual comments and share the most common:

• good: you don't inflict change
• good: you hear our concerns and adapt, you don't force us to do it by the book
• good: you presented the philosophies behind it instead of telling us just to do it
• bad: you talk to fast and cram in too much
• bad: you sometimes try to hard to help people and step on their toes in the process

There were many other insightful comments including the humorous remarks of my nerdiness, male pattern baldness, etc.

What's my point?

I'm proud of the fact that these people trust and respect me enough to give me honest feedback. I'm proud of myself for asking for it even if I felt like hiding in the corner as they scribbled on cards. I hope I have the guts to absorb this feedback and improve my coaching skills.

Peer reviews can be an amazing way to improve yourself if you are open to changing.

Do you have the guts to try it?

"No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today." - Kent Beck

Puppy vs. Pitbull...

The puppy approach: Every time this person comes to you and asks for something... they stick their head through the door slowly and kindly ask for permission to enter. They give you puppy dog eyes and you know they need something. But they are always so stinking nice that you invite them in to talk. They carefully explain what they need, and they work with you to mold their needs to something you can provide. When you help them out, they tell everyone about it including you. You get credit. It's almost like every time they enter the room, you just want to hand them a treat because they make you feel good when they wag their tail and shower you with appreciation.

The pitbull approach: You walk quietly by their desk hoping they don't notice. They remind you of your walks home from school many years ago when that dog ran towards the fence barking at you. You always wondered if the chain on their neck was long enough for them to hop the fence and take a chunk out of your arm. You feel fear and you always brace for the worst. This co-worker charges into your office, even when you are very busy. You can be fixing the fire that will keep the company out of trouble, but this person's stuff is always more important than everyone else's. You've tried dropping your work to help this person thinking it would make them appreciate you more, but it only led to them coming around more. They never give you credit for your work; they only complain about what you don't do for them. At the end of the day, you can only do your best to avoid them or figure out how to make them go away.

These are extremes, but which are you known more as?

Unfortunately there is a small percentage of people that are proud to be pitbulls. After all, they get quicker results. They get what they need from someone. Who cares how much damage is done if they get the desired result?

What do I have to say to pitbulls? I hope you enjoy getting just enough to fulfill your needs. The puppies around you get a lot more than they expect or ask for. You see, most people like puppies and will do stuff just to see the puppy happy. So, as a pitbull, you get exactly what you want... nothing more. The puppies are getting all the love.

Don't feel so special now, do you? By the way pitbull... over time, people learn how long your chain is and figure out how to stay out of your reach. You will actually lose your ability to get what you want over time. Good luck with that!

Sustainable Pace...

I hate that in the past I've worked in an environment where overtime or week-end work was a badge of courage. Where the pager was rotated and the holder expected a page every night at some point. And this was commonly accepted. People didn't question whether the pager should have been able to go a week without ringing... they were used to knowing it would go off within the next 12 hours.

Of course, the company didn't require overtime... it didn't condone burning out... but we also didn't force someone who stayed up until 3 am to come in late (or not at all) either. Where does the line between volunteering and demanding begin/end?

Well, here's a post that I like... it's a debate I've poked at for over 5 years and homebrutrout says the piece very well.

Downstream testing...

No, no, no.... and no.

The word "downstream" and "test" should not be near each other in a sentence.

Kevin Rutherford had an interesting post about how better testers allowed the developers to become lazy. As humorous as this was (and I can definitely see it happening), I started to think about what he was saying. Especially as he asked: "What did you do to harness the skills of your great testers so that they constructively support your great coders?"

I got to thinking about the flaw and whether or not it was obvious to him. Even if it was obvious to him, maybe it wasn't to readers of his post. So I had to comment.

Tests need to be run before the story is accepted, reviewed, and closed. If you work in an environment where a testing team runs manual scripts to do testing, then this is included. If this means that your story isn't closed for a while, then so be it. If this is painful to you, then work as a team to shorten that time frame and remove the waterfall.

Paul Richie had some similar thoughts (thanks for the reference Paul).

Code reviews?

Alex McMahon has a great post about the appropriate time to do a code review. Some very great questions and some very interesting proposals.

I wanted to leave a comment, but "you must be logged in". So, I'll put them here.

• Why does your code review take so long? Should it?
  
• Pair programming, though very effective and valuable, is difficult to sell or get working properly... but why can't review be a rotating thing. Spread the love, normalize your review approach.
• There are several comments in the post skirting the testing topic, but nothing blatantly stating it. Tests should pass first, then check in. If the tests pass, then any refactoring caused by the code review should be easier and lower risk. This safety net will allow you to check in first and then do the code review second.
  

Ambler rocks...

He's an industry leader. In my limited experience, there is very little I can add to this. I can't say it any better. I can only sit at the back of the room and look at everyone else to see if they are getting it as clearly as I am.

For those of you who haven't seen his work before, here are my favorite excerpts to entice you to read the full article:

Starting a project- "You don't need anywhere near the level of documentation, or detail for that matter, that you've been led to believe over the years. For example, although you'll likely be asked for an initial estimate, you don't need to spend weeks or months doing detailed requirements, analysis, and design so that you have the input into some form of complicated estimating process. A ballpark estimate will often do, and frankly it is just as accurate as anything you'd produce counting function points or following COCOMO II."

Should you do a project? "An important consideration during Cycle 0 is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organization can tolerate the successful delivery of this system."

Cost? Deal with it- "Agile or not, someone is going to ask the questions: "How much is this going to cost?", "How long is this going to take?", and "What am I going to get?". The real answers, respectively, are "As much as you're willing to spend," "As long as it takes," and "Whatever you tell us that you want," but few organizations are willing to tolerate this level of honesty and instead ask for "exact" answers. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy to show for it. I believe that it is time to admit that we can't predict the future accurately and cast off the shackles of traditional thinking."

Tests after story closure?

As a customer I tend hang out in the VersionOne google-group user forums. Sometimes I find myself providing agile coaching feedback unrelated to the tool. Today was one of those days.

A peer was asking questions about the tool when running tests. But their team regularly closed stories in one sprint and had the testing team test that work in the next sprint. I had to share the following feedback:

"Flags are raised in my head whenever someone says that their testing team works on the prior iteration's work.

This is problematic for the following reasons:
- the development team has moved on to new work
- if the testing team finds something, they must "interupt" the development team to go back and fix the bug
- this throws off velocity (or it is gamed and false)
...and this whole concept feels like a mini-waterfall since it ignores that the product should be "potentially" shippable at the end of an iteration.

What we did on my last team was have a CI (continuous integration) build that ran every night separate from the check-in test/build process. If everything passed, then the test environment was automatically updated in the middle of the night. Thus, our test team was part of the sprint team and they tested stories as they were built. Stories were not closed unless Dev, Test agreed AND the customer accepted them. This removes the pitch-over and splash-back feeling.

It can also remove a lot of interruptions and debates that pit QA against Dev.

Having said all of that- you may not technically be able to do this today. Or, your culture may not be ready to truly be agile. As a pragmatist, I say whatever you are doing is better than not. I just wanted to throw this out there as a potential goal to strive for. "

I'm glad I said the last part... my peer responded with appreciation but noted that they were working through the technical hurdles to creating an automated build.