Idea: I want to put a small group of us (6-ish?) in a room for a week and develop an app. There may or may not be an iOS expert among us. We'd be using scrum/lean techniques and the goal is for each person to learn something new. The purpose of the end product is to demonstrate what we have learned.
Motivation: I need to become proficient at iOS programming. So, I am using this as an opportunity for me to conduct an experiment in alternative models for teaching software development/design, by holding a "boot camp" on the topic.
Who: Programmers, graphic designers, UX designers, and domain experts with some software-related learning objectives. You don't have to be the best programmer or have any experience in iOS; you just have to be motivated and want to learn. For example, you might be a programmer, but always wanted to try your hand at project management. Or you might run a non-profit and want to learn how to give requirements for some software. Or you may be graphic designer who wants to get more involved in programming.
Who Not: This boot camp is not suitable for people who are expecting a lecture and well-crafted assignments. It is also not a for someone looking for free labour to develop the app that they have been planning for a long time.
Where: Toronto, either at a home in the Yonge/Lawrence area or at UofT
When: First week of August. I imagined this to be 4-5 days, 9-5-ish with lunch breaks. But if I get enough interest from people who have day jobs, we might do this over two weekends. I am also looking into the possibility of providing childcare for participants.
How: We will be working in pairs most, if not all, of the time. We'll be doing short (1-day) sprints. We'll work hard, but we'll have a sustainable pace. We will all be working on an app together-- I make no promises on the quality of the final product. The app itself with depend on the learning objectives of the participants, and we will decide together during the planning meetings.
Next Steps: Drop me an email (benevolentprof at gmail) to let me know you're interested. Tell me a bit about yourself, your availability, and what you'd like to learn at the boot camp. We'll have one or two meetings in advance to identify our collective goals for the boot camp and to do some scrum planning.
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Wednesday, July 13, 2011
Wednesday, March 2, 2011
Overcoming the loud-mouthed shnook in Planning Poker by using Crowd Wisdom
A common problem when using Planning Poker is some people who are more opinionated or argumentative can dominate the estimation process. This usually happens because the standard method for using Planning Poker is to make independent estimates and discuss until all the estimates converge. Crowd wisdom may be able to offer us a way out.
The idea behind crowd wisdom is that together we are smarter than any one of us. This is the central idea behind crowdsourcing. Any one person's contribution is checked and improved by other people. Consequently, these reviews are just as important as the initial contribution. Wikipedia, open source software, and remix culture are classic examples of this.
In the book "The Wisdom of Crowds," author James Surowiecki gives a number of examples. At a county fair, a prize was offered to the person who could guess the butchered weight of a cow. The average of all the guesses was closer to most individual guesses, including some cattle experts. When a submarine was lost at sea, an assembled team of experts made a number of best guesses for the location of the vessel. Ultimately, the submarine was found within 220 yards of the aggregation of these guesses. Pretty impressive, considering the size of the North Atlantic.
In a nutshell, Planning Poker is used to generate estimates for software development task items. In agile terminology, it's used to allocate story points to User Stories. Typically, the number of different possible values for the estimates is constrained, e.g. 1, 2, 3, 5, 8, 12, 20. Each team member, comes up with their own estimate. All of these estimates are revealed simultaneously using Planning Poker cards. More often than not, these are a variety of estimates. The recommended solution is to discuss these differences in estimates to reveal assumptions. Independent estimates followed by simultaneous sharing is repeated until the group reaches consensus. (For software engineering wonks, this is just a twist on the Delphi method.)
Surowiecki identified four elements that are necessary to use crowd wisdom successfully. These are diversity of opinion, independence, decentralization, and aggregation. To apply crowd wisdom to planning poker, we would need to do the following.
Diversity of opinion means that each person is allowed to form their own opinion, even if it's based on private information or an eccentric interpretation of established facts. I believe that this is already built in to Planning Poker, by having a group create the effort estimates.
Independence means that people's opinions aren't determined by the opinions of others. Planning Poker already allows for this, because individuals come up with their own estimates separately before sharing them with the group.
Decentralization means that people should be allowed/required to draw on specialized or local knowledge. In Planning Poker, you'd have a cross functional team do the estimating. This is a good practice anyways, so should not be a big change.
Aggregation is the mechanism for turning the individual, private judgements/opinions into a collective decision. In Planning Poker, this should be relatively straightforward, since we are working with numbers. A reasonable mechanism would be to take the average of the numbers.
This last element diverges the most from conventional Planning Poker. The rationale behind coming to a consensus estimate is that an average isn't a good estimate for any one person. Just as the average family has 1.7 children, but no one family has 1.7 children, because children only come in whole units. Nevertheless, this is a supposed to be the strength that underlies crowd wisdom.
My guess is a hybrid would probably be best. The discussion after the estimates are shared are invaluable for improving the team's understanding of the software being developed. But the average of the initial estimates is the best guess of all.
I'd be interested in hearing from anyone who has tried using crowd wisdom with Planning Poker. Did it work for you?
The idea behind crowd wisdom is that together we are smarter than any one of us. This is the central idea behind crowdsourcing. Any one person's contribution is checked and improved by other people. Consequently, these reviews are just as important as the initial contribution. Wikipedia, open source software, and remix culture are classic examples of this.
In the book "The Wisdom of Crowds," author James Surowiecki gives a number of examples. At a county fair, a prize was offered to the person who could guess the butchered weight of a cow. The average of all the guesses was closer to most individual guesses, including some cattle experts. When a submarine was lost at sea, an assembled team of experts made a number of best guesses for the location of the vessel. Ultimately, the submarine was found within 220 yards of the aggregation of these guesses. Pretty impressive, considering the size of the North Atlantic.
In a nutshell, Planning Poker is used to generate estimates for software development task items. In agile terminology, it's used to allocate story points to User Stories. Typically, the number of different possible values for the estimates is constrained, e.g. 1, 2, 3, 5, 8, 12, 20. Each team member, comes up with their own estimate. All of these estimates are revealed simultaneously using Planning Poker cards. More often than not, these are a variety of estimates. The recommended solution is to discuss these differences in estimates to reveal assumptions. Independent estimates followed by simultaneous sharing is repeated until the group reaches consensus. (For software engineering wonks, this is just a twist on the Delphi method.)
Surowiecki identified four elements that are necessary to use crowd wisdom successfully. These are diversity of opinion, independence, decentralization, and aggregation. To apply crowd wisdom to planning poker, we would need to do the following.
Diversity of opinion means that each person is allowed to form their own opinion, even if it's based on private information or an eccentric interpretation of established facts. I believe that this is already built in to Planning Poker, by having a group create the effort estimates.
Independence means that people's opinions aren't determined by the opinions of others. Planning Poker already allows for this, because individuals come up with their own estimates separately before sharing them with the group.
Decentralization means that people should be allowed/required to draw on specialized or local knowledge. In Planning Poker, you'd have a cross functional team do the estimating. This is a good practice anyways, so should not be a big change.
Aggregation is the mechanism for turning the individual, private judgements/opinions into a collective decision. In Planning Poker, this should be relatively straightforward, since we are working with numbers. A reasonable mechanism would be to take the average of the numbers.
This last element diverges the most from conventional Planning Poker. The rationale behind coming to a consensus estimate is that an average isn't a good estimate for any one person. Just as the average family has 1.7 children, but no one family has 1.7 children, because children only come in whole units. Nevertheless, this is a supposed to be the strength that underlies crowd wisdom.
My guess is a hybrid would probably be best. The discussion after the estimates are shared are invaluable for improving the team's understanding of the software being developed. But the average of the initial estimates is the best guess of all.
I'd be interested in hearing from anyone who has tried using crowd wisdom with Planning Poker. Did it work for you?
Wednesday, February 9, 2011
The Scrum Mistress' Guide to Standing Up Daily
This is my second of two posts on my experiences while attending a CSM course. The first post appeared a couple of days ago.
Just before lunch on the second day, Mike wanted to do a short exercise on running daily stand up meetings. He asked for a volunteer to be a scrum master. I paused a moment to give other people a chance to have the educational experience, before I enthusiastically put up my hand. Although I've studied scrum, I've never actually had a chance to use it.
After I trotted to the front of the room, Mike started to look for other volunteers. He jokingly said that it would be fun for everybody except the scrum master. He handed an index card to each of the volunteers, who joined me at the front.
I wondered what was on the cards. Could it be the user stories that they were working on?
When we were assembled, Mike stepped out of the way and told us to have our meeting. I turned to the group and they all started talking at the same time. I thought to myself, "Oh, it's like that is it?"
I started to pull out my various tricks for crowd control. In my day job, I teach classes of 50-100 undergraduate students. There's always a joker/talker in the class. Also, some days are more difficult than others. It's like a whole bunch of them had something in their breakfast that made them extra fidgety and extra talkative. Here are some of the strategies that I used.
Needless to say, I had a lot of fun. A lot of these tactics are very heavy handed and I wouldn't necessarily use them in a normal team situation. I definitely took advantage of the fact that this was a classroom exercise that involved role-playing. In an actual work situation, I would let the team have some runaway meetings, maybe have a meeting where we discussed protocols for daily standups, and met one-on-one with the most problematic team members.
At the end, Mike said, "Wow, you got them through it. Susan is small but scary." He also asked the group if the meeting looked familiar. A number of people in the class, all of them women, agreed enthusiastically. One woman said that the exercise was too close to home.
I was taken aback by this. I had seen some daily standups led by a woman, where the team members were infantile and even rude to the scrum master. But I always thought that this was an exception. So, I started to wonder.
Do women scrum masters encounter special challenges because of their gender? How many of you out there are dealing with unruly meetings? Do you have an advice or war stories to share?
Just before lunch on the second day, Mike wanted to do a short exercise on running daily stand up meetings. He asked for a volunteer to be a scrum master. I paused a moment to give other people a chance to have the educational experience, before I enthusiastically put up my hand. Although I've studied scrum, I've never actually had a chance to use it.
After I trotted to the front of the room, Mike started to look for other volunteers. He jokingly said that it would be fun for everybody except the scrum master. He handed an index card to each of the volunteers, who joined me at the front.
I wondered what was on the cards. Could it be the user stories that they were working on?
When we were assembled, Mike stepped out of the way and told us to have our meeting. I turned to the group and they all started talking at the same time. I thought to myself, "Oh, it's like that is it?"
I started to pull out my various tricks for crowd control. In my day job, I teach classes of 50-100 undergraduate students. There's always a joker/talker in the class. Also, some days are more difficult than others. It's like a whole bunch of them had something in their breakfast that made them extra fidgety and extra talkative. Here are some of the strategies that I used.
- I put my hand up, way up, to get attention. I'm about 5 feet tall (~150cm), so putting my hand up gets it about eye level for most of the guys. This is the universal signal for I have something to say and it usually gets people to stop talking for a split second, so I can get a word in edgewise. As a woman, one must never shout, because one ends up sounding shrill.
- I used my eyes to place a laser-like focus on the person who was supposed to be talking. The other team members will use my eyes as a cue for their attention as well.
- I used my aerosol can of "ssh" (in the style of Austin Powers) on one particularly disruptive team member.
Needless to say, I had a lot of fun. A lot of these tactics are very heavy handed and I wouldn't necessarily use them in a normal team situation. I definitely took advantage of the fact that this was a classroom exercise that involved role-playing. In an actual work situation, I would let the team have some runaway meetings, maybe have a meeting where we discussed protocols for daily standups, and met one-on-one with the most problematic team members.
At the end, Mike said, "Wow, you got them through it. Susan is small but scary." He also asked the group if the meeting looked familiar. A number of people in the class, all of them women, agreed enthusiastically. One woman said that the exercise was too close to home.
I was taken aback by this. I had seen some daily standups led by a woman, where the team members were infantile and even rude to the scrum master. But I always thought that this was an exception. So, I started to wonder.
Do women scrum masters encounter special challenges because of their gender? How many of you out there are dealing with unruly meetings? Do you have an advice or war stories to share?
Tuesday, February 8, 2011
When should we be using pair programming (or writing)?
I attended Certified Scrum Master training with Mike Cohn last week. I have been teaching agile and scrum to undergraduates for about six years now and I thought I should finally get my certification. Although I had the "book knowledge" down pat, I learned a lot from the Q&A and from the conversations that I had at my table. This post is the first of two that I will be writing about my experiences.
One of the people at my table was Andrew Mutz, Director of Software Engineering of AppFolio in Santa Barbara. He joined his organization two years ago and has been using scrum since then. I used the opportunity to pick his brains about his experiences. I was impressed by the software development practices that they use at his organization-- Lots of common sense and a good balance between engineering principle and business goals. (They're hiring, by the way.)
We got onto the topic of pair programming. We both agreed that there were many good things about pair programming. Appfolio has all new hires pair for the first three months or so. I didn't mention this at the time, but there are research literature to support some of our intuitions. Laurie Williams, Ron Kessler, and Ward Cunningham had a paper in IEEE Software in July/August 2000 on "Strengthening the Case for Pair Programming." They reported on studies by other researchers and their own work. Pairing increased the effort (person-hours) by 60%, but reduced the timeline (elapsed time) by 40%. Programmers produced higher quality code (pass more test cases), were happier, and were more confident.
We also agreed that not all tasks benefited from pairing. There were some tasks that were so simple (tedious?) that having another pair of eyes was not helpful.
However, we disagreed on the value of pairing on difficult tasks. Andrew argued that the value of pairing diminished with more complex tasks. Consequently, the graph of value vs. difficulty would look like a typical ROC (receiver operator characteristic) curve. This line is shown in blue in Figure 1.
My impression was that the value of programming increased along with the difficulty of the task. This line is shown in green in Figure 1. Most of my direct experience with pairing is in writing and brainstorming research. But it's also based on conversations that I have had with professional developers who use pair programming. It's entirely possible that Andrew is right and I just haven't experience the top end of the difficulty axis.
Our conversation went on and we also agreed that pairing would be less useful for program comprehension, i.e. trying to understand an unfamiliar code base, if we used the conventional model. However, if we could have two people working side-by-side with a computer each, it might be useful to pair. On one occasion, I was working with two students to come up with a research question for a grant proposal. We were sitting around a table, each with our own computer. We went through cycles of brainstorming, critiquing each other's ideas, and doing searches of the academic literature to see what had been done before and to get new ideas. We managed to eliminate a lot of dead ends quickly.
I'm sure that there are other situations that are worth discussing.
What do you think? When should we be using (or not using) pair programming?
One of the people at my table was Andrew Mutz, Director of Software Engineering of AppFolio in Santa Barbara. He joined his organization two years ago and has been using scrum since then. I used the opportunity to pick his brains about his experiences. I was impressed by the software development practices that they use at his organization-- Lots of common sense and a good balance between engineering principle and business goals. (They're hiring, by the way.)
We got onto the topic of pair programming. We both agreed that there were many good things about pair programming. Appfolio has all new hires pair for the first three months or so. I didn't mention this at the time, but there are research literature to support some of our intuitions. Laurie Williams, Ron Kessler, and Ward Cunningham had a paper in IEEE Software in July/August 2000 on "Strengthening the Case for Pair Programming." They reported on studies by other researchers and their own work. Pairing increased the effort (person-hours) by 60%, but reduced the timeline (elapsed time) by 40%. Programmers produced higher quality code (pass more test cases), were happier, and were more confident.
We also agreed that not all tasks benefited from pairing. There were some tasks that were so simple (tedious?) that having another pair of eyes was not helpful.
However, we disagreed on the value of pairing on difficult tasks. Andrew argued that the value of pairing diminished with more complex tasks. Consequently, the graph of value vs. difficulty would look like a typical ROC (receiver operator characteristic) curve. This line is shown in blue in Figure 1.
 |
| Figure 1: Difficulty of Task vs. Value of Pair Programming |
My impression was that the value of programming increased along with the difficulty of the task. This line is shown in green in Figure 1. Most of my direct experience with pairing is in writing and brainstorming research. But it's also based on conversations that I have had with professional developers who use pair programming. It's entirely possible that Andrew is right and I just haven't experience the top end of the difficulty axis.
Our conversation went on and we also agreed that pairing would be less useful for program comprehension, i.e. trying to understand an unfamiliar code base, if we used the conventional model. However, if we could have two people working side-by-side with a computer each, it might be useful to pair. On one occasion, I was working with two students to come up with a research question for a grant proposal. We were sitting around a table, each with our own computer. We went through cycles of brainstorming, critiquing each other's ideas, and doing searches of the academic literature to see what had been done before and to get new ideas. We managed to eliminate a lot of dead ends quickly.
I'm sure that there are other situations that are worth discussing.
What do you think? When should we be using (or not using) pair programming?
Subscribe to:
Posts (Atom)