When the Scum Master is on a different project

This round I find myself in a new scenario. We had a departure of the Lead-In-Training developer and I had to re-assume the role. In the mean time I was slapped on three different projects (I know, major no-no) and, as such, had no time to re-allocate to the main project I was scrum mastering.

I find myself extremely out of touch with the state of the project. Yes, I get the status updates, but I don't know what is happening. I have to take it on faith. It has made me acutely aware of the people who day after day state:

I'm working on my tasks today and everything is well.

I have become management. Horrible. I'm clueless and am constantly asking stupid questions. It really makes me appreciate the people whom I can count on to get things done.

One of the biggest challenges is that I can no longer anticipate when problems are coming down the pike. All I can do is to react to the daily stand-ups. I even forgot when the Sprint was ending. Total disconnect. Your scrum master should never be split like this. Always pick someone who is dedicated and intimately involved with the guts of the project to fill this role. No split-timers, and no fair-weather scrum masters.

Co-development partnerships

So, what happens when an Agile organization attempts to work a co-development project with a non-Agile organization? Panic! Chaos! Hilarity ensues!

We have these weekly status meetings with such a project. They are pressing us hard for "Final Design" this Friday so they can start development. Meanwhile, we're 3/4 complete with total development (not that we're telling them that), but missing design details on the 1/4 not yet addressed. Which has them in a total panic. This, in turn, puts our PMs in a total panic. Hilarity ensues.

In some ways this is similar to the problems faced by an Agile development group in a non-Agile organization: at the touch points (before and after development) the product development needs to look like a waterfall project. In a lot of ways it's different, however. Co-development requires functional areas to be synchronized. Therefore functional interfaces must be completed at roughly the same time for the project to move forward.

I think we could have avoided some of these issues had they given us their top concerns earlier. Unfortunately an SDLC/waterfall organization is unable to express their concerns early due to the "specs must be written first" mentality. At this point I see two ways forward - give them information we know to be incorrect to fulfill their need and force thru a change request when we have accurate data, or stall and deliver when we have more accurate data for their concern.

1. Deliver incorrect with intention to submit change later:
PRO: People are used to this approach with waterfall projects. They will become unblocked on the design doc and may start development.
CON: Must manage informal channels to insure development doesn't start on bad part of spec; change request may be denied, locking us to bad design.

2. Stall until accurate data is available:
PRO: They will not have option to develop incorrect solution.
CON: They may stall all development, even on complete areas, to satisfy process requirement.

Basically, everyone should move off of the SDLC development process. It would make my life a whole lot easier.

Handling the Unpredictable

Theoretically people are supposed to keep their efforts focussed on one project. Task switching is incredibly wasteful and there is a fairly large amount of empirical data to back that up. But what happens when you have no choice? The other day one of these scenarios reared it's ugly head around here. There is a product that was frozen in development due to external client dependencies. Then the logjam broke. Then one of the sales people sold it to a big customer before knowing it wasn't ready to ship.

So now we have to get this done, but all the resources are mid-cycle on another important project. What to do? Well, what you don't do is what our QA manager suggested: pull everyone off the current project to work on this new, more important project. Major no-no. Also why his team feels constantly over-taxed; he doesn't know how to handle complexity.

The most important thing is to maintain continuity and flow within existing projects.
1. Finish tasks in the current time box. Don't allow people to thrash on different projects.

2. Attempt to stall and buy time so resources may be adjusted at a new planning point. Otherwise you will precipitate failure in both projects.

3. Isolate resource re-allocation. Identify one or two people to re-dedicate to this new initiative fully instead of slicing off 30% of everyone's time. A full missing resource is easier to predict than a 30% drag on all resources.

4. When re-planning adjust your projected velocity based on new resourcing. Don't forget and pick the same amount of work.