Agile Just Don’t Go ’round Here
One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?” After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”
A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“ There seems to be a clear delineation between these 2 camps.
I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.
The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile. Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.
Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.
So underneath the skepticism and FUD, what’s the REAL problem? What are people afraid of? Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:
1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”
2) Agile won’t work here, everybody works on multiple projects at the same time.
3) Management tells us we HAVE TO launch with all these features on this date.
Hmm. So what do we do? Where’s the Agile checklist that allows us to fix these problems? I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality. In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done. The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.
I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”
While our topics do differ, the underlying tone is the same. Organizations needs to understand what being Agile is. They need to look to the manifesto, not to the Nokia Scrum test or a checklist. They need to un-learn what has been instilled through so many years of the command and control approach.
AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about? what are your challenges? how can the knowledge and tools I have solve your problems”
Lately that approach is working much better and I find people who want help are more likely to accept help.
A Week in the Life of an Agile Coach – Wednesday
9:30am - Oops, overslept a bit, but yesterday was pretty busy so I’m glad I got some rest. I head over to the A/V room, grab a projector, stop at the cafeteria to grab some wake-up juice and then across the building for our retrospective and iteration planning.
10:15am – We usually skip the standup on iteration planning day and since the team needed to travel to the head office for the demo yesterday, we all agreed to do our retrospective today. Normally we would go right into the retrospective after the demo, but this worked better for the team and they suggested it and all agreed to it.
Retrospectives are new to the team, so we’re following the typical “what went well, not well and what to try” approach but we always start off by reviewing what we wanted to try from the last retrospective and see if it was still a valid improvement and if so, what was the progress.
We finish the retrospective, have a quick break and then get into planning. The first 2 or 3 sessions were pretty painful but everyone is starting to get a better feel of how to interact with each other. The team is having a hard time breaking out one of their stories so I suggest that they create one general development task, pair up when they do it and then jot down some notes while working on it. I figure this will help them for the next time and give them some ideas about how to break up future stories and they generally agree.
I offer to enter all the tasks and hours into the tool but mention that at some point it would be ideal to rotate that duty each iteration between team members. That will help keep everyone interested and remove their dependence on me, plus it’s pretty simple and everything I do for the team is something they can’t do on their own. This is especially important given the strict waterfall background where they’re just used to being handed tasks and relying on a PM to do this type of work.
2.30pm - After ordering on some pizza for lunch, planning is finished and the team gets to work. Just before we leave the planning meeting I remind the team to start on the highest priority story first and make sure that they don’t start all 6 stories they committed to like they did last time. They were able to recognize that they felt rushed at the end to finish everything and this approach allows them to finish something and move on as well as allow the business the opportunity to pull out a lower priority story if something more important popped up. If the team hadn’t started the story, there’s no waste to worry about.
3:30pm - I’m feeling pretty worn out from the previous 2 days and with a 4 hour training session in the morning, a mid-town meeting after training and back to the satellite office after that, I decide to call it a day. The team had agreed that core working hours were 10 – 3, so I check with them before heading out to make sure there isn’t anything else they need.
On the way home I give my mentor a call to update her on the team’s progress and I ask her if she will attend the training tomorrow to evaluate me and point out how I can improve the delivery of the class. She gives me an update on progress with the team environment we’ve been trying to get setup for a couple of months now and progress on the new team that is starting soon.
Sometime in the evening – I take some feedback from earlier classes and, based on the audience I am expecting tomorrow, I try and come up with some other examples that might be more relevant to drive the material home. I toss down some internal blog post ideas, pack up my class materials and head off to bed.
A Week in the Life of an Agile Coach – Tuesday
9:15am - I arrive at the office, check my email and the general Agile support box. Our stand-up is happening soon so I login to our tool and check out the burndown and see what tasks are in progress.
10am – standup. The team wasn’t really happy about standing up at the standups from the get-go so today is the first day we’re actually sitting down. I have to remind a couple of the guys that they aren’t reporting to me so there’s no need to face me and report their status. A couple of guys get into a discussion that doesn’t belong in the standup so I ask them to let the rest of the folks finish up and then whomever needs to be involved in the side discussion can stick around afterwards.
10.20am - The Standup finishes a bit later than usual but since it’s demo day the team wants to make sure they are understand what they need to do before 2pm. Myself and a couple of other team members walk over to the environment support folks and ask that they not allow any changes into the environment we’ll be demo’ing in today and we get the lead’s mobile number so we can call him in the event there is any issue.
11am – We pack up and drive down to the head office, 1 team member stays back to handle any last minute issues. Today’s the first day the team is doing a full demo to about 40 – 50 people including some stakeholders, observers not directly involved in what we’re doing and, of course, our product owner. I wanted to make sure the team had the chance to experience this since most of the time in traditional settings stakeholders don’t get the chance to meet the team.
1pm – We get to the boardroom for the demo, setup the projector and go over the stories with the product owner and the general script for the demo. The Product Owner asks me how we are supposed to keep the demo from going off the rails just in case there is too much feedback so I let her know that when the demo kicks off, we’ll set that expectation properly. Feedback is great, but I remind her that it should be in context of what we are showing them and other feedback can wait until after the demo.
1.45pm - 15 minutes to showtime and our QA environment goes down. Uh oh. A quick email and phone call and at 1:58pm we’re back in business.
2:15pm – After the last straggler stumbles in we get started and the product owner welcomes everyone and introduces everyone to the team. As the Product Owner is going through the stories (we had given her a demo previously to get the stories accepted) one of the QA guys on the team notices a problem so I grab an index card from my utility belt and write it down.
3pm – The demo finishes up and I have 4 or 5 new index cards with questions and feedback. Not too much, but some ideas we’ll want to prioritize against the existing backlog. A couple of folks stick around for more questions and I have a brief chat with the Product Owner about some of the new cards.
4pm – I head over to chat with my boss and let her know how the demo went. She asks me to setup a couple of training sessions for the next week and we review a blog post I wrote for our internal blog.
She gives me an update on a new team that is forming and will be starting up soon. Since my team is already doing well, taking on mentoring a new team won’t be stretching me too thin but we talk about the risks and how we can help each other out with it.
5.30 - After a quick check of the Agile support inbox and couple of quick chats with a few other folks wanting some advise, I head out for the day.
