Agile Fashion

It’s a rather long list on Amazon.

http://icanhaz.com/AgileForSoftwareDevelopmentOrganizations

Sorted by fundamentals, then technical, some management and enterprise in there, too.

What would you like to see added to it?

If there are multiple teams working off of one Product Backlog, how best to reflect and close the iteration? I see these choices:

choice 1:
one review per team
one retrospective per team
one consolidated review for everyone at end

choice 2:
one consolidated review
one retrospective per team

choice 3:
one consolidated review
one consolidated retrospective

I have a bias to the last choice, if space is not a factor. What is yours? Do you prefer another way to coordinate these meetings?

Here are my definitions for these Scrum ceremonies.

Sprint Review: Story time.

Only stories which are DONE and accepted by the product owner as matching the criteria are reviewed. Any and all questions are answered until the time-box of the meeting lapses. Priority is on reviewing all the DONE stories and celebrating success. Questions are parked and answered last.

This is a look at what value was created(the software+artifacts) within the last iteration for the Customer and with them present. Outcome should have immediate influence on the product backlog from the Customer. Typically, items are added and some removed. Usually there is at least a little re-sort of priorities.

I am lumping stakeholders, users, product owners, and other business people together as Customers.

Preparation for a review should be no more than 4 hours.
———————–

Sprint Retrospective: Not a bitch fest, and nothing died.

Longer release-level retrospectives are not a post-mortem. Good retrospectives last awhile and are very interactive. Great retrospectives have the 5 stages as listed in the Derby and Larsen book, Agile Retrospectives, as listed on Diana Larsen’s blog. It’s also in my slide deck.

A look at how that value was created (the process+practices) and ways to apply learning. Outcome should have immediate influence on working agreements and best practices.

With smaller groups, the line blurs between the end of the review and the beginning of the retrospective, except that all the chickens are kicked out, with the exception of the Scrum Masters and Agile Coach.
———————–

I start to think of all these types of meetings as review, and have recently heard the term reflection as a way to link them. Types could be: software, artifacts, process, operations, best practices, releases, roadmap, vision, and on and on. All on a syncopated cadence.

Do you agree with these definitions? How do you like to go about them?

I also would like to mention that these ceremonies I think are necessary no matter the process, and ensure their presence in any Kanban system a team I am coaching may be using.

What does the Scrum Master do in the role, besides facilitate the daily standup? Have you ever thought perhaps a team was too dependent on the Scrum Master for this meeting? What have you done to address this issue? Right now, I’m with a group that I feel is in this predicament. This group went through training together and could rotate the position, as frequently as on a daily basis. After the training each team elected a developer to fulfill this role. Time was deducted in Sprint planning to handle the additional responsibilities of the role.

Recently after standup I asked the teams involved to raise their hand if they were a Scrum Master. One person would raise their hand. It would be the appointed Scrum Master. I then asked for those who went through the training to raise their hands, which was everyone else in the room. I then pointed out that everyone with hands raised IS a Master of Scrum. It sunk in a little.

The next test came when one of the Scrum Masters had to be absent for a standup, and notified the team. This person did not have a backup Scrum Master in place, and was hoping to see the team organize and someone volunteer for the role. Instead, the command chain appointed a team lead the duties.

It got me to thinking, what if the Scrum Masters for each team just did not show up? There would be no time to plan what to do. How would the teams organize? I’ve really been trying to impress on the teams to begin the meeting when scheduled, regardless of who is in the room. Would they think of this, and the fact that everyone is a Scrum Master, and get it going?

I then sent out the following email to them:

Subject: an experiment – don’t come to standup today

…I think the teams are too dependent on the Scrum Master. I want you to not come, not to mention it is time for standup, nothing. Do what you can to just sort of fade away without anyone noticing. I’ll be there to observe how the teams react and organize themselves…

After just a couple of minutes of wondering what was going on, each team effectively found the solution. They would remember that anyone could fulfill this role, and that the meeting must go on. The teams were effective in communicating to each other progress on their tasks, and discussing how to solve blocking issues. All the teams also finished within the 15 minutes allotted. We debriefed in the Scrum of Scrums meeting that day.

Yet I still wonder, especially as the Scrum Masters are developers on the team also responsible for creating value, do people really understand what is expected of this role besides facilitating the daily standup?

One year ago, at an event titled the “7-Minute Soapbox on User Experience Design“, three presentations touched upon the integration of usability/UCD with agile development.

A word of warning: the 7-minute duration was strictly enforced at this event, so these videos may feel more like previews than feature-length films. But it makes for easy watching! Here’s a brief summary of each:

* User-Centered Design and Agile Development at NCR
How a 2-person usability team at NCR is working to better support both design and testing activities across 30 agile projects.

* Tips for Integrating User Experience and Agile Development
Challenges, gaps, and words of wisdom for bringing these two worlds together.

* An Agile Alternative to the Ponderous Usability Test
Argues that usability testing is too slow even outside agile development and introduces the “design checkpoint” as complementary activity.

A question paraphrased from an email just received. It’s from the first team to anoint one of the new Scrum Masters for a group I coach. The reason not everyone on the team answered the 3 questions in standup …and as long as I’m just throwing in links it’s not just standing up, by the way… is because some really good discussions emerged that people were interested in. What part of the Scrum Master’s Role could help empower the team to stay focused?

Before digging in to that, I’ve also expanded a little on this definition of the role. I guess I would maybe change conflict resolution to “facilitate communication between roles”. I should also add, perhaps, “mine for conflict” as well.

To get straight to the point, who is involved in the conversation? The right Scrum Master would ensure these people get together, outside the standup.

Personally, I am a little forgetful and cannot remember who is involved in every conversation. When I hear people talking, I write down who is talking, and why. This amount of time may allow for the issue to be resolved. While I want conversations to emerge between people, I gently remind them that this is solution-izing and that we need to get all the way around the circle within 15 minutes. I also try to ensure people are standing in a circle, as well.

At the end of the standup, I run through for the team who I believe needs to follow-up and as I’ve jotted down the reason these people were talking, I can also address that if they ask me why. I allow for people to add themselves to the list. I believe it’s then up to them to figure out how best to get together for the solution-eering.

At the end of standup I also go through known impediments worked on yesterday, today, and what is keeping them from being removed.