Group items tagged

Try a 'speed retrospective'. How quickly can the team get together and find one good, solid improvement to make? Make it exciting and use a stopwatch. I wouldn't do this all the time, but again, what harm to try it once?

How about one retrospective where you set yourselves the challenge of generating actions from the "What did we do well" column? In other words, find an action designed to magnify an existing positive rather than remedy an existing negative.

How about a 'Show and Tell' retrospective where every team member comes to the meeting with an action item and its explanation already prepared? The retrospective would really be each person presenting their idea in turn.

How about a retrospective wherein you challenge yourselves to come with a new approach to retrospectives that is so exciting that people would skip other work activities to attend?

The major thing is to make the changes visible and memorizable for everyone and not assuming that people remember what they decided on in the last retro.

I find it very important to revisit the outcome of the past retrospective and celebrate the things the team had been able to do differently.

Another thing is that I would invite team members to take turns in facilitating the retro. So not always the same person runs the retro (this typically also changes the format and techniques a bit).

- Heartbeat Retrospective (google for Boris Gloger)

- Temperature Reading

- Team Radar Chart

- Our project / team / product ship - draw a ship on a flip chart, ask the team what moved the ship forward, what blocked it

Just to add a totally different direction: I've made good experiences with having a *long* retrospective every few months. The short retrospectives are great to see the trees and optimize the daily work. A two or even three day retrospective helps the team to step back and watch the forrest instead.

It is important to get at least one item done every sprint. If you do the retro, but don't implement any of the actions, this is a tremendous demotivator. Better one thing finished that you can celebrate than 5 unfinished things in the queue.

Variety is the spice of life, so some variation is essential to keep the freshnees. Change the moderator, do technical focus once, then organisational, then "improving the fun factor", then go back to a general retro.

Just because anybody can have more than one item in process doesn’t mean that everybody should have more than one item in process. A problem with our multitasking rule is that it locally optimizes with no consideration of the whole. An implicit total WIP limit of 6 is still more WIP than we should probably tolerate for our three workers. A limit of 4 of 5 total items in process at one time still allows for some multitasking exceptions, but disallows the obviously dysfunctional behavior of everybody carrying two items

The ready queue contains items that are pending from the backlog, but have high priority

Here we’ve broken down in-process into two states: specify and execute. Specify is about defining whatever criteria are necessary to determine when the work item can be considered complete. Execute is about doing the work necessary to bring that work item into a state which satisfies those criteria. We have split our previous WIP limit of 5 across these two states. Specify is considered to take less time in this case, so it is given a limit of 2. Execute consumes the remaining limit of 3. We might change this ratio as time goes on and our performance changes.

Adding the specify-complete column communicates to the team that a work item which was previously in the specify state is now ready to be pulled by anyone who wants to move it to the execute state. Work that is still in the specify state is not eligible to be pulled yet. If the owner of a ticket in the specify state wants to hand it off, he can put it in the complete buffer. If he doesn’t want to hand it off, he can move it directly into the execute state as long as capacity is available.

e will also need some agreement about what results to expect at each handoff. We can do that by defining some simple work standards or standard procedures for each state. These do not have to be complicated or exhaustive. Here, they are simple bullets or checklists drawn directly on the task board.

The next event we might consider for scheduling planning activities is the concept of an order point. An order point is an inventory level that triggers a process to order new materials. As we pull items from the backlog into the process, the backlog will diminish until the number of items remaining drops below the order point. When this happens, a notice goes out to the responsible parties to organize the next planning meeting. If our current backlog is 10, our throughput is 1/day, and we set an order point at 5, then this planning will happen about once a week.

we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled

Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.

Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.

Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)

I am very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.

The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.

The remote person in this case could identify during the daily Scrum what he or she will work on and not need further interaction with the task board until selecting the next task. Here, the remote person doesn’t really interact with the task board at all and interacts only with the team. Not ideal as I’d like the person to see the tasks, but this can work in some situations.

more common is for the ScrumMaster to take on the responsibility of updating an electronic version that mirrors the physical task board

One good way of minimizing the time the ScrumMaster spends doing this is to mark the cards on the physical task board. The mark indicates “I’ve updated this task. Please update it in the online task board.” I like to use Post-It flags for this