8:15am - Ah, the end of a long week, I like to get in a bit earlier on Friday’s since it’s usually a pretty low-key day.  No meetings, no training, just an opportunity to think and research.

After the usual checking the Agile support box and responding to email I start working on some Agile flash cards we want to start distributing.  These are 3 x 5 index cards on various Agile topics that folks can use as a pocket reference guide.  This will help people at least get some of the lingo right so it’s not so confusing.  Right now any opportunity to see stuff is called a demo and when the product owner is preparing stories they often call it a planning session and are getting confused between this session and iteration planning.

10am – Stand-up time.   Since we’re only a couple of days into this iteration some un-expected tasks come up that the team didn’t think about during iteration planning.   I remind them to stick to the 3 questions and we’ll talk about those after.    There is still dysfunction in the stand-up but they are getting value out of it and I don’t think forcing them to the 3 questions and only those 3 questions is what is best for the team.  Yes it should be a guide, but the value of the stand-up is defined by the value the team gets out of it.

After the stand-up I remind them to update their tasks in our tool, as recommended by one of the programmers.    Then I ask them if they are pairing, they should add a duplicate task in the tool so each person can get credit for the work.  If it was up to me I wouldn’t bother but governance is governance and that’s far too big of a battle I’m not willing to fight right now.  Besides, it’s quick and easy and if it makes some managers happy, I don’t really care either way.

I close out the morning with preparing 3 sets of front-and-back flash cards and send them over to my mentor to review.

1pm – After lunch we have an emergency meeting with the QA manager about passing off our work to the regression/release/deploy process.   I make the mistake of being a bit smug with the fact we’ve automated our tests and we’re happy to sit with the QA team to show them what we did but in retrospect I realize I should have listened more to uncover why we need to go through this process.  I should have spent more time understanding what they need instead of being so nonchalant.

I guess I’m a bit irked that although this is a self-organized, fully cross-functional team, the business still wants governance and checks and balances.  At the end of the day, figuratively speaking, we’re only losing half an iteration for these activities and the product owner is satisfied so mission accomplished.

2pm – I do some research on the Estimating and Planning class we plan to deliver next month and it’s really tough to come up with material and not completely rip-off just about everything Mike Cohn has already done.  I am able to apply some ideas more relevant to our environment and make the material focus more on planning instead of the plan.

Upper management also wants some notes on the pros and cons of a short-term vs long-term transition plan so I jot some down and send them off to my mentor to get some feedback.  She’s handling this initiative because, well to be frank, she’s smarter than I am and has more experience.  I do enjoy participating in these activities but with the sheer size of the organization there is no shortage of work.

4:30pm – after reading a pile of blogs and a couple of videos I head out for the week satisfied with the result.

I hope you enjoyed reading this series of posts.  They accurately describe what I do day-in and day-out and everyday is almost like working with different clients as I get to participate in various teams and talk to many people throughout the company.   Hopefully you did notice some of the dysfunction with some of the interactions I described as well as what I did to handle them.  That was sorta the whole point of the series!  As usual, don’t hesitate to let me know your thoughts, the 2 comments I’ve received over the last couple of months are getting lonely!

7:30am - I arrive at our head office early as I’m delivering a rather thorough 4-hour Agile introduction to 20 or so people.   Since this is my 30th or so time delivering this at this company I’m into a good rhythm and getting here early just allows me to miss most of the morning traffic.

I have a chat with the project manager who is handling the budgeting for our team and ask about the hardware we were supposed to get for the team 3 months ago, he lets me know it’s still on order and should be here soon.  There are some blocks a coach or Scrum Master just can’t remove and with an enterprise company and big, heavy-weight process, it is what it is, so we’ve been making do with what we have and pillaging spare machines for parts.

8:45am - Armed with a projector, sticky notes, markers and purpose, I head over to the training room and setup.    People start stumbling in and my observation about culture here over the last few months is that people seem to double-book themselves quite a bit or simple expect meetings to start late so I expect to start later than I thought.

9:15am - After sending out a reminder and getting a couple of last minute cancellations and a couple of no-shows, the class is down to 16 people and I get started.  I remind everyone that  I would appreciate it if they turn their Blackberries off and ignore them.  I offer to do the same knowing full well, based on history, some folks will ignore the rule.

Today’s session has a wide-range of personalities such as folks from product management, audit, release management and various analysts.   I find this really helps everyone understand the impacts of transforming to Agile for other co-workers in different areas of this department.

I won’t go into deep details about the class but essentially the first half is conceptual in nature.  We talk about the Manifesto, what it means and that Agile is not a quick fix solution and there is no checklist or easy answers.  I remind them that it would be simply crazy for me to convey that a 4-hour session is going to arm them with all the tools of the trade and that myself and my mentor are here to help when they want help.  Some are confused by that message and often I’m asked what the plan is to roll Agile out across the company and if we can just give them the answer.

They are a bit surprised to hear when I say that I don’t know the answer but I do have a whole bunch of knowledge and tools that will help us discover what works for us. We understand the way we are working isn’t working very well but it’s up to all of us to find the best solution.  I can certainly help guide that but my mandate isn’t to come in and order them to follow what I say.

The second half goes into more tactics where I talk about Scrum and Extreme Programming to help them understand the definitions and underlying principles.   I remind them again that if they like what they see, approach me afterwards if they want to learn how to apply them in their situation.

1pm – Class finishes up, I stick around for more questions and a couple of people invite me to some meetings for their group to further talk about how they can employ these techniques.  Some of the folks who were involved in early “agile” projects are relieved to hear what they thought was Agile really wasn’t.  There is danger is mistaking that just because you work in 2 week Sprints and have a backlog you are Agile.

I get some feedback from my mentor that I seemed nervous and I suppose on an unconscious level I probably was.  I have a great deal of admiration and respect for her so I wanted to prove myself.  She also tells me about a couple of things she would explain differently and tells me what those were and what she would change.  Luckily I also have my utility belt on so I jot down some notes.

3pm - After scarfing down a slice of pizza I rush over to our mid-town office for a meeting with a team in supply chain management.  They enjoyed the Agile introduction session last week and wanted me to come in and see if I could help them apply the practices to an upcoming project.

I listen to them explain what they are trying to accomplish and talk about a couple of approaches.  The key message I try to deliver is to collaborate.  Involve the whole team including the operators fielding the support tickets, the analysts, stakeholders and everyone involved in the project.  The wisdom of crowds is a powerful ally and I suggest they start off with a retrospective to start the dialogue.    After that, I point out that a brainstorming session would be a great way to figure out an action plan so they can at least figure out the direction they feel they need to go.

4:30pm – The meeting finishes up and I head home.

Sometime later that night - I check the Agile support mail box, respond to some emails and prepare an blog post on Retrospectives.