Scrum.org announced today that its Chief Craftsman, David Starr, will soon be joining Microsoft as Senior Program Manager in Visual Studio ALM.
Since joining Scrum.org in 2011, David has driven significant improvements in all of Scrum.org’s programs, and has dedicated himself to helping teams around the world improve their software development. David is leaving his post as Chief Craftsman for Scrum.org to help Microsoft continue improving Visual Studio to support agile software development practices.
In discussing his new role David said, “There is a saying that the tool sets the rules. As unfortunate as that statement is, it is true for many organizations who don’t yet value people over process and process over tools. I look forward to delivering products that encourage good agile practices with a focus on better people interactions and higher quality software. Creating features for a product that is used by millions of software developers is humbling.”
"It is with mixed emotions that we bid David farewell," said Alex Armstrong, Scrum.org's co-founder and VP of Business Development. "David has made incredible contributions through his work at Scrum.org, and we will miss him at each and every Daily Scrum. As part of the Scrum.org team, David has been directly helping to improve the profession of software development. We are excited that he will be able to continue to do so with a company as central in the software development universe as Microsoft," Armstrong continued.
“I have been privileged to work with the thought leaders at Scrum.org. The Professional Scrum Trainers and others in the Scrum community are some of the most committed and talented people contributing to our craft,” said Starr.
“I will miss my interactions, heated discussions, and finally resolutions with David.,” said Scrum.org founder Ken Schwaber. David drives integrity, and that is essential to Scrum.org’s mission and to the well-being of our profession.
Asked about the significance of Microsoft’s choice, Armstrong summarized, ”By bringing a Scrum practitioner with David's unique mix of talents into a leadership role on its flagship ALM product, Microsoft is clearly telegraphing its commitment to supporting Agile and Scrum teams. Agile’s influence in software development has been increasing steadily over the past decade, and this seems to be a clear demonstration of the trend continuing.”
You can read more about David’s future plans on his blog.
I never refer to the daily scrum (or daily standup) meeting as a “status meeting.” The term “status meeting” is too pejorative for most of us. For me it conjures images of sitting around a table with each person giving an update to a project manager while everyone else feigns interest while either mentally preparing for their own upcoming update or wondering how much longer the meeting will last.
I prefer to think of the daily scrum as a synchronization meeting. Team members are synchronizing their work: Here’s what I did yesterday and what I think I’ll do today. How about you? Done well a daily scrum (daily standup) meeting will feel energizing. People will leave the meeting enthused about the progress they heard others make. This won’t happen every day for every team member, of course, but if team members dread going to the daily scrum, that is usually a sign of trouble.
I want to offer one of my favorite tips for an effective daily scrum: If you’re a ScrumMaster, don’t make eye contact with someone giving an update. Making eye contact is human nature. When we speak, we make eye contact with someone. It’s only natural that a team member will look at the ScrumMaster; call it a legacy of too many years under traditional management but a lot of people on Scrum teams do look at their ScrumMasters a bit like managers to whom they need to report status. By not making eye contact with someone giving an update, the ScrumMaster can, in a subtle way, prevent each report becoming a one-way status report to the ScrumMaster.
Each person’s report is, after all, intended for all other team members.
I’ve never been a micro-manager, especially not since using agile and Scrum. I could have turned into a micro-manager early in career, except I’ve always been too busy to spend my time checking up on people. But, while I’ve avoiding checking up on teams or people, I’ve never been reluctant to check in with them. I was recently reminded of this by reading an article about the importance of small wins.
While checking up and checking in may seem similar, there are four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team:
1) Be sure the team has the full autonomy to solve whatever problem they’ve been given. A good ScrumMaster ensures the team is given complete autonomy to self-organize and achieve the goal its been given.
2) Don’t just ask team members about their progress; offer them real help. ScrumMasters do this, for example, by protecting the team from outside distractions and removing (or even anticipating) any impediments.
3) Avoid blaming individuals. Things will occasionally go wrong. Assigning blame when that happens will make people feel they are being checked up on rather than just being checked in with.
4) Don’t hoard information. Micromanagers tend to view information as a resource to be retained and only shared when needed. A good ScrumMaster will share anything learned by checking in with others who could benefit from it.
So, stop reading this blog and go check in with your agile team right now. Just don’t check up on them.
I’ve been wondering lately if Scrum is on the verge of getting a new standard meeting–the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint.
To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let’s revisit the early 2000s.
Back then, Scrum didn’t have a formal Sprint Retrospective Meeting. Prevailing wisdom at the time was, in fact, fairly opposed to such a meeting. The logic was that a good Scrum team should be always on the look out for opportunities to improve; they should not defer opportunities to discuss improvement to the end of a sprint.
That argument was a very good one. However, what was happening on teams was that day-to-day urgencies took precedence and opportunites to improve often went either unnoticed or unacted upon. And so what most teams eventually realized was that of course we should improve any time we notice an opportunity, but at a minimum each team should set aside a dedicated time each sprint for doing so–and thus the retrospective became a standard part of Scrum. This was helped along tremendous by the great book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.
I’ve had more CSM course attendees recently asking questions about a Backlog Grooming Meeting as though it were a GASP. Many are surprised when I tell them that not every Scrum team has such a meeting each sprint. I still don’t advocate every team conduct a Backlog Grooming Meeting each sprint–as with the early arguments against retrospectives, I’d prefer backlog grooming to happen in a more continuous, as-needed way–but so many teams are successfully using a Backlog Grooming Meeting, arguments against it may be on their last gasps.
Share what you think below. Will a Product Backlog Grooming meeting become so common it becomes a Generally Accepted Scrum Practice (GASP)?
Following the article in the Wall Street Journal on daily standup meetings a few weeks ago, a number of other places have interviewed me abut the topic. I don’t know why they’re asking me, but the interviews have been fun so far. The latest was on the National Public Radio (NPR) Marketplace show on Monday, 20 February 2012. You can listen to the whole show but Sarah Gardner’s interview with me begins at 18:50.