This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.
I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.
This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.
Tools required:
- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- pens
- play-food could be optional to make it more fun!
Set the Stage:
Have the group split into small groups of 3, depending on class size. I had 3 groups of 4 in this particular class. As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back. You can leave the room, but I stayed in the room to hear the type of conversation that is happening.
Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)
Expected result:
- ideally you will get at least 2 different orders. In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise
Observations:
- immediately I heard conversations like “what did he mean? does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best
Learnings:
- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
- the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily
I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other! I plan to try this exercise again, the feedback from the group was unanimous. They all ‘got it’ that the point of the user story was the conversation. I start each class with a focus question and this exercise quickly answered about half of the responses. Most were concerned about the story missing details, how can I write better stories for the team etc.
Would love to hear your thoughts!
Agile Coach Camp 2010 is coming the weekend of March 19, 2010 in North Carolina. I’ve heard great things about Coach Camp and this is my first opportunity to attend. You can check out their site here and for those who aren’t familiar with Coach Camp, it’s an Open Space conference focused on peer-to-peer learning and exploration as opposed to the traditional speaker/audience conferences I’m not a huge fan of.
Anywho, onto the position paper: You’ll notice these are high-level points, that’s the point of Coach Camp. The goal is to share experience and gain feedback from the Agile community.
Title: A Recipe for Enterprise Agile Transformation
Background and Challenges:
- large department within large organization
- tall hierarchy, great deal of office politics
- heavily silo’d organization
- complex product portfolio
- mix of full time, contractors, outsourced developers and teams
- limited people with Agile experience in the organization
- no recognized Agile champion
Speaking and Presentation topics I plan to share:
- transitioning focus of functional managers and other roles
- there is much confusion about ‘where does my role fit’?
- breaking down silos between multiple groups
- having to prove you are worthy of being trusted
- demonstrating and sharing success and failures
- portfolio and team organization
- how to structure your teams with the right skills for the project
- techniques for handling ’specialist’ groups
- how these groups interface with teams
- how these groups share information gained from working with multiple teams
- cross-project knowledge sharing (technical or process related)
- getting people together to talk about experiences.
- How PMO and process teams evolve
- more teaching and coach, less command and control
- spreading Agile culture
- making it about the organization, not the coaches
- teaching the organization to think for themselves
The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.
I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details. Interested in your thoughts and experiences!
Ah, good old re-work. The thorn in the side of Scrum teams, the impossible mountain to climb for development teams. Re-work is un-avoidable. When people see working software, they get new ideas and might want some changes. Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.
If We Knew Earlier, We Coulda Did Something About it
Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work. Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.
Problem: Waiting too long to get feedback.
Solution: I’m happy the team came to this conclusion themselves in the retrospective. One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo? Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.
Splitting the Iteration into Work and Re-work Phases
Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.
Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well. The work this team does is non-software and they rely frequently on interacting with people in other departments. They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.
Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part. Not so at all. I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do. Perhaps a Kanban system would be more effective for them. We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.
Agile/Waterfall Hybrids is What we Did!
This one came up in a training session I was doing. One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile. The solution to this is similar to the first scenario I discussed at the start of this post.
The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process. A deeper problem was the apparent separation between programmers and testers on the team he was talking about. I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.
All of these examples, in my opinion, are some of the main reasons why companies fail with Agile. They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us. While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process. This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.
It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.
