kaczor.info

This week I started to work on a new project as ScrumMaster and Agile Coach for the new Scrum Team. All the team members are not familiar with Scrum.

One team member is working on more than one task at the same time. If these two tasks need to be worked on in parallel, why were they separated and estimated separately?

In fact the Team is doing Sprint #1, but before that there was Sprint #0 (which is perfectly normal thing to do) and Sprint #0.1 to hide, that Product Owner doesn't have any Stories to implement and no requirements gathered in any form. I guess there are no lessons learned in our business and Agile is still taken as synonym to flexible a.k.a. we can do what ever we want.

On the first Daily Scrum I found out that the previous Sprint is not closed and bunch of tasks is hanging there in Review state. Sounds like lack of discipline and luck of Definition of DONE. The second one for sure. So I created a task to book hours in the current Sprint to track where the time went. It took three days to clean this up, because other tasks were worked on in the mean time. Yeah, definitely there is luck of discipline.

Following tips from the book I am reading now Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition I let them sink for a bit.

The Team consists of contractors and I don't know why they are quite stubborn on Ideal Day definition. They estimated effective work time as 8h per day, working 8h per day. That means no toilet, to checking emails, no discussions. They put 168 hours of work into the Sprint, I say maximal amount of hours to be booked by the end of Sprint is 100.

The Sprint is defined with more than 50% of Spikes to investigate, but funny enough there are tasks depending on outcome of Spikes and they are already estimated. How can you already estimate something for what you are gathering requirements for? In the Sprint Backlog there are also tasks with dependency on third parties and second team. They can easily become blockers.

As you can see there are quite a lot of issues already and we have just started.

Anyhow, I decided to change methods and instead of insisting on implementing best practices, I let them do mistakes and get lessons learned. Hopefully I will see lessons learned on the Sprint Retrospective Meeting.

I will keep you posted ;)

what do you think about this approach? Should I let them fail? Let me know in the comments below.