Talking to a team about carryover at a daily scrum meeting led me into a very uncomfortable confrontation with someone who already didn’t like me. Not sure why but I ascertained it had something to do with the unhealthy relationship between product and technology organizations and the fact that product was pushed by sales to make commitments on behalf of the teams that were essentially never met on time (more on that issue in a later post). So a contentious confrontation – read on…
A product owner should be dedicated to one team. Or no more than two teams working on the same product with the same product backlog. But what about a product owner who we spread across two teams with different backlogs working on different products? We’re asking them to be two people and it’s not sustainable! This product owner told me he was in 17 hours of meetings between the two teams per week (and I added it up and it was true)! For the product owner who should be splitting his/her time between self thought, stakeholder and customer input, and team time, it’s not possible for those things to be equal or sustainable not to mention the loss of productivity when context switching/multitasking. Though unfortunately this is the non-ideal reality sometimes.
Ah, the elusive, well-executed stand up meeting. In my experience, the stand up or daily Scrum is often the first thing we try to implement when introducing a team to Scrum and also the first thing to deteriorate as teams mature or don’t mature. But what actually makes a good stand up and what are some symptoms to avoid for a poor one? I’ve been circling this for awhile now and here is what I’ve come up with – including the ‘eyes closed stand up.’
Scrum works very well within its own construct, but when dependencies arise with teams that practice Waterfall, it can be tough to get the work you need on the docket in a timely fashion. Here are a few pieces of simple advice to make integration go more smoothly.
So, you just got out of your CSM class, overflowing with your newfound Scrum knowledge and renewed faith in software development practices. You’re ecstatic to share your new view of the world and show how Agile can benefit your organization, and you can’t wait to get started. But, in your first Agile project, you meet resistance, opposition, and worst of all, modified Scrum practices. What’s a ScrumMaster to do?
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.