In this course, Agilisto Luke Angel outlines the tools needed to successfully run a great retrospective. Including the five phases: setting the right direction, getting all of the issues on the table, gathering insights from the team, making decisions, and finally, applying the changes. He will make you starfish and then PANCAKE, Yup their as funny as they sound buy hey they work, diagrams to identify challenges and opportunities for process improvement, and show how to close a retrospective with clear action items.
An agile retrospective allows a team to continuously improve and get better together. This simple practice lets members step back from the day-to-day challenges with product delivery. Instead they focus on the team. "What are we doing well? What can we do better?" The answers to these questions help the team create a more agile mindset. They will be self-organized and more productive. Instead of a postmortem at the end of the project, they will have health checks throughout the project.
Watch and learn agile project management techniques to assess your project today, and get back on track for tomorrow.
THIS COURSE IS CURRENTLY IN ALPHA - ILL BE UPDATING IT OVER THE NEXT WEEK. PLEASE SEND ME DIRECT MESSAGES IF YOU FIND ANY FLAWS WITH THE COURSE! IF YOU LOVE IT PLEASE RATE IT. IT MAKES ME EXTRA HAPPY AND MOVE FASTER GETTING THE REST OF THE COURSE UP.
Retrospectives have been around since the beginning. After running the agile manifesto, the alliance listed out several core principles. These principles clarified the shorter agile values. One of the principles says that at regular intervals the team should reflect on how to become more effective, then adjust their behavior. So the team should reflect, tune and adjust. In many ways, the retrospective is about the team being agile with their own improvement. They use the same ideas to turn their efforts inward to reflect on how they can be a better team.Typically, the team will meet for 2 hours on the last day of every sprint.
A retrospective meeting is not an informal gathering. It should be well run, very structured. That's why many teams have a dedicated facilitator. A facilitator is usually someone outside the team. It may be an agile coach or someone who specializes in retrospectives.
Retrospectives depend on many set up details. This is true more than any other Agile event. There's a lot of details that really matter. It matters who attends. It's also important who's not attending. It's important who facilitates your retrospective. It's also extremely important where you have your retrospective. The facilitators should work hard to make sure that everyone feels safe and engaged.
Retrospectives depend on many set up details. This is true more than any other Agile event. There's a lot of details that really matter. It matters who attends. It's also important who's not attending. It's important who facilitates your retrospective.
Sometimes, a retrospective's misused. Some teams just use the session as a way to vent their frustrations. Other teams just use it as a small get together. They focus on their accomplishments and only bring up a few items that could be improved. After a while, the team starts to lose sight of the intended purpose. That's why some organizations have independent facilitators. Their job is to come in and run the retrospective. They help the team get the most out of the time. Sometimes they're consultants.
Even very agile organizations can't fight the allure of a distributed team. Less expensive overseas labor markets are an easy way to cut costs. Also, many organizations like the ability to reach out and hire global experts. Either way, there's a good chance that your agile team will have at least one offshore developer.
Like many Agile practices, a good retrospective depends on a self-organized team. The team needs to accept responsibility for their improvement. That's why Norm Kerth created a short retrospective mission that he called the Prime Directive. The Prime Directive should be taken very seriously. Don't think of it like the original Star Trek's Prime Directive. The team shouldn't discard this directive whenever it may cause problems. Instead the Prime Directive is a pledge. It's a shared understanding about how to work together. Some facilitators even suggest reading out the directive at the beginning of each retro.
It's a little strange to see a team do this.
Every so often, something will happen which captures everyone's attention. Maybe it will be a big legal decision, an election, or a natural disaster. Afterwards you'll see experts talking on television. People will write articles. People at work will tell their own version of the story. When this happens, you might notice that it seems like no one person can tell the whole story. People only have their piece of the picture. They'll have their perspective of what happened.
A starfish is one type of chart you can use for your retrospective. The diagram shows the team how they can improve. The starfish has five equal sections. Each of these sections is a category. The categories are Keep doing, Less of, More of, Stop doing, and Start doing. The dividing lines look like a starfish. To use the starfish, each person identifies an item they'd like to discuss. One team member might like the way the team holds their standups. In the retrospective, they would create a note called "Having Efficient Daily Standups".
They'd put that activity in the Keep doing section of the starfish.
The starfish diagram is great for open-ended retrospectives. It's a simple chart, and it works well for many teams. It has the benefit of being broad but not too directed. It doesn't limit the team's agenda. Still, there are times when the team needs a little bit more guidance. This is especially true for newer teams. For these teams, it might be better to have a PANCAKE Retrospective. Unfortunately, this retrospective doesn't include a short stack of buttery, fluffy goodness.
Some organizations don't like the idea of playing retro games. It seems unprofessional. It's different from the traditional corporate image. It's important to show that retrospectives are about creative reflection. It's about coming up with ideas to improve the process.
Even during a retrospective, teams don't usually spend their time asking the right questions. It makes sense. Most Agile teams are filled with developers and managers. These professionals have spent most of their careers providing answers. They're not usually hired to be inquisitive. If they ask questions, they may even look less qualified. If you search one of the job listing sites, you'll see how most organizations hire teams. Search for words such as expert, solution and experience, then search for words such as curious, inquisitive or learn.
The second search will give you much fewer results. The first search would probably include most of the listings. What this suggests is that teams are not rewarded for being good at questioning. The problem is, without good questions it's very difficult to find real process improvement.
One of the goals in a retrospective is to find ways to improve the process. The starfished almost always has items the team wants to do less of, start doing, or stop doing. Yet identifying the challenge is only the first step. The team still needs to find action items so they can figure out how to make the process better. Fortunately, agile uses some of the same tools as lean manufacturing. Remember, that lean software development is still considered under the agile umbrella. That means that many of the items in the lean tool kit also work for agile.One of the oldest is the 5 Whys Technique. The 5 Whys Technique is used to find the root cause of a process failure.
Thanks for looking at my courses. I am excited to bring you some awesome lessons I have learned along the way. I also love to talk about my favorite products that really help me stay ahead of the curve. I am an Architect, Developer, Product/Project Manger, and humble hustler focusing on building next generation application.
I am currently working as a Sr. Technical Cross Platform Program Manager at a Fortune 500 company building technology-driven marketing solutions with global reach and Netflix scale. I lead teams of developers to new heights by giving top of the line guidance on product deliverables, organizational techniques, and in general kicking butt. I hope you find my courses enjoyable and please contact me if you have any questions or would like any additional content covered that is not in one of the courses.
I am a PMP expert and PRINCE2 consultant.