When working with new Scrum teams, team members often don't recognize what is impeding them because even though something is obvious to me, to them it's business as usual.
Working with these new teams, I've stumbled upon a way to structure their thinking around this retrospection: Identifying the Most Productive Mode. Once the team knows what their most productive mode is, they can see what is impeding their ability to reach that state. Once they "see it" then they can do something about it such as bringing it up at standup.
MOST PRODUCTIVE MODE
Teams under stress will feel that cutting out some of their new development practices will somehow make them go faster. This is a natural reaction to fear--going back to the old way. This is why it's so important for each team member to intellectualize (know) why they are doing the practices and how *not* doing them will slow them down.
It's better to deliver as much code as you can with your new good practices and communicate what is keeping you from reaching your most productive mode:
Characteristics of productivity
Focus-- focus on one task at a time and getting the artifacts finished and checked in before dealing with distractions (email, phone, meetings, lunch break). Do this work with another (pair programming) who can bring immediate feedback, mentorship, and different perspective
Quick Feedback-- create feedback loops so you know ASAP that something is right or wrong:
writing tests and code in baby-steps (Test Driven Development);
executing the unit tests at least once every fifteen minutes and recognizing you've bitten off too much to do in one step when you can't (a coverage report is a medium-slow feedback mechanism, but will be a constant one once we get it fixed so it gives you feedback every time you run the tests in JUnit); and
getting feedback on the product owner as soon as a story is done.
When something gets in the way of you reaching your most productive modes, something is impeding you. (Examples: the unit tests take more than 30 seconds to run, the IDE is difficult to setup into a productive state, it's hard to setup a pairing station, people/email/IM keep taking you out of your most productive state, you've been pairing too long and you want to disagree with everything your partner is saying so you need a break, you come into work too tired to interact with people because you were up late developing code at home/work.) We're human, sometimes these can't be avoided. If most of the time you can't reach your most productive mode, then something is wrong.
PREPARATION FOR YOUR MOST PRODUCTIVE MODE:
Clarity--
* You should know what is on the sprint backlog. If you're confused about this, then something is dearly wrong! During standup, if you can't see how what someone is saying maps back to the backlog, then ask. If they don't know, then solve the problem: stop working on stuff that's not on the backlog.
* Get those definitions of done for a Sprint and a Release in a clear, easy to understand state. If it has 20 separate items and you need a lawyer, it doesn't help with clarity.
* You should know your velocity by sprint planning for the next sprint.
* At standup, the team members should all understand at some level what each person is saying. If you don't have a clue, say "what's that about?" so you know. Sometimes you'll realize it isn't helpful for person A to recount a blow-by-blow of a meeting about some other concern that has little to no impact to your project. In that case, ask them to parking lot it or follow up after standup with the one other person they are talking to.
* Standups > 15 minutes should be an anomaly. If they aren't then something is wrong. Keep standup focused on the team talking to each other about the three questions. Make it clear when standup is over and your going to shift into something else so people can leave or understand what you are about to go into is a hallway meeting. Otherwise, standups turn into 45 minute hallway meetings every day. Immediately raise impediments during standup about why standup is going too long (trying to do release planning, trying to solve a problem by falling into a 5 minute discussion).
* Use the fist of five. It's simple and effective.
* Come to standup prepared. You may need to make some notes. You may need to meet with a subset of the team *before* standup (the ones which could be a 1-2 on a fist-of-five) and have those long discussions so you have some alignment so standup goes smoother.
* Use big visible charts. If you're team has a problem, then make a chart. If your standups run too long, make a chart of the time. If the team sees the chart, but refuses to adjust despite that, then you need another approach. (Setting an egg timer for two minutes and passing it around to each speaker really works because it provides a quick feedback mechanism). By day three most of them will have figured out how to communicate effectively in that constraint.)
Working with these new teams, I've stumbled upon a way to structure their thinking around this retrospection: Identifying the Most Productive Mode. Once the team knows what their most productive mode is, they can see what is impeding their ability to reach that state. Once they "see it" then they can do something about it such as bringing it up at standup.
MOST PRODUCTIVE MODE
Teams under stress will feel that cutting out some of their new development practices will somehow make them go faster. This is a natural reaction to fear--going back to the old way. This is why it's so important for each team member to intellectualize (know) why they are doing the practices and how *not* doing them will slow them down.
It's better to deliver as much code as you can with your new good practices and communicate what is keeping you from reaching your most productive mode:
Characteristics of productivity
Focus-- focus on one task at a time and getting the artifacts finished and checked in before dealing with distractions (email, phone, meetings, lunch break). Do this work with another (pair programming) who can bring immediate feedback, mentorship, and different perspective
Quick Feedback-- create feedback loops so you know ASAP that something is right or wrong:
writing tests and code in baby-steps (Test Driven Development);
executing the unit tests at least once every fifteen minutes and recognizing you've bitten off too much to do in one step when you can't (a coverage report is a medium-slow feedback mechanism, but will be a constant one once we get it fixed so it gives you feedback every time you run the tests in JUnit); and
getting feedback on the product owner as soon as a story is done.
When something gets in the way of you reaching your most productive modes, something is impeding you. (Examples: the unit tests take more than 30 seconds to run, the IDE is difficult to setup into a productive state, it's hard to setup a pairing station, people/email/IM keep taking you out of your most productive state, you've been pairing too long and you want to disagree with everything your partner is saying so you need a break, you come into work too tired to interact with people because you were up late developing code at home/work.) We're human, sometimes these can't be avoided. If most of the time you can't reach your most productive mode, then something is wrong.
PREPARATION FOR YOUR MOST PRODUCTIVE MODE:
Clarity--
* You should know what is on the sprint backlog. If you're confused about this, then something is dearly wrong! During standup, if you can't see how what someone is saying maps back to the backlog, then ask. If they don't know, then solve the problem: stop working on stuff that's not on the backlog.
* Get those definitions of done for a Sprint and a Release in a clear, easy to understand state. If it has 20 separate items and you need a lawyer, it doesn't help with clarity.
* You should know your velocity by sprint planning for the next sprint.
* At standup, the team members should all understand at some level what each person is saying. If you don't have a clue, say "what's that about?" so you know. Sometimes you'll realize it isn't helpful for person A to recount a blow-by-blow of a meeting about some other concern that has little to no impact to your project. In that case, ask them to parking lot it or follow up after standup with the one other person they are talking to.
* Standups > 15 minutes should be an anomaly. If they aren't then something is wrong. Keep standup focused on the team talking to each other about the three questions. Make it clear when standup is over and your going to shift into something else so people can leave or understand what you are about to go into is a hallway meeting. Otherwise, standups turn into 45 minute hallway meetings every day. Immediately raise impediments during standup about why standup is going too long (trying to do release planning, trying to solve a problem by falling into a 5 minute discussion).
* Use the fist of five. It's simple and effective.
* Come to standup prepared. You may need to make some notes. You may need to meet with a subset of the team *before* standup (the ones which could be a 1-2 on a fist-of-five) and have those long discussions so you have some alignment so standup goes smoother.
* Use big visible charts. If you're team has a problem, then make a chart. If your standups run too long, make a chart of the time. If the team sees the chart, but refuses to adjust despite that, then you need another approach. (Setting an egg timer for two minutes and passing it around to each speaker really works because it provides a quick feedback mechanism). By day three most of them will have figured out how to communicate effectively in that constraint.)
No comments:
Post a Comment