MatrixMaxx is Matrix Group’s Web-based association management software product. For about a year, the team had been exploring agile development methodologies. Maki, our CTO and Chief Architect for MatrixMaxx, was really hot to implement SCRUM.
There is a lot to SCRUM, but here’s what SCRUM means to a non-techie, manager type like me:
- SCRUM is all about roles and process.
- There are 3 main roles in SCRUM: the ScrumMaster (who serves as the project manager); the Product Owner (who represents the stakeholders like me and the clients); the Team (the folks who do the development work).
- Development cycles are broken up into sprints, which last anywhere from a week to 30 days; each sprint has a defined list of shippable work. Complex projects are broken up over multiple sprints, but each sprint must include deliverables that the customer can recognize and use.
- There is a daily SCRUM meeting (lasting no more than 15 minutes), during which each team member answers the following questions: what have you done since yesterday?, what are you planning to do today?, and what is preventing you from making progress? (so the ScrumMaster can facilitiate a resolution).
- Tasks, or user stories, are posted on a board and each team member takes tasks off the board each day.
Sounds great, right? But for an agency like Matrix Group, SCRUM posed some problems:
- We have one person who serves as BOTH the ScrumMaster AND Product Owner. Why? Because I wanted one Director who would be fully accountable for the team’s progress, revenue goals and customer satisfaction.
- At the end of the day, we’re still an agency and we need to be able to respond to urgent customer requirements; yes, these requirements screw up development schedules and sprint goals.
- It wasn’t an option to NOT use our intranet and bug tracking system since we need a detailed record of our work, including specifications, related projects, testing notes, etc.
So we decided to create the Matrix Group version of SCRUM. Team members read Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle, long considered the bible of SCRUM. Our version of SCRUM includes:
- A daily SCRUM meeting at 2pm; yes, it’s a little late, but we wanted to accommodate a team member who only works afternoons.
- Our sprints are 60-90 days long to coincide with the software release schedule, which is quarterly.
- We don’t have a SCRUM board. Instead, we add release numbers to all tasks in our intranet and then use a canned report to define our project backlog for each release/sprint.
- Sometimes, the daily SCRUM meetings are followed by tech meetings used to work out issues and solve problems together.
- The sprint list gets modified every few days, sometimes daily, to accommodate urgent requests from clients.
So where do the beer and cream cheese come in? Tanya, the MatrixMaxx Director, posted to one of the SCRUM message boards, asking if anyone had experience with having the same person be the ScrumMaster AND the Product Owner. One ScrumMaster sarcastically remarked, “You CAN do it, but that would be like combining beer and cream cheese.”
The challenge was on. As is often the case at Matrix Group, we took a methodology and made it our own. To celebrate the 9.2 release, a half dozen staff members scoured the Internet and found yummy recipes that combine beer and cream cheese. Last Thursday, our Beer and Cream Cheese feast included: cream cheese dip with heffeveisen, and cupcakes with Guinness and cream cheese frosting. I brought in pumpkin bread with Guiness and cream cheese + cheesecake made with a maple syrup and Guinness reduction. Check out the photos from our Beer and Cream Cheese fest on Flickr. We have dubbed our version of SCRUM “Beer and Cream Cheese SCRUM” and are considering blogging about it.
Beer and Cream Cheese SCRUM really worked for us. We plowed through more tasks and bugs than ever before, the bug list is down, and we prevented major communications snafus between team members. Most importantly, MatrixMaxx 9.2 was released on time with a huge feature list.
How about you? Is your team using SCRUM? What’s been your experience? And have you created your own version of SCRUM?
6 replies on “Beer and Cream Cheese SCRUM”
Hey Joanna,
Congratulations on adopting Scrum, albeit in your own Matrix way. One question — 60 to 90 day sprints??!! That is pretty long. Any thought to breaking those down to 2 or 3 week sprints and just have more of ’em? Seems much more manageable. I cannot imagine us trying to figure out enough stories in sufficient detail to plan for 90 days.
BTW: Ken’s not going to be happy about you misspelling his name — http://en.wikipedia.org/wiki/Ken_Schwaber
Regards,
Dwight
Hi Johanna –
I would hesitate to call this Scrum. This isn’t necessarily a bad thing. Scrum didn’t work for you and you morphed your own agile process. Nothing wrong with that!
Scrum has a pretty static set of requirements and two of them are iterations of no longer than 30 days and static sprint priorities with accompanying goals. The reason that iterations are short is so that priorities can be shifted frequently, but only at the end of a sprint.
Another issue is the fact that the iterations vary in length drastically, from 60 – 90 days. One of the goals of Scrum is to establish a cadence so that the team knows what happens when and gets a comfort level with the process. You team is naturally going to adjust to either a 60 or 90 day cadence and the sprints that differ from their expectation is going to feel rushed or drawn out.
Why do sprints correspond to releases? You can finish sprints, but not deploy. Just curious.
It’s great that this agile-ish method is working for you, but please don’t muddy the waters by calling this Scrum. You’ve rolled your own methodology call it Beer and Cream Cheese, drop the Scrum.
Very interesting story.
I do agree with the previous commenters that it’s worth trying shorter sprints, and seeing if — pardon the pun — it makes the team more agile, to have more frequent opportunities to assess what worked, what didn’t work and what the next set of goals should be.
And yeah, it’s not “real” SCRUM if the scrum master and the product owner are the same person; it’s modified-SCRUM or SCRUM-influenced or Matrix-style-SCRUM or “Beer and Cream Cheese SCRUM”. But I wouldn’t lose sleep over it.
One size does not fit all and I don’t know if a purer version of SCRUM would be better for your firm.
IMHO, the important question isn’t the purity of the methodology; it’s the results.
Thank you for the thoughtful comments.
Dwight, thanks for catching the typo in Ken Schwaber’s name; this has been fixed. And to respond to your comment, the team is now experimenting with two week sprints immediately after a software release, before doing a longer sprint for the next release.
As for the ScrumMaster and Product Owner having to be two people, my question to you all is this? Who is ultimately responsible for making sure the meets goals (financial and otherwise)? This continues to be a major topic of debate at Matrix Group.
Finally, we certainly don’t mean any disrespect to the SCRUM community and methodology. We are tweaking our process as we go, and perhaps you all are right and we should simply call our process Beer and Cream Cheese.
Thank you. Joanna
Hi Joanna,
Interesting story and I’m glad it’s working for you.
But I must echo some of the comments already here and say that because you’ve strayed away from some of the basic principles of SCRUM, I’d say you’re practicing something called ‘SCRUM-But’. This is when a team says, ‘We do SCRUM, but….’. Yes, SCRUM is a set of values and principals, not a process and yes you can adapt it to fit your organization, but there are some limits to how far you should stray. After being involved in a challenging but successful transition to SCRUM, I’ll suggest that you reconsider a few ways you’re doing things.
60-90 days is way, way too long a sprint. The purpose of short sprints is to shorten the feedback loop so that feedback can be incorporated as the product develops. At 60-90 days, you’re waiting a heck of a long time to get that critical feedback and use it. I would recommend 2 or 3 week sprints. We do 2 week sprints and it works.
The other, I would say serious problem, is the fact that you have one person playing the role of PO and SM. Take it from a PO, this is a huge, inherent conflict of interest. First, it’s a full time job. But more importantly, a PO is supposed to represent the business, while the SM is supposed to protect the team and help remove impediments to getting the work committed to during the sprint. This can even include protecting the team from the PO so new requirements aren’t introduced during a sprint or other additional work that wasn’t agreed to doesn’t impede the team’s progress and prevent them from meeting their commitment. The PO wants features of value and the SM wants to make sure things get done and they engage in a bit of a negotiation every sprint. Decisions about priorities must be made constantly. If a PO, determines one story is now more important than another, they need to be able to get that story done. But the SM may feel something else is more important, say addressing some technical issue that might make the team’s life a little easier. Well someone needs to make the tough decision about what gets done and that person is the PO. If the SM and the PO are the same person, you don’t know what you’ll get.
Best of luck to you and your continued success.
[…] over a year ago, I blogged about how the MatrixMaxx team was using an agile software methodology we’ve dubbed “beer and cream […]