This morning I officially became PMP Certified. As an agile-enthusiast (or maybe preacher) I never thought this would have ever happened. I’d like to share briefly the reasons of this choice in this post:
* First of all, the current economic crisis requires constant improvement: if you want to stand out of the lot, you need to differentiate yourself and always continue to develop your skills and competencies. If you don’t do that, somebody else is going to eat your lunch. Am I going to let that happen? No way!!
* Secondly only focusing on one aspect or vision about a specific topic can never be a positive thing. Broadening your knowledge can provide perspective and help you make the right decisions. Although Scrum has been at the center of my daily work for about 2 years now, I wanted to compare PMBOK and Scrum and see what differences / commonalities there are. Maybe I’ll write about this…
* Finally I would say that project management is also about picking the right set of guidelines (or call it framework / standards) to allow successful delivery of a project. There is no silver bullet – Scrum isn’t, PMBOK isn’t, Prince2 isn’t, therefore a great project manager will know when to use which methodology to make the most of the project team and get customer satisfaction.
Let’s see what’s next…
We are entering our 21st Sprint as a team tomorrow. 21 2-week Sprints that we all meet everyday at 11:00AM in the project room. We’re a bunch of dudes working on the back-end systems of our websites: caching, framework, performance etc. 5 PHP developers, 1 QA, 3 contractors, 2 SysAdmins, 2 DB developers, 1 Product Owner and a Scrum Master. That’s a whole 14 people, quite a few if you ask me…
Problem description
Since I joined the team, I have always found our Daily Scrum meetings a little, well, boring. I have tried shaking things up a little but without success so far. However recently I had the feeling people come to the room because they must and not because they want to, entering the room as if they were going to be beaten up to death. As a result the actual communication is of no value whatsoever to anyone. That annoys the heck out of me and I don’t seem to know what I could do…
Work environment analysis
Here is a sumary of the team’s work environment, this should give some clues already on the root cause.
* We have several projects running at the same time – team members are usually split between these projects.
* Some team members are not fully dedicated to the team (they are shared with other teams).
* The backlog is managed virtually, same with the various Burndowns.
* Lack of meeting rooms generally make it hard to split things up.
* Lots of pressure and high priority work going on: we can’t take the time to talk about things!
Generally I think some guys don’t want to go into details because they either dont want to hold off others or actually think that others don’t care about what they are doing because they are focusing on other things. 14 people…
All that ain’t fun!
What can I do, as a Scrum Master, to sort things out?
I have to be creative to sort these problems while staying within the framework provided by the company. Here is a list of things, in no particular order, which come to my mind as I write this piece:
* Organize the Daily Scrum in projects: start with project A, the with project B etc. The expected result is more coherence in the communication flow instead of jumping from one project to the other.
* Do 1 Scrum per project instead of 1 big mammoth Scrum – split the team into smaller groups while keeping the lead developer in all these.
* Have a physical product backlog and burndowns in the project room in addition to the virtual one (thanks Dan).
* Change the time and location of the Daily Scrum meeting.
* Do one session to remind everyone of the purpose of these daily meetings.
* Work closer with management and stress again the importance of not working on several projects simultaneously.
That’s all that comes to my mind for now… Next step is do a thorough cost/benefit analysis and work together with the team to find a solution that everybody is committed to.
What would you do to break the routine in Daily Scrum meetings and make things fun for everybody? Have you ever experienced a similar scenario?
Another day, another interesting discussion at work.
This time, I guess you got that, we talked about the data teams’ Sprint Burndowns should be based on. Should teams have their Sprint Burndown based on Story Points or on the sum of all remaining estimated tasks in hours?
To answer this question, it’s important to understand what the goal/role of a Sprint Burndown is. The Sprint Burndown is a tool that:
* shows the team’s progress of a running Sprint
* indicates the team’s performance during the Sprint
* should show whether a team is on a good way to meet its commitment or not
* shows where blocks in the development process may happen
Let’s do a small comparison of 2 approaches…
1. Sprint burndown based on story points
* doesn’t require the team to estimate tasks
* might be considered as less overhead by the team
* may not explicitely show bottlenecks in the development process
* may have the tendency to create burndowns like this
2. Sprint burndown based on time
* requires initial tasks to be created and estimated at Sprint start
* may put negative pressure on the team by introducing another level of estimations (and measuring against these estimates)
* may be considered as too much overhead by the team
* may show bottlenecks/blocks more explicitely than with Story Points
* will have the tendency to create burndowns like this
In summary, the purpose alone of the Burndown should already give a good idea in which direction to go. The team/company’s culture and how deep you are in your implementation of Scrum may be 2 other aspects to take into account when making that decision.
Now Jeff Sutherland recently wrote “The best teams I work with burn down story points. They only burn down when a story is done.” (Source) - Are you there yet?