Agile Fashion

Product Design and Development Through Collaborative Consensus

Browsing Posts published in March, 2009

Aaron: I was reading your old blog and found, “We in the Agile community need to do more to promote and encourage the rising stars of tomorrow”. What was happening at the time that prompted you to assert this?

Brian: I was at that time hanging around with a professor of sociology at the University of Illinois, who was writing a book on the British cyberneticians; very larger-than-life figures, but who had no effect. Eventually they retired, or died, and that was kind of the end of it. The first wave of people failed to build up the next wave. At the time I was wondering if we would have a next generation in Agile.

Aaron: How then did you feel that providing an award in Agile would help keep that community strong?

Brian: It would be a way of saying, “Look at this person. This person has things you need to hear.” So rather than tagging along behind Ward Cunningham at conferences, look up J.B. Rainsberger or James Shore. That’s essentially it. Listen to these people, give them opportunities to speak.

Aaron: What were some of the challenges in instituting the award?

Brian: There were none.

Aaron: There were none? Interesting because it says, “One day before the start of Agile2005, the Agile Alliance board voted to create the Gordon Pask Award for Contributions to Agile Practice.” Did you guys discuss it for a while? Was there something that led up to this vote?

Brian: We were at the end of a 2-day retrospective. Not much of immediate visibility was accomplished. It was more along the lines of: we will set deadlines, we will investigate the following in the future and I asked, “Well, why don’t we just do something?”.

I proposed the Gordon Pask Award and I probably ranted on about cyberneticians. Everybody said, “Hey, that sounds like a good idea!”. So somebody said, “How many people?” and we said, “Two.” and someone said, “How much should the award be?” and somebody said, “Well how about let’s make it something substantial like ten thousand dollars for the two of them?” and everybody said, “Great!”. It really went very fast.

Aaron: I was also noticing on “Luck” that there are some flaws to the Gordon Pask Award. Have you seen any of these troubles?

Brian: Yes, in the sense that at any given moment there are a bunch of deserving people. We always worried a lot that it would feel arbitrary. There was some talk that because of the issue we should maybe reward it to an idea. People like awarding it to a person over an idea, even though often that person represents an idea.

There have also been some worries that we could get locked in. The first two people who got the award were programmers. I’ve gotten complaints that it’s too much of a programming award and not enough of a management award and that could well be true.

Aaron: Are there different things you do to temper concerns people have?

Brian: The people involved in giving the award are all the past award participants plus the original three (Brian Marick, Rachel Davies and Big Dave Thomas) bring up the issue when we have the actual meeting.

Aaron: What comes to bear when you get together to discuss potential awardees?

Brian: We have basically divided it in to accomplishments and service. I remember in the first award I looked on my machine and saw that J.B. Rainsberger had contributed fully 37% of the posts on the test driven development mailing list. Looking through them a lot of it was spent answering questions. That’s contribution to the service, to the field. People who are active in user groups, for example.

Steve Freeman and Nat Pryce are both active in the Extreme Tuesday Club, which is where a lot of real good ideas have come from. That weighs in to it.

Aaron: Was there such a big pool that it was easy to draw from and has become tough over time?

Brian: The toughness is that there are multiple candidates. An issue that repeatedly comes up is that in theory we would like to believe that there is a person poised on the edge of some sort of break through and we can tip him right over the edge. One of the discussions we continually have in the meeting where we do the selection is, “Does this person actually need our help?”.

Aaron: I would assume that adds some difficulty in finding people that can really take advantage of what the award has to offer. Getting somebody’s name and their word out there.

Brian: Yeah, exposure. We’ve always had a discussion about, is handing somebody a check for $5000 the right idea? A better way to do that is to say the money is for speaking somewhere.

Aaron: And the idea was there because of cybernetics and knowing how much was lost through that. Was that somewhat of a prompt for you?

Brian: That was a prompt for me, yeah. I don’t know that any body else cared about that. I think they all thought, “Oh there he goes again with that ‘wierdo stuff’. It’s a good idea no matter what the motivation.”

Aaron: So I guess that ‘wierdo stuff’ is what got it to be called the Gordon Pask Award?

Brian: Right. The interesting thing about him is that he worked with communication. He had this notion of communication as a cooperative and competitive game. At the time it resonated with me when I thought about Alistair Cockburn’s stuff about projects as cooperative games and I think that was when I first heard of “pair programming ping pong” which has very much the style of Pask behind it. Of all the people he seemed to fit the closest to Agile.

  • Share/Bookmark

I recently received an email from a senior-level manager, who raises a valid question about all the meetings associated with Scrum. This particular instance of Scrum has over 50 people working in more than one locale. When yet another meeting was created, he raised a valid question:

90 minutes every week for backlog hygiene? And that is on top of all other scrums, scrum of scrums, business reviews, can we ship, planning etc. meetings and scrums? I am getting seriously concerned about our state and efficiency. If we need to spend 90 minutes on this weekly, than, IMHO, someone is not doing their job. Looking forward to find out more.

My answer:

It’s true, this is a lot of time to spend together planning what we are building for this product. Are you familiar with the book, “Death by Meeting“? Essentially, a short daily meeting (15 minute standup) should focus on the daily plan (3 questions). The longer the meeting, the further out we’re looking. Meetings should have a very specific purpose, stick to it, start on time and finish when the purpose is reached. In Scrum, all meetings are finished when they hit the time-boundary (aka time box) as well. We endeavor to reach the objective before hitting the time boundary. Scrum-of-Scrums (SoS) is a little exceptional as you’ll see.

Let’s look at all the meetings in our Scrum.

-Daily stand-up. 15 minutes max. Only pigs are allowed to speak.
Single team daily coordination. Answer 3 questions.
1. What did I complete yesterday?
2. What am I planning on completing today?
3. What’s in my way of completing work?
We stand up to keep it short.
http://aaron.sanders.name/agile/what-if-the-standup-is-ended-on-time-but-not-everyone-spoke

-Daily SoS. Meta-stand-up. Inter-team coordination.
First, answer 4 questions. 15 minutes max and again, only pigs are allowed to speak for this part.
Scrum Master and Product Owner for each team required, other team members are optional as needed and/or interested.
1. What did our team accomplish yesterday?
2. What is our team going to accomplish today?
3. What is in our team’s way?
4. What are we about to put in another team’s way?
Then, we review all the obstacles on the board. Reporter confirms removal of existing ones. Decide how to remove the ones added today. Old obstacles are scrutinized.
Last, we walk through the Air Traffic Control (ATC) board and ensure it reflects reality. If a problem is detected, a plan is set to address it.
This meeting is the only one without a time boundary. We stay in the room until all goals of the meeting have been addressed.

-Weekly backlog hygiene
Keep the backlog in front of the Scrum teams by 4-6 weeks (2-3 Sprints).
+ Review meeting agenda and ask if any item for end
+ Review customer and user input about the Product
+ Review arrangement of the stories in themes and goals.
+ Write new stories, themes and goals. Remove old and wrong ones.
+ Review and update acceptance criteria currently known.
+ Prioritization
+ Team added agenda item, wrap-up.
Add new stories, keep the top prioritized. Look at the bigger backlog map. This will become the release planning mechanism. 90 minutes does seem long right now. Prioritization is not an easy endeavor. I would also like to enhance understanding of the User Story and examine the ones being added together. Some are coming in from user interviews. More are likely with Customer Support involvement. There are some interviewing-like ways to create them, so that eventually the customer/user can write them for us themselves. The time will also be needed later, once the teams pick up value delivery. All of this will intensify to stay in front of the progress we make.

-Review and Retrospective (aka Reflection)
Every 2 weeks we review the current working software with the customer, showing User Stories the Product Owners have accepted on their behalf. We then ask *them*, can we ship this to you? The answer will influence the backlog, too. The teams then gather and go through a retrospective to ask themselves, how did those last 2 weeks go and what would we like to change and experiment with to find improvements and innovation?

-Planning
We are now planning as we go at many different levels, so that is much less disruptive to the teams. For the pigs involved who are busy creating value, it is an impact of 15 minutes daily, and 2-4 hours for one day every couple of weeks. We are meeting so that they can continue to do their job of creating the actual Product.

-and more!
There should also be monthly meetings to look at the next 3 months, and quarterly meetings to look at the next 4 quarters, and yearly meetings to look at the next 3 years. That last one may be a 2-3 day off site.

http://leansoftwareengineering.com/2007/11/14/planning-a-month-or-less-ahead-is-not-enough/

This is a complex, adaptive system with emergent properties. The system is continuously running at a sustainable pace, with value flowing through it from concept to cash. We need constant feedback so that we may inspect this system and ensure we are adapting to the best of the emergent capabilities. The concepts are captured as User Stories, and when we release it we determine the market value, when we start getting revenue from the Product. Along the way we keep our customer/user involved at every step and invite them to attend any meeting. Except the Retrospective, which is for the pigs.

The ATC board shows all stories in progress for all teams. It includes the top of the backlog in a stack-rank buffer for teams to accept work from when they have delivered something and have capacity (below the story point WIP limit).

There are more than the 4 meetings mentioned in the book: stand up, SoS, review, retrospective, can we ship?, planning, backlog hygiene. The longer-term Agile strategic meeting is not yet in place. How else should I address the concern? Is there too much mixing up of strategic goals in the weekly tactical backlog hygiene meeting? Should that be pulled out to the monthly strategic meeting? What should be in the tactical one, then? What could be removed from a meeting, or a meeting itself? How would you redo these to be more effective?

  • Share/Bookmark
Design by SRS Solutions