New to agile? Learn how to fail well

Is success or failure really a choice?  I don’t think it is at all.  Pretty much no one chooses to fail.  Unfortunately, we can’t just choose to be successful either.  What we CAN choose is to try to make a success out of a failure!  The old saying “Make lemonade out of lemons” really is a good way of looking at things, especially for agile teams.

Agile teams will have times when they “fail.”  I know a lot of people dislike using the words “fail” and “failure” when talking about team results.  I’m actually pretty tired of that argument because I don’t think it helps anyone.  I’d rather call a “poor result” a “failure” and acknowledge we can and will strive to do better next time.  As I say during workshops I facilitate, “I am blunt and reality based. Sometimes that means I will say things which you won’t like to hear.”  I don’t call teams “failures” or anything like that.  That would be namecalling and that is never appropriate.  However, calling results a failure is correct and leaves no room for interpretation.  I find being blunt in those situations to be more useful because teams then must face the reality and not try to sugar coat it as “not being all that bad…” [Read more...]

Agile pondering: Why use an agile approach?

The theme of the blog this month is “Getting a Fresh Start.”  In order to get a fresh start it is important to know WHY you want to do it!  I’ve seen many presentations over the years about why agile is something a software development organization should use.  I’ve seen this sort of presentation called “The Business Case for Agility” and several other names.  I’ve seen people walk out of those presentations, go back to their organizations, implement agile – and fail miserably.  Clearly having a reason for using agile is not the only important thing.  I think many of these presentations are presenting some possible reasons for using agile, but they sometimes miss a key point – WHY are those reasons important.  In the spirit of Agile For All’s second agile belief, I’m going to try to explain WHY some of the popular reasons are important to consider. [Read more...]

Agile antipatterns: Agile burn-down chart roundup post

Do you want to see several different ways agile and scrum burn-down charts can lie?  If so, you are in the right place! This month I went on a burn-down chart craze and posted several blog entries about the different ways those charts can lie to us or expose us to team dysfunction.  In order, the blog entries are:

The whole series had a LOT of web hits, so clearly I’ve touched a nerve.  Good luck improving your agile or scrum metrics.  Sometime next year I’ll do a series on metrics in general.  Our current state of the art for agile teams is pretty pathetic because the data can be skewed so badly (as shown by all of these blog posts).

Until next time I’ll be Making Agile a Reality® by helping people understand the real meaning behind their agile burn down charts.

Agile antipattern: Another burndown chart that lies!

sprintburndown6That burndown chart looks sweet doesn’t it?  The team finished the iteration on time.  What could possibly be wrong.  Well, a lot actually.  Notice that one day this team completed a tremendous amount of work.  Do you ever see teams really do that?  It certainly could be a symptom of allowing large stories and they just got completed that day.  But I’m not buying it.  When I see a chart like this I immediately think the team is hiding something.  Most of the time they are hiding that they changed the scope for the iteration.  They saw their trajectory and simply said we have to remove some scope in order to have a successful iteration.  DO NOT BE TEMPTED TO DO THIS!!!  There are far better ways to fail.  If a team starts to believe this is ok then they will use it as a fallback position too often.  How do I know this is the situation?  Easy, I look at the burnUP chart.

[Read more...]

Agile antipattern: Changing the definition of done

sprintburndown5Ever see a burndown chart like the one to the left?  I’ve been on a big burndown chart kick lately and when I saw this one I just couldn’t resist using it.  This one is a bit different from my previous blog entries here and here.  This burndown chart is a release burndown rather than an iteration burndown.  It sure looks like the team was incredibly successful and finished early, right?  Wrong!  What this burndown actually shows is all of the stories being “done” and the release not actually occurring for several more iterations.  How is that possible? [Read more...]

Agile pondering: How does a highly mobile agile team of 1 work?

ponderingIn my last post I gave you insight into how I do my work as an agile team of 1.  What I didn’t mention is I am highly mobile.  I travel a lot to other cities and even when I’m in my normal city I have meetings all over the place.  How do you remain agile if you don’t always have access to the same environment?  Let me tell you, it isn’t very easy.  It requires lots of help from tools which work without me having to think about making them work.  It also requires forethought on how your normal workflow will occur.  Finally, it requires knowledge about how certain tools function so they can be set up properly. [Read more...]

Agile pondering: How does agile work with a team of 1?

See that picture off to the left?  That is me and my agile team!  It’s not a bad picture, but there appears to be something missing, right?  Where’s the “team” part of me and my team?  Well, you’re looking at it!  That’s right, I am a team of 1 for almost everything I do.  This has unique advantages and challenges over larger agile teams.  My goal with this blog entry is to give you some insight into how I make it work by telling you how I do it, and more importantly, the principles I try to keep in mind.  The idea for this blog entry came from a comment on a blog entry about Simple Agile back on October 6.  I have been doing some variation of what is written below for the past 18 months or so.  Things have changed a bit over that time (some examples are given) but I’m still basically doing what people would recognize as Scrum.  For those of you into Personal Kanban, I have a bit of that in here too.  Let’s see, maybe I actually do Personal Scrumban# (anyone who gets that is way too much of a Scrum/Lean/Agile geek!).

[Read more...]

The 7 Deadly Sins of Almost Being Agile presentation from Agile 2009

This presentation was originally given at Agile 2009 in Chicago.  Richard Lawrence and I wanted to give teams a bit of hope if they weren’t quite doing agile.  In order to do that we gave a presentation helping them understand some of the basic issues.  However, we also recognize every organization is different.  We didn’t want to give cookbook answers when the kitchen wasn’t always the same.  So instead we gave attendees a way to help reach resolution on their problems.  This is based on the Thinking Process from the Theory of Constraints.  Below is the presentation from SlideShare.  It mentions creating clouds as exercises.  You can download the handout given to attendees in order to learn this for yourself.  If you want to download the presentation please email me.  I would rather send you the file directly.  My email is in the sidebar to the right.

Agile antipattern: Burndown charts that hide the truth

sprintburndownSee that burndown chart over there to the left?  It looks beautiful doesn’t it?  It is an actual burndown chart with no made up data.  It looks like this team is kicking butt and having a great sprint.  Unfortunately, the chart lies!  It turns out this team is actually in difficulty and in fact are unlikely to make their sprint commitment.  Are you confused yet?  I know when I do this exercise during agile courses the course attendees all look at me like I’m crazy.  I assure you, I am not crazy.  This team is in trouble, it just doesn’t show up in this chart!

[Read more...]

New to agile? Give thanks!

turkeyHere in the United States we will be celebrating the Thanksgiving holiday on Thursday, November 26.  If you are currently on an agile team you may want to consider giving thanks a bit earlier!  My thank you list would definitely include:

1. Thanks for the organization allowing us to be successful with an agile development framework.
2. Thanks for giving the team the support needed from all areas of the organization so value is delivered each release.
3. Thanks for giving us the training necessary to be successful with agile. [Read more...]