Daily Stand-ups: Workshop

Recently, after analyzing how we are doing on our daily stand up meetings I decided to run a small coaching workshop with the team. The purpose was to emphasize the value of a daily stand up meeting and figure out how to improve. In my opinion great place to run such workshops is a sprint retrospectives meeting. Everyone is already in the "learning mode" which makes the time right.
Here is a summary of the workshop:

• Open the discussion asking the team what value stand-ups have in their eyes. You will be surprised with the answers. Some folks will see certain benefits while others will see no benefits at all.
• Ask the team what the purpose of stand-ups is?
• Explain that daily stand-ups are for the team to:
• Daily sync-up: Be aware of the overall status (what's on track, what's behind, what's blocking, what the risks are, what new tasks were identified)
• Set direction and focus
• Perform a daily to weekly planning
• Share observations on how do our stand-ups look right now (our example):
• What I worked on, What I will be working on
• Some technical details of individual tasks
• Occasional planning during stand-up
• Occasional planning post stand-up
• Elaborate on how you'd like to see our stand-ups going forward:
• A place to self-organize on daily basis: For The Team, By The Team
• What I have accomplished since last stand up
• What I plan to accomplish by the next stand-up
• What needs to happen in order for me to accomplish the task (what blockers need to be removed, what coordination with others has to happen)
• This does happen on occasion, so I'd like to emphasize the value of this kind of stand-up.
• Problem solving: Parking Lot for post stand-up discussion
• Move from "Story telling" to "Headlines"
• Next move on to discussing the actual examples. Story telling exercises are the best because they create mental hooks that help people relate to these stories in the future easily. For each example ask the team following questions: 
• What is good about this stand-up meeting example?
• What can be improved?

Examples:
Show
Hide


Example 1
John: Since yesterday I was working on the new report; Today I will continue working on this report; Nothing is blocking.
Mary: I have nothing to test in this sprint yet, but I have some bug retests so this is what I've been doing pretty much in the last few days and planning on continuing with retests until User Story 123 is ready for testing.
Avanti: Yesterday I was fighting the Web Server configuration issue. Eventually I've found that there was an issue with database connection polling settings. Basically there was not threads pooled and this was affecting the throughput and therefore end user response time. I have found several articles and forum discussions about it and have left a message in few threads. Just few minutes before the stand up meeting I've got a response from some guy with reference to Weblogic article about suggested threads defaults in development vs. production.


Example 2
John: Yesterday I was working on a new report. I've implemented the UI based on the UX that Ivan designed and started implementing the query. This was a big task and I wasn't supposed to complete it yesterday. My plan for today is to complete the query and to complete the report. Mary should be able to get a first look at it later tomorrow.
Mary: Since yesterday I haven't done any work on this project since there is nothing ready to be tested. From what I just learned, John might be done with development of the new report by tomorrow, so today I will write the test cases and will review them with John.
Avanti: Yesterday I was fighting the Web Server configuration issue. Eventually I've found that there was an issue with database connection polling settings. I'm not blocked anymore and will plan on completing the configuration by tomorrow.


Example 2 - the next day
John: Since Yesterday I've completed the new report and have reviewed the test cases with Mary. Today I will be working on a spike about new authentication mechanism and plan to spend 2 days on it. By tomorrow I plan on reading framework documentation and setting environment.
Mary: Yesterday I've spend most of the time on bug retests and also had test cases written and reviewed them with John. I'm waiting on a build to perform the actual testing. I expect that I will have some time to look at any other completed functionality so folks, please let me know if there is anything for me to look at.
Avanti: Yesterday I've completed the web server configuration and it's ready to be replicated to our staging areas. Today I was planning to start working on US 234, but I need someone to bring me up to speed on it as I was on vacation during grooming and planning sessions.


Example 3
Alex: Yesterday I've completed the last task on US 323 which was to update the design documentation. Today I'm going to switch to US 454. No blockers.
Garry: Yesterday I continued working on US 323 and I keep getting these runtime errors that didn't occur even few days ago, so I'm pretty much stuck. Today I'll continue debugging this.
Jose: Yesterday I was working on the new interface to the provisioning system. I have completed this interface and will call a quick meeting to show it to few folks: it's important that we'll get it right, so I'd like to get some feedback early. Later today I have several meetings so I won't be able to complete much by tomorrow, although I'm planning to at least start writing the detailed design for the upcoming US 676.
Cathy (Scrum Master): Garry, what help you might need to move forward with this task?
Garry: I'd like to have another set of eyes with me looking at this issue as I'm going crazy here.
Alex: Garry, let me help you out here. I think it makes sense to declare victory on US323 before looking into next user story.
Garry: That would be great!

Knowing the path

In “Made to Stick” Chip & Dan Heath talk about “The Curse of Knowledge” as a term used to describe a situation where a person has a lot of knowledge on a subject, but has difficulty to assimilate it among his peers, or coachees. In “The Matrix” Morpheus and Neo exhibit classic coach – coachee relationship, where Morpheus asks the right questions at right times helping Neo to discover the answers instead of giving them out. During the past 2 years, and especially during last 3 months since the Agile pilot start I have experienced “The Curse of Knowledge” first hand and I saw how difficult it is to hold my tongue when the answer is obvious to me. I didn’t succeed to hold my tongue all the time and it was evident that when I did – the answers took longer to surface, but the effect was great: the sense of ownership and commitment from the group was much higher. It really seems easier that it is… I’m seeing every day my colleagues, whom I would define as excellent coaches, struggling with holding the tongue and rushing to give the answers right away.

With Agile mantra of self-organization, where managers “give-up” the decision making power delegating it to the team, the requirement for this new behavior becomes more evident and we all start paying more attention to the decision making process in the Engineering organization.
Here is an example. In the last sprint we had 3 user stories being worked on. At the sprint planning I have mentioned that the way to attack these 3 stories is one by one and not to work on all 3 at the same time (to the degree possible with all the constraints and dependencies). This idea seemed redundant and everyone was sure that if they work in the priority order of their tasks this will be achieved automatically. Few days before the sprint end the team has realized that none of the stories is likely to make it. This time, instead of bringing this idea up again, I asked few questions that have leped the team to come to this idea themselves. One team member suggested to abandoning the bigger story that had no chance in getting done in favor of other two stories that could be completed with the team effort. Another team member suggested next time the team attacks one story at a time – and this seemed reasonable. Eventually, we’ve attacked the last two stories with  as real team effort and got them accepted in time. I could have said “I told you so!”, but this of course would be counterproductive. When the team has come to this realization by themselves they felt ownership of this idea and were committed to try it again in the next sprint.

Hiring a coach

Agile coaching is a hot topic now – great opportunity for anyone who is in software or management consulting business to capitalize on on this new “trend”. How do you choose a coach that is right for you? To answer this question let’s focus on what we are trying to achieve. We need a coach to accompany our Agile transformation because we do not have enough expertise in-house – sounds like a good reason to hire a consultant. Our initial thought was to find a coach who has “done it” with companies of our size and with similar transformation context. We were focusing on challenges this coach had with other teams and whether he/she was successful to address these challenges, and how creative he/she was in addressing them. Here are some good questions to ask the candidate:

1. How would you address the limited shared resources situation, knowing that company cannot hire additional personnel? Specifically, how would you suggest dealing with 1 UX Designer serving simultaneously 3-4 teams? How about Product Owner serving 2-3 teams?
2. Pure SCRUM promotes approach of evolving architecture, while focusing on juiciest features. This is one area where we will not follow the guideline and would take RUP based approach, investing in architecture in the beginning. How would you approach this kind of projects, knowing this constraint?
3. Would you engage offshore team in pilot projects? If yes, would you try to co-locate or to mix teams (current model is mixed/extended teams)?

Like with hiring any senior resource it’s important to look for behavioral patterns through thought process exposed while answering the questions.
Another important aspect that we felt was necessary is coach background. It’s definitely an advantage when the coach is coming from development background experienced in both Waterfall and Agile environments. This is because there will be a higher chance to ”click” with engineers on fresh Agile teams.