This Monday and Tuesday I attended the Scrum Master Certification tutorial at QCon held right here in San Francisco, California. It was great to have this tutorial right in my own back yard. I wish I could have attended the rest of the convention this week with speakers like Martin Fowler from the Agile community, but alas I was paying for the $1,700 course myself and shelling out extra bucks on top of that didn't seem like a good plan.
The course was two days as I mentioned, and held no surprises for the seasoned Agile/Scrum participant. We went over the product backlog, the sprint backlog, product planning, sprint planning, Scrum artifacts with a lot of emphasis on burn down and burn up charts, and we did some simulations, which is what I want to talk about.
In our simulations we had WAY too much to do in the time box we were given. So for instance, when we were told to prioritize the stories, we didn't really have time to fight over was story A really more important than story B in relation to stories A through ZZZZ (so there were lots of stories). But, we didn't have time to fight. Initially I felt cheated, like the simulation didn't resemble "the real world", but then I got to thinking that it could resemble the real world, if I made it that way. Think about it, why give your Product Owner and the stake holders days to decide what they can decide in hours, or even minutes. The end result will probably be the same that the critical items get in the product before the release, and the rest will possibly go in the next release.
I also got confirmation that technical items, those that don't directly add value to the customer, but help the devs produce better code faster, should also be on the product backlog, which implies that a tech person should be a stake holder. That person could be an architect, a team leader, or maybe even just a team member (and rotate the member). Same thing for maintenance (aka super high priority bugs, that management can't downgrade because they can't set expectations well enough with customers) - put a person on them all the time, but rotate who that person is so he doesn't burn out.
So now I'm a Scrum Master, and I feel confident I could do what a Scrum Master should do, given my new found training and my previous experience with Passageways and my counter-Scrum experience at Jobvite. If you're looking to hire someone with unlimited courage and a good sense of people, feel free to drop me a line.
Tuesday, November 18, 2008
Saturday, November 8, 2008
Generalists
This week I sat down with Davis Frank of Pivotal. He's part of a contractor shop that does projects in Ruby and Java, but it's exactly the kind of shop that you wouldn't think could exist. They help a company work on a project, but at the same time they also teach that company how to be Agile (XP specifically). When you sign up for Pivotal's services, your engineers pair up with Pivotal's engineers. When the project is over, Pivotal gives you their project management software, Pivotal Tracker, and you're on your own.
One of the things Davis said was important in an Agile shop is to hire generalists. He admitted that no one is ever even in all areas (database, class libraries, UI design, client-side scripting, etc and even other non-tech areas like, um, communication), and that by the nature of being human we all have "specialties" but that the employees that work best in Agile are the ones who can do it all - there's no barrier preventing them from working on any particular task, especially when paired with someone else.
It doesn't make sense though. If you want a killer database, you have to hire the database zealot who has never come out of his Oracle cave, right? There are some projects where that will be true, where you need the specialist. But when it comes to the web, we're not talking about single platform applications. Knowing how to design a decent table structure that'll lend itself to your business objects that get passed through web services to be displayed on desktops, mobile phones, and video game consoles is a bit more practical.
We used this at Passageways to it's full advantage. No one person was ever on "the critical path", rather, the whole team was on the path. There was a bucket of tasks, and they were assigned to the team as a whole, and an individual took them when he or she was ready to work on them. So if I finish making the schema for the new reports, and then I jump over and add some themeing to the control for the new chat feature.
Sounds great? There's a cost to being able to do this. The cost is that everyone involved in that bucket of tasks has to understand "the big picture for all of the user stories that those tasks relate to. If there are ten user stories in a sprint, then all the developers (and testers) need to be part of that design process for all ten stories. This means that the first few days of a sprint, you'll have to sit around a white board. It also means that you'll disagree, and it'll be frustrating at times. But you'll also have fun. You'll learn from each other, and you'll learn how they think, and you'll come to trust them over the long term.
In the short term you'll know exactly what your fellow teammates are expecting a feature to look like. You'll be able to grab a task off the stack and get going without too much time of "getting caught up" and having to have your fellow team members repeating themselves.
Otherwise you're a bunch of people working in the same room, but you're not a team. A team agrees on design, a team knows where a feature is going, and where it is at all times. Imagine a soccer game where, before you could pass the ball, you had to tell your team mate where the ball had come from, how he had to move the ball up the field, and what the goal was. It's a pretty dysfunctional picture, and the same applies for software. You have to be involved and agree from the start so you can easily jump in half way through.
One of the things Davis said was important in an Agile shop is to hire generalists. He admitted that no one is ever even in all areas (database, class libraries, UI design, client-side scripting, etc and even other non-tech areas like, um, communication), and that by the nature of being human we all have "specialties" but that the employees that work best in Agile are the ones who can do it all - there's no barrier preventing them from working on any particular task, especially when paired with someone else.
It doesn't make sense though. If you want a killer database, you have to hire the database zealot who has never come out of his Oracle cave, right? There are some projects where that will be true, where you need the specialist. But when it comes to the web, we're not talking about single platform applications. Knowing how to design a decent table structure that'll lend itself to your business objects that get passed through web services to be displayed on desktops, mobile phones, and video game consoles is a bit more practical.
We used this at Passageways to it's full advantage. No one person was ever on "the critical path", rather, the whole team was on the path. There was a bucket of tasks, and they were assigned to the team as a whole, and an individual took them when he or she was ready to work on them. So if I finish making the schema for the new reports, and then I jump over and add some themeing to the control for the new chat feature.
Sounds great? There's a cost to being able to do this. The cost is that everyone involved in that bucket of tasks has to understand "the big picture for all of the user stories that those tasks relate to. If there are ten user stories in a sprint, then all the developers (and testers) need to be part of that design process for all ten stories. This means that the first few days of a sprint, you'll have to sit around a white board. It also means that you'll disagree, and it'll be frustrating at times. But you'll also have fun. You'll learn from each other, and you'll learn how they think, and you'll come to trust them over the long term.
In the short term you'll know exactly what your fellow teammates are expecting a feature to look like. You'll be able to grab a task off the stack and get going without too much time of "getting caught up" and having to have your fellow team members repeating themselves.
Otherwise you're a bunch of people working in the same room, but you're not a team. A team agrees on design, a team knows where a feature is going, and where it is at all times. Imagine a soccer game where, before you could pass the ball, you had to tell your team mate where the ball had come from, how he had to move the ball up the field, and what the goal was. It's a pretty dysfunctional picture, and the same applies for software. You have to be involved and agree from the start so you can easily jump in half way through.
Subscribe to:
Posts (Atom)
