When people put on their agile hats and go through their agile check list they lovingly purr over their test driven, pair-built, continuously integrated codebase and pat themselves on the back as the stories drip through to Done like honey from a spoon. The devs cool down post codefreeze playing Quake, the last story is UATed and hey presto that honey is out in the wild. Where the bears live. And the bugs, and boy do bugs love that honey!
In an ideal world there won’t be any problems in production. In an ideal world there’s a great soundtrack playing while the dev team, PMO and the business high-five one another in slow-mo.  If you’re talking about a complex enterprise system even the most able teams will produce code that encounters some problems. Test driven development and pairing will minimise production issues that’s true but there’s no practice that eliminates bugs and missed functionality.
So what part of the agile world deals with issues in production? Its going to be either a support analyst or someone playing that role. In the enterprise the support analyst will be part of a larger support team. The support team will investigate problems raised by the business. They’ll analyse the issue, quantify the problem and raise a bug for the dev team to fix.

So now we’ve discovered the support tribe and after careful observation we see they survive by hunting bugs and gathering information. They seem to make a lot of noise but communication with this tribe is proving difficult. Lets enable them with some agile tools!

Bringing agile to the front line

Task Board

This is my second day of the second week of my first month at my new job.  The differences between me and the other Scrum Master are really style at this point so it doesn't make sense for me to sit in on all of their meetings anymore.  I've been focusing on the Business and the process they go through today to get work done.  Boy, it's a mess!  There are, by title alone, about 3 Project Managers for just about every area of the business and they don't seem to talk to each other much.  The PM at the outer most realm of the actual delivery team doesn't really know when or who works on their request and they appear to communicate solely via email with questions like "What's the status of x?" and "Is anyone working on Y?"  The most important thing for our teams right now is to find out WHO is doing WHAT and WHEN are they going to be done.  There is work being done already but it's unclear who has been assigned or what their schedules are.

Using my connections through LinkedIn, I was able to find out more than the Product Owner candidates resumes told me.  Our interviews for the new Product Owner are coming along but they won't start by the time we kick off our first sprint.  In the meantime, I've created a draft backlog with Business Owners, Resource names, Roles and requested launch dates so we can begin collecting every project known to the team.  We'll need to discuss what work must continue, what work should be transitioned.  As busy as it seems and chaotic as it is, this is when I get excited because bringing clarity to chaos is my specialty.  Bring it on!

We want to hear about what's going on at Agile2010 and we want to hear it from you. Agile Journal will be giving away 5 copies of Mario Moreira's book Adapting Configuration Management for Agile Teams to the top 5 people who blog about Agile 2010 this week. 

All you have to do is be a registered member of Agile Journal and then post your blog here on Agile Journal

http://www.agilejournal.com/blogs/write-a-blog/adminhome/

The Agile Journal Video crew is on the road again. Today they are in Orlando Florida at the Agile Alliance Agile 2010 conference.

If you would like to get your agile story on the air just look for them in the expo hall and follow us on twitter @AgileJournal

Ever since I came across Agile methods some years back, I have become a die-hard fan of it. I wonder, why Agile is not been accepted as Industry standard for Software development, even after having many advantages over other methods.

The answer to this question according to me is reluctance to CHANGE. Agile requires difference kind of mind-set; it is a paradigm shift as compared to traditional managed projects. Traditional Managers do not want to change from the way they are working for years i.e. they do not want to come out of there comfort zone and explore new ways to success.

I have come across many people, who by name of ‘Short Release’ become uncomfortable with Agile. I do not have any statistics, but I think, unless Agile is enforced by Customer, there would be few people / project / company, who would advocate Agile.

-Vinayak Mehta

So it's the first day on the new team.  There are already two teams sprinting under a Scrum Master.  I've worked with him before indirectly and he's got the right experience and talent so it's going to be a great partnership once my two teams are in flight.  He's not a push over, not shy, and he's seasoned enough to know when he's hearing a bad idea but also open to hearing them before he says it's a bad idea.  We're going through the resource plans for the other two scrum teams that I'll be taking on.  I'm already planning for a Scrum training session for each of them but I'm going to play it by ear before i decide if both teams will be in the same session together.  We have a few openings on each team that we need to settle first; some hires, some transfers between teams.

The first two teams have already taken on names for their teams.  Their stand ups seem to be mature for a new team.  The team is on their feet for at least 15 minutes.  Everyone reports in the standard format; What did I accomplish since yesterday? What will I accomplish today? Do I have any roadblocks or impediments in my way?  They even report if the Scrum tools are accurate for our burndown charts.  They spend another 15 minutes or so (officially NOT part of the stand up) going through each story in a bit more detail to catch up on any detailed discussion that wasn't covered in the stand up.  They currently use Rally for their backlog but I'm not sure if that's consistent across the department yet.  I'll be looking into their backlog and tracking tools more this week.

My Product Owner is actually leaving the company in a few weeks so there will be some transition necessary if I dont' get someone by the end of the week.  I also met two of the Delivery Leads (new role for me as well as the company) and the Dev Manager to discuss our working relationships and our goals.  We're still getting to know each other but since we all came from the same company before this one we already have some "war stories" to reminisce over.  My meeting with the PM that I will be replacing was much faster than I would have hoped but I'm sure it won't make much difference in the end.  Since the teams aren't formed yet, the work is being done by random resources with SME experience based on their Non-Discretionary status until we have fully functional scrum teams to begin working on a backlog.  This leads me to believe that as soon as we complete our first sprint, we'll already be outperforming what was done before!  I'm going to spend some time in the morning detailing a plan and begin scheduling the meetings for each milestone. Just a brainstorm in my next steps... I'll need to gather as much knowledge as I can about the architecture of the systems and the business to see the big picture more clearly.  Even if I don't have a new Product Owner in place, I'll start pulling together a draft of the backlog and begin grooming the Business Leads that the Product Owner will interface with so I can brief them on how the scrum looks and feels.  I may even do a quick Scrum session just for them.   I'll be traveling to another site this week to confirm the team members and the openings. I'll be traveling with my Scrum Master partner, Delivery Lead, and Dev Manager so if there is any room for process improvement or efficiency opportunities we'll probably spend the train ride discussing those.  So I've just built my own two week sprint!

I sit at my desk for almost the last time today.  I've been in this seat for about ten years. During those ten years,  there were times it was so uncomfortable that I'd rather be tearing out my toenails one at a time than do it another day and sometimes I woke up early just to get back in this seat.  I guess that's how work goes; when you have a bad one you suffer and moan and maybe get up the courage to get a new one and when you find a great one, you don't want to leave, you don't want to move and you certainly don't want to make too much noise about how much you love it or someone might take it away or give you too much of it and then you're back to moaning about it again.   But I love my job, right now, I still  love my job! And I'm leaving it.

I love my job so much I want more of it so I'm taking a chance, a risk, a leap to go somewhere that wants me for what I've already done and what I can do for them.  Pretty friggin' cool, right?!  Well, I'm nervous.  I've been blessed with a great team and a great manager (yeah, really, it does exist!) that even when they doubted me, they trusted me to push them to the next level and give Scrum a shot. So I'm nervous because I know that I've been living the dream and I'm voluntarily choosing to leave it and see if it can replicate itself for me somewhere else.  Am I smokin' the good stuff or what?

So this is going to be my Julie & Julia meet Scrum blog about how it goes.  My plan is to commit to at least six months of blogging about what happens, removing real names to protect the guilty and maybe even exaggerating a little bit for effect because, let's face it - that makes a better story!

Sometimes we spend more time getting back to the work we already started than getting the work done the first time we started.  Check out my blog from earlier this year.

Over the past few years, I've transitioned project teams from their traditional Waterfall ways to a more Agile approach using various techniques at first and then decisively moving toward a single methodology. My preference is the Agile model presented in Scrum.  With my old PMO baggage, I struggled through the potholes and roadblocks that are typical when you attempt to change the way people have always done things.  As the more senior Scrum practitioners advised, it took about six months before the change became the norm and people weren't talking about why we were changing things anymore; they were talking about how we could change things.  As any project manager knows, this is the ultimate compliment and a huge win for the team.  They are now open to change instead of fearing it. 

While change is great for a team to accept and embrace, what happens to the other teams that are impacted? How do they relate to a Scrum team and their nontraditional ways?  I've been researching other Scrum Masters and teams to find how they have converted the agile atheists and here are some helpful insights I've found:

• The Agile PMO Role
• Is the Agile PMO Possible?
• How to Create an Agile PMO
• The Agile Manager
• Can you teach an old PMO new tricks?

Keep checking back for more materials and findings.  I may decide to track a case study of my own soon so if you're interested, please let me know there are some followers out there.