Category: retrospective
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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:
Bookmark/Search this post with:
Project 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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
I 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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with: