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.
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.
No comments:
Post a Comment