Your Agile Isn’t My Agile
I’ve been wondering for quite some time about just what exactly is Agile. I’ve been a team member on Agile teams and a consultant (call that an agile coach or consultant…it’s the same thing to me) and worked in small to medium-sized to enterprise-sized companies.
As have many others, I’ve seen different interpretations of what Agile means to different people in different environments. From my experience, people generally consider Agile to be a ‘state of mind’, a particular practice or a set of practices. I worked with a team in the past that considered themselves to be ‘very Agile’. They were Agile enough to have a 4 day sprint after a 2 week sprint because all the work couldn’t get done in time. I’ve worked with teams that had development and testing sprints. I’ve worked with teams that had programmers that would account for re-working bad code in any story that was going to require changes in those areas.
Does that describe what Agile is?
I dunno.
The interesting part of those 3 stories is that the environments and culture created those versions of Agile, for the lack of a better phrase. The 1st team that couldn’t seem to finish work in any sprint thought they were really Agile. They thought this because there was no impact to missing the sprint commitment. It didn’t really matter when the work was done or when it was released. Using ‘sprints’ was just a way to break the work into 2 week chunks. I’d call that iterative, not Agile.
The 2nd team I mentioned was in a larger company with very strong functional silos that were stronger than the team itself. Some call that ‘mini waterfall’. I don’t know what I’d call it other than that was the best these guys could do at that particular time.
The last team I mentioned was one of the best teams I ever worked with. They all got along well, they all understood the application from a technical perspective and a user perspective and most importantly, they gave a damn. They were a passionate group of people who challenged each other and just liked doing what they were doing despite the constraints they had as a result of their environment.
So is Agile a state of mind? A single practice? A set of practices? A couple of years ago I wrote a post about how I learned organization culture is the most important aspect of becoming Agile. That seems to still ring true for me.
To me, Agile is like the old Lexus slogan from the 90′s. ”The Relentless Pursuit of Perfection”. I went to the Toronto Agile open space this past weekend. That’s what Agile is all about. People giving up their free time and time with family and friends to share ideas and learn about something. There’s something special about these people. There’s something intrinsic that drives these people to be better.
You can’t package that up and install it into an organization. You can, however, package up and install a set of tools and practices into an organization.
My Agile is the former, yours may be the latter. And that’s ok. Just be aware of what you and your organization is capable of and choose your Agile adoption path to align with your culture and values.
Your ‘Done’ Isn’t My ‘Done’
Last night I finished my taxes. I tweeted I was done. Not developer done, but done done. Lynn McKee pointed out that even my impression of ‘done’ was open to interpretation. Does ‘done’ mean finished with the calculations? Filed? Received refund? Being audited? Filed mine and my wifes?
That reminded me of a recent sprint planning session our team had. Our product owner considered customer value and done as being able to clearly show separation of presentation and data layers in a new service we’re developing. I considered customer value being showing the user of the new service a simple interpretation of the data being shown through the service. Very different perspectives. Read more
Is it Dysfunctional to Sit at Your Stand-up?
It’s called the daily standup for a reason. It happens daily and you standup. Why do you standup? You stand-up in order to keep the meeting short. Each team member should answer 3 quick questions:
- what did I do yesterday?
- what am I planning on doing today?
- what’s in my way?
I’m amazed at all the grumbling I hear from new teams I work with about these evil Agile people are forcing you to stand-up when Ken’s book clearly says you don’t have to stand! Actually, one of the team members actually threw that in my face so I re-iterated the purpose of the stand-up to them.
Bob Hartman tweeted me with a great idea a while back. Why not let them sit? Simply plot along how much time they take to do the standup when sitting vs standing. The team admitted to me that when I wasn’t there they would sit down so I didn’t want to be forcing them to do something they were against. Isn’t it a bit more Agile to let the team do what works for them as opposed to being worried about breaking the golden rule of standing up?
Here’s the observations after a few iterations of comparing sitting vs standing. To put some context around it, our team isn’t completely co-located. We’re all in the same general area and a few sit next to each other but since we’re in a huge environment we agreed (as a team!) to do our standups in a neutral area so we don’t bug the people around us. Oddly enough there is a waterfall in the building, that’s where we do our standups.
When standing:
- people drift further apart as it goes on
- body language is terrible, they seem to be there out of habit, but they do still get value out of it without really realizing it
- they address me, the coach and temporary Scrum Master
- averaging about 12 – 15 minutes
- each person answers their 3 questions (except for blocks, I usually just recognize them and so do other team members)
- seems very regimented in nature and not natural
When sitting
- they sit closer together
- body language is MUCH better, they actually lean in towards each other
- they address EACH OTHER. Sometimes they look at me but they are more team focused for some reason
- averaging 15 – 20 minutes, still followed by follow-up conversations
- they do get sidetracked by trying to address blocks and I have to reign them in more often to stay on track
So far the experiment is showing me that they are getting much more value out of sitting than standing. Sure they are taking a few minutes longer and I have to pull them back on track sometimes, but they are much more engaged and working together while sitting.
I’m sure part of what helps with sitting is that we have to walk to another part of the building as we don’t have a dedicated team room yet so I’ll follow-up with another post once we have that environment.
Do your teams sit? Would love to hear your stories.
