Week One : Relief & Panic (Long)
- So as of yesterday we're a week into our use of Scrum
The start of the first Sprint was rocky for some of the reasons
mentioned before. This is a long post and I mostly describe what
we've done so far. The one question I have (and more detail is
towards the end of the post) is how to get the team to realize what
project mgmt can fix; and what needs to be fixed by other departments
(ie., bad planning because sales doesn't maintain predictions, or a
1. The Sprint Backlog was not accurate
We were able to substitute better backlog items and keep our Sprint
size the same. The Sprint items that had to change hadn't been
started yet, so I think this is OK; and the decision was made with the
whole team present and in agreement.
2. The "True" product owner didn't have enough input
The product owner is now on the team. Though he says he doesn't think
he'll be able to make all the daily meetings. I think this is still
a problem, but at least the psuedo product owner and the true product
owner have a better idea of what is involved. I think that they can
work together to create better single "proxy" of product ownership.
One concern that came up as a result of this is that the Product Owner
is a little too high level. He is supposed to be a product manager,
but really isn't that interested in details. When he and the proxy
worked on the backlog they didn't come up with that much work.. And I
think the Product Owner is still expecting a way to "interrupt" us if
really important stuff happens.
3. The team, in general, wasn't well educated on the use of Timeboxed
This is getting better. I'm doing a lot of "Coaching" to try and
explain the context of what we're doing and the alternatives for doing
things differently that still yield the benefits of Scrum.
4. No "experienced" Scrum people
I mentioned hiring a ScrumMaster but didn't get a postive response.
I'll keep mentioning this especially as we run into problems that
could have been avoided if we had more experience.
Regarding the willingness to "Interrupt". In the past, with no
process, and no planning; it was perfectly acceptable to stop
development at any given point to work on emergency issues.
In our business these are "Pilots" where a new customer is promised
some changes to support their specific business needs. We've
committed to this level of support since we're a new company and are
trying to get a customer base built up.
However, instead of trying to predict these events, or plan for them
better (using intelligence from the sales and customer service
departments) we're "adapting" our process to allow interruptions
The CEO, COO and the product owner have said that no matter what we do
in development we have to respond to Pilots. I agree with that; but
think that we can do that in the context of a relatively short sprints
(we're at 3 weeks now).
Sorry for such a long post.