Skip to content

Category: retrospectiveSyndicate content

How to continuously improve your presentations

February 4, 2009 by Peter Stevens

As a Scrum evangelist, I often talk to groups about Scrum. I want each talk and each course to be better than the last one. The best source for feedback is the audience, but usually audience feedback is limited to a multiple choice feedback form. You get a report card, but nothing to build on. I now collect feedback from the participants using a feedback form inspired by Scrum’s Heartbeat Retrospective. This provides useful information and enables continuous improvement as a speaker.

That Was the Year That Was

December 30, 2008 by Peter Stevens

I’ve promised myself I would actually take some vacation this week, and fortunately with small children in the house, it’s actually possible to do so! So, before the kids wake up, a blitz retrospective: High Points, Low Points and Potential for Improvement in 2009.

My First Agile Project Part 12: The Good, The Bad, and The Ugly - Our Retrospectives

November 17, 2008 by mattgrommes

Picture courtesy of cliff1066 on flickr

Welcome to Part 12 of My First Agile Project. Inspired by Peter's recent 5 minute retrospective article, this time I'll be talking about our retrospectives, which we termed our GBU or Good, Bad, and Ugly meetings. Our vendor brought these GBU meetings to us, along with the Scrum methodology, and while we weren't doing everything by the book (not a surprise if you've read any of the other parts of this series) I think they were very valuable and still light-weight and easy enough to be adapted for other teams looking for retrospectives.

Read on for more on how we ran these meetings, what we got out of them, and what we'll be doing differently in our next meetings.

No time for reflection? Try a 5 minute retrospective

November 12, 2008 by Peter Stevens

I recently started managing a new project. As such projects are by definition “challenged”, I like to start with a retrospective to find out what to focus on and earn some initial respect from the team. In this case, the team is working fervently to get a release out, which should happen in a month, so everybody is under stress and no one wants to take time off for “diversions”. A heartbeat retrospective takes 1 to 2 hours, depending on the size of the team. How do I get the team to do a retrospective under these conditions?

Ken Schwaber applied an interesting technique at his plenum session in Stockholm. At the time, I thought it was just a nice device to help conference attendees get to know one another. Ken would pose a deep, thought provoking question to the audience. Then he would ask everyone to discuss the question for 5 minutes with two or three of their neighbors. Then he would go around the audience and ask the spontaneous teams what answers they came up with.

Start with Trust, Start with a Retrospective

July 23, 2008 by Peter Stevens

Taking over responsibility for a troubled project is always a delicate situation. Something was not working as it should. There is a group of people in place, who may or may not 1) be working as a team, 2) have the necessary skills and a positive attitude, or 3) be willing to accept change. So how do you, the new project manager, get the team back on track quickly?

We all have our stories about arrogant consultants and managers who a) don't know the business, b) reorganize everything regardless of the consequences, c) quickly move on or get promoted, and d) leave the team to clean up the mess. A certain skepticism is not only to be expected, it is healthy. So the top priority is to win the support and respect of the team. A close second is getting the team working on improving the situation.

Scrum teaches a wonderful tool: the Retrospective, which is normally performed at the end of each Sprint. At the start of a project rescue, I like to use a Retrospective to get to know the team, identify short term action items, earn the trust of the team, and plant the seeds for transitioning to Scrum (while focusing on what the project needs, not on methodology).

Advertisement:

Lesson Learned: Automate Project Evaluations

May 7, 2008 by JurgenAppelo

EvaluationProject evaluations (or retrospectives) are a nuisance. Everybody knows they are important, but nobody performs them. With at least ten new projects starting every week in our company, how can I instruct our people to get all project stakeholders together (in ten different settings) and construct a "lessons learned" list of the ten projects that were delivered the week before? Nobody is available for such meetings because they are all too busy making sure the new projects are initiated properly. Sure, this is no excuse. But it is reality.

Automate the Process
To get around this problem I have decided to automate the evaluation process.

What's in your backlog?

February 20, 2008 by cspag

This morning I was looking over several of our project backlogs and noticed something that really caught my attention. In addition to user stories that addressed the functionality we are developing, our project teams have been adding stories to the backlog that have nothing to do with project tasks (or maybe they have everything to do with project tasks). The stories are about improving processes and practices, organizational issues, team matters, and even the project structure.

Retrospectives: You live, you learn

January 23, 2008 by cspag

rear_viewI recently came across a quote from one of my favorite authors, Pearl S. Buck. She said:

“One faces the future with one's past.”

Short, sweet and to the point. The quote really struck a chord with me because our development team recently learned this lesson the agile way. Last Friday, we completed the second iteration of an enterprise GIS development project and conducted a sprint review with our client. To our dismay, we seemed to have been off the mark in terms of what the client was expecting. The client seemed disappointed and our team was as well.

Product owner on retrospectives

June 4, 2007 by Artem Marchenko

Retrospectives initially were not a part of Scrum at all. There was supposed to be a retrospective part during the sprint review. Over the time it evolved into two separate sections: Sprint Review focused on what and Sprint Retrospective focused on how.

Retrospectives

November 12, 2006 by Artem

Every agile software development process by definition requires periodical retrospectives in order to pause, have a look at the current practices and improve the way of working. There are two kinds of retrospectives: major retrospectives that happen at the product release or major milestone and minor retrospectives that are carried out at the end of iteration.

Iteration retrospectives

Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.

Best of AgileSoftwareDevelopment.com