Sprint Planning Meeting for an Intranet Portal
Today I spent pretty much the whole day leading a Sprint Planning Meeting as the ScrumMaster. This is the first time I’ve gotten to involve the customers, which is a really nice change since generally we’ve had to follow the waterfall process and then organize a Scrum under the covers. Customers have a way of really helping to refine the thinking, since they can explain directly what they care about. They didn’t of course stay for the second half of the Sprint planning, but they were very helpful nonetheless.
All and all the meeting went pretty well given the team and myself are still pretty new to Websphere Portal and it’s default content management system. I did get a fair bit of help from one of our Agile coaches who is much better at being direct than I am. The nice part was we were able to get out of the second half of the meeting with a detailed task list for the entire Sprint. The items were almost all all 4-16 hour tasks which I was only able to previously achieve on a much smaller Scrum project with only two developers. The coach was particularly good at roping people back in when we drifted off on tangents.
Everything went into a spreadsheet, but I’ll probably move everything onto index cards and a cork board, because I really prefer visual indicators. Excel can drive me crazy very quickly, so I’d prefer not to rely on it. Last time I did I decided to try out xplanner, maybe this time for the second Sprint I’ll have time to try out Scrumworks.
One odd moment was that we kicked back the final Sprint review two days after the end of the Sprint because myself and 3 of the developers will be at Software Development 2006. For the first Sprint we didn’t want to have most of the team missing. Of course that’s adapting to change over following a plan.
Technorati Tags:
Team of Experts
“Agile works really well with a team of experts.”
— Ken Schwaber (ScrumMaster Training)
“I’ve read up on this Agile stuff and it was designed for a team of experts. So we shouldn’t start sprinting until we’ve figured out Websphere. We can just use our usual process until then.” (Our usual process is a waterfall.)
— Sysadmin at my company
Common advice with managing experts is to relax and just get out of their way. Therefore Scrum and any Agile methodology naturally accentuate this strategy. They’re designed to cut the process down to a minimal level and let the team self-organize. Then the real world steps in.
Try putting together an expert team. Sure you may have a few experts on a team, but unless it’s a really high profile project, you can’t pull all the best experts at your company and staff them on the same project.
So you sub-optimize. You get maybe a really good PM/ScrumMaster and a really experienced tech lead. You have a few less senior people on the team who are going to need some help with learning curves. Maybe you have almost all senior developers on a project, but you ask them to work with a completely new toolset/language/framework where they’re not experts.
Sub-optimal Scrum is still a lot better than the typical waterfall. At least the nasty learning curve or other difficulties are taken on as a team and built into estimates and adjusted as you go. And if you want to put a whole team of novices on something then you’re bound to fail no matter what you do.
The second quote from one of our sysadmins should probably be better explained. Their experience was with a ‘Scrum’ project that was pretty much Scrum in name only. The standups regularly went 30+ minutes, there were effectively two ScrumMasters and two product owners. You can get in way over your head on a project using pretty much any methodology.
Technorati Tags:
Test Driven Development/Design or Test First Design
Everyone agrees the three letter acronym starts with Test. After that we have:
Since development is obviously a broader term hence the need for the other two options centering around the word design. Since developers pretty much uniformly hate testing versus designing and writing code adding the word design attempts to point out the benefits of writing tests first on software design. Then there’s a bit more clarity to Test First versus Test Driven. I actually think Test First Design is probably the clearest, but I tend to stick to Test Driven Development or just TDD myself.
Technorati Tags:
Scrum Queen
ScrumMaster isn’t exactly the sort of job description someone goes looking for. As I remember Ken Schwaber explained that the term was specifically chosen to be uncomfortable because the process of adopting Scrum sucks.
The term reminds me of DungeonMaster from the old D&D days or more recently Webmaster. I actually think my job title was Webmaster at at least one company. At another one I remember working with another developer who referred to himself as the Webmaster and occasionally to me as the WebSlave. Not that that irked me at all.
Anyway we now have a Scrum Queen for one of our projects. The converted PM has rugby jersey embroidered with Scrum Queen on the back courtesy of a developer. I have to say that team is starting to gel. It’s their first Sprint and they’re already jumping in and having fun, which is one of the sure signs things are working.
Technorati Tags:
Sarcasm on Scrum Team
Say you have a developer, Brad, on a project. Brad is a pretty senior developer and is fairly sarcastic. On a typical waterfall project with defined phases, no collocation and a long testing phase a lot of frustration develops. Typical miscommunication happens and too much is contained in documentation from emails, to defect tracker comments. Distance increases the need for documentation.
On this sort of project Brad’s sarcasm is often misinterpreted as confrontation and further separates factions on the team. The project is actually pretty successful, but at the end Brad is burned out and frustrated.
Contrast this with a Scrum style project with daily standups. Same Brad, same sarcasm, but everyone just giggles when Brad explains his impediment that the sunlight reaching his cube is distracting him and that he really would prefer fluorescent lighting. The sarcasm is understood and even appreciated as a humorous release. The team tends to gel because they’re collocated and meeting regularly. Everyone is visibly on the same team and the conflicts that often develop over distances are handled by the Scrum process.
Not a side effect I would have expected, but one I’m beginning to really appreciate.
Technorati Tags: