Scrum meeting snapshot.

I’m sure you know about apples and doctors and whatnot; I’ve also found that Scrums are just like that too.  It’s a foundational tool for any team that’s becoming “agile”, and a great starting point to work Scrum principles into an organization for a lot of reasons.

A Scrum is simple and wraps a lot of good ideas into itself.  The idea of a 15 minute meeting with a hyper-focused agenda with a few rules is something that can easily be applied in non-technology as well as technology groups.  To frame the benefits in a slightly different way:

• You’ll just get things done.
• Information is boiled down to the essentials.
• You can improve morale by empowering team members; they are free to self-organize for the rest of the day with minimal regimentation.

Here are some tips for organizations who want to start introducing Scrum into non-software-engineering teams:

• For project managers acting as Scrum Masters: Focus on impediment identification and resolution (action) as opposed to project plan maintenance (passive).
• For business analysts (or other team members in general) acting as Product Owners: Focus on getting everyone on the same page regardless of role and break out of the siloed information mentality as opposed to creating and maintaining over-wrought documentation.
• For the rest of the team members involved: Focus on progress, momentum, and constructive conflict as opposed to accounting for every minute of one’s time.

I realize that some people might argue:

• What about emergencies?  I would say that Scrum Master judgment can intervene to call off the Scrum as needed.
• What about getting to other topics?  That is not the point of the meeting!
• How do we make sure everyone has their say?  Team members (emphasis on team) will, as long as it’s brief and to the point.  Non-team members wait until the “parking lot” time that’s determined by the Scrum Master.

These (and their variations) are all excuses for ScrumBut, a horrible mutation that’s justified with weak rationales and a disdain for other folks’ time.  Respect the people you work with, and just don’t do it.

PS. Credit for the photo of the Scrum meeting goes to Jason Yip and his article here.

My perspective comes from lots of hands-on experience with each of the three groups. Creative folks need time to let ideas marinate and mature into thoughtful assets. Technical folks (good ones, anyway) need scope to build the best possible product (if only I had a dime for every time a developer’s asked me “Well, if I do it this way it can work okay, but I think it’s better to do it this way because [insert comment about future capabilities or cool functionality]“, I’d be rich!). And of course, we can’t forget business folks, whose tolerance for time seem to fall lower every day. How can you get the three groups working together?

Recommendation: Building mutual respect and condensing each group’s issues into soundbites for the other groups is my approach to handling any initial situation. Project managers must have a strong curiosity for new domains and the nuances of each group’s work and background, which will help them argue for each side. This kind of position will guide a project to success for all stakeholders since it strikes a good balance and effectively negotiates a lot of tension out of the situation. However, when I’m in between a rock and a hard place, I have to side with the money but not without a fight for quality and extensibility. Doing right by the client is my mantra and I would never sacrifice that until I’m kicked out of the building.

What do you think?

I’ve personally seen demonstrations or used the following tools:

• ActionMethod
• Microsoft Project
• Danube Scrumworks
• Rally

but they all serve some subset of functionality that could be addressed by a better integrated and streamlined tool.  Consider the following scenarios:

• The project is starting up, and you’ve identified all of your stakeholders.  Where does someone set up resource assignments for WBS planning?  Where does someone set up mailing lists for the team?  Where does someone set up collaborative workspaces for documents and deliverables?
• The project is in flight, and a new resource has joined the team to assist with a new stream of work that arose because of scope changes.  Where does someone make assignment changes on the planned tasks?  How does someone get the person up to speed quickly with his/her respective peers?
• The project is closing down.  How does someone close a collaborative workspace, draft/issue a final status report, and archive deliverables with a minimum of effort?

In many cases, all of this work is distributed across physical machines, distinct programs, and perhaps even in analog form (as opposed to digital copies).  Managing projects to success should be about the project management, not the tool management.

Recommendation: Combine or integrate:

1. ad-hoc organizational modeling
2. sophisticated communications tools
3. work breakdown structures, and
4. collaborative workspaces and their deliverables

to foster a project-oriented work environment.  Has anyone seen such a beast?