Scrum 1:2:2 (Month One:Week Two:Day Two)

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! My goal of getting the Scrum Teams trained and in their first Sprint Planning session by the 18th of August is too aggressive considering we don’t have a clean backlog and we are still missing the Product Owner and a Dev Engineer.  I met with the team today to formally introduce myself as their Scrum Master and to share everything I know about our teams, our workload and began our first exercise of team building by voting on simple things as a team. I made sure to include everyone when asking for their input on the team make up (even the one UI guy that had to call into the meeting), and made a point to use words that were team friendly – the “we”, “our”, “us” and “this team” so that everyone begins to hear and feel how being part of a Scrum team will be. We agreed on staggering the sprint start and end dates from the other two team in case we ever need to be at their sprint planning sessions for cross-team impacting stories.  We agreed that our team’s core working hours will be between 10:30am and 3pm to accommodate everyone’s individual schedules.  Two other decisions that will be decided during our Scrum training in two weeks are the team name, the sprint length and the inclusion or exclusion of the User Experience designers as part of the team.  Our resource plan looked like this for our initial discussion:

  • 1 Scrum Master
  • 1 Product Owner
  • 2 Dev (Sys Eng)
  • 2 UI Designer
  • 2 QA Tester
  • 1 CMS Eng
  • 1 DBA
  • UX (Need to confirm if this role will be in the team or not)

We have enough people to start with two teams but we’re thinking of starting out as one team, focus the first few sprints on Knowledge Transfer between team mates in the same role and then split out to two teams once we can function as two independent fully functional teams.  The team seems to be open to that so we may end up there by the end of our next team meeting.
One of our partner teams is not sold on Scrum so he’s asking many of the standard questions about how Scrum works with UX, what are the processes and procedures for how team members work together and where are the data flow diagrams and detailed documentation which is usually not dictated but rather organically grown as the team or teams mature.  This is an area where I need a successful Scrum engineer to share their successes and failures with different Scrum team make ups.  I want to know what they started with and what they ended up with and what scenarios they went through to get to success. Anyone know someone who’s done it? I’m reaching out to some of my Scrum forum groups to see who I can connect with.
Here are some links I found searching the web:



Scrum 1:1:3 (Month One:Week One:Day Three)

Long day yesterday so I’m late with my blog so I’m catching up while I ride the train to our other office.  I observed Sprint Planning for each of the first two teams.  This is their fourth sprint so they are working quite well together.  There is open dialogue about stories and their purpose, detailed tasking of the work to complete each story and consensus about how detailed they should be on day one of the sprint.  Occasionally, the conversation would dive a little deep into solving but their Scrum Master was able to redirect them as needed.  Many of the team members are fairly new to the company and new to Scrum so the relationships and communication styles are still in their infancy.  Even still, they have a very respectful and open tone across the team.  That also describes my relationship with their Scrum Master.  We’re spending a few hours a day sharing insights on the team’s maturity as well as his own delivery style to uncover any opportunities for improvement.  It will be a welcome exchange once my team begins and he observes my style firsthand.

Scrum 1:1:2 (Month One:Week One:Day Two)

Today I spent my time in meetings.  I should just end right there because we all know that when you do that, you’re not getting any actual work done.  It’s the type of day that ends with you wondering where all your time went and how fifty people even know you’re email address!  I managed to squeeze in a few minutes to sort through them and start organizing and prioritizing them so I can stay focused on the more important tasks for the week.
If there’s one thing I could share with anyone with time management challenges, it’s to set up Outlook rules to presort incoming emails.  I’ve been doing this for so long I don’t even know when I started it.  I’ve got some rules that automatically move meeting responses to the deleted folder, rules that move emails with certain subject words to a sub-folder, rules that send a notification to my cellphone when the CIO emails me, and others that do some fancier stuff when I need them (can’t give away all my tricks just yet).  It has saved me hours of time not only checking my mail but also searching for mail.  I managed to crash a smoke break on the patio to discuss a candidate for the Product Owner on one of my teams, observe other team’s Standup meetings, Demo prep discussions, Cross Team communication and sharing discussions, Sprint Demos, Retrospectives, and then I learned a little more about the company and the organization.
Org charts are a tricky thing.  They must be since it’s always hard to find and when you do it’s always out of date.  Sometimes Organizational charts have no direct relevance to the Projects or their responsible Business Owners so defining the RACI model takes more time that it should.  Maybe this is something you have experienced, maybe not.  Almost every project I’ve been on has had some “hybrid” or “matrix” team that support multiple business areas but no one can really agree on the same terminology to describe the relationship so we, as Project Managers, are left to standardize the acumen and duck when the daggers start flying.  You’d think that by now, someone would have finally said “Enough already!  Let’s just use the standard and move on!”    Well, in my career, that person has usually been me.  It didn’t always work out initially but we refined the original and settled on something.  I’ve found that it’s easier for people to refine an idea than to create one.  I’m creating a wiki with a matrix of roles and projects to get the conversation started.
As I’m learning where the work comes from, who asks for it and where they are in the organization, it’s apparent that this department really isn’t any different than most.  Ownership and clearly communicated prioritization are usually one of the weakest links in managing work and it appears to be true for this group.  And that’s actually a good thing, because it’s not so overwhelming or foreign to fix.  Typically everyone knows their process isn’t perfect but they just deal with the fallout when it happens.  Sometimes for legitimate reasons and sometimes just classic avoidance.  Sometimes it’s the “loudest voice syndrome”, as I call it.  Whoever yells the loudest gets the attention of the team.  It usually works for the short term but the residual effects are pretty hefty because the working relationships and trust deteriorate and take an enormous amount of effort to repair.
Focusing on the intake process will help eliminate these issues from carrying downstream and help clear the way for the scrum team to kick off their first sprint plan with a well groomed backlog.
During the business introductions this week, I’ll confirm the backlog we have is accurate and build a responsibility matrix for each of the products or workstreams.  This will be helpful to share with my new teams once we have everyone.  Which, by the way, reminds me that I should talk to the Dev Manager again about his plan to have my two new scrum teams kick off their first sprint on the 11th or the 18th.  At our current rate of interviews and the team training sessions, we’re looking at the 18th at the earliest and even then I’m not confident we can get a full team onboarded and trained with the appropriate backlog items with story points ready.  I would rather tackle work in the traditional way (waterfall or chaos) for a few more days, rather than to cut corners simply to hit a start date.  Would you agree or disagree?  Guess I’ll find out tomorrow when I begin sharing that with my peers and managers.

Scrum 1:1:1 (Month One:Week One:Day One)

So it’s the first day on the new team.  There are already two teams sprinting under the other 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!

%d bloggers like this: