Too many times, companies focus too much attention on metrics like Team Performance and Team Efficiency, while ignoring metrics like Team Emotion or Happiness. This last week, I worked with a company and team which did not make this mistake. At the conclusion of the iteration, they held a retrospective.
As noted on a previous blog post,
a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator, a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event. The meeting is time-boxed to help ensure it doesn’t just turn into an out-of-control complaining session. When properly facilitated, you come out of the meeting with an actionable list for improvement candidates.
At the conclusion of the team retrospective, it was time for the final task of the (2-week) iteration. It was time to know how the team felt.
As you can see from this Cacoo drawing, the team was happy during iteration planning and the first week of the two-week iteration. Things didn’t go so well during the second week or the Iteration Review. I was there during that meeting and not surprised they voted as they did. What is telling from this diagram was their feelings of the actual Retrospective meeting. They were very happy.
During the Retrospective, the team discussed how they could make the next iteration (and Review) better. It was a really healthy and productive conversation. There was no blaming. It was all about “how can we as a team do better?”
In closing, find out how your team feels. You may be surprised how team performance and efficiency improve when the team is happier. If you want true process or team improvement (Kaizen), track your feelings as well.
Popularity: 2%
After each PMI Agile Certified Practitioner (ACP) workshop that I offer, I refine the format to make it better. I learn some new content from the ACP Support team at the PMI Agile Community of Practice and some I learn directly from the students in my class. Originally, my key objective for the class was to provide an introduction to Agile; strictly positioning the class as a knowledge-based learning workshop. The 3-day workshop was a learning experience filled with lecture, group discussions, hands on exercises, and videos. Based on feedback through formal course evaluations and talking with the students, I actually added performance-based learning as an additional key objective. (ie. getting a passing score on a certification exam versus just learning new approaches to deliver value to customers).
It’s been an interesting progression. The name of the workshop started as “Agile Fundamentals: PMI-ACP Prep”. The feedback from the classes was there was not enough exam prep. I didn’t want to create a PMI-ACP Bootcamp but I did want to help my students. I changed the name to PMI Agile Certified Practitioner Workshop and then scattered relevant questions throughout the 3-day course. I also added an ACP Practice exam so people could get a real idea of what the test is like. The last thing I did was give each person attending my class a free Premium account with my tool AgileFlashcards.com.
The results from my latest class were very positive with comments like I liked the fact that this course provided great learning about Agile practices, fundementals and not ONLY ACP prep. Great amount of balance.
I give David Bland some of the credit for getting my class where it is today. I used his Course Canvas to visualize my course and make it better. I’m sure you could use this visual tool to improve all kinds of things. Just remember that you don’t need to reinvent the wheel to make improvements. You just need to find the right tool for the job. I found such a tool, with the Course Canvas.
Popularity: 1%
Who would have thought that a year after publishing Zombie Project Management that I would be asked to brief a Federal Agency (which is not to be named at this time) on the topic. As part of my briefing, I will be including the Zombie Manifesto. Nobody has said I have lost my sense of humor. Then again, nobody has told me I have ever had a sense of humor. I look forward to writing a blog post next week after the briefing. ”Briefing” makes me talking for over an hour sound so official!
Become a Signatory!
Leave a comment below
Popularity: 1%
When you think of spending a Saturday afternoon among friends and colleagues, do you picture yourself sitting in front of your computer, collaborating for three hours on a web-based tool and discussing what is working and what could work better? Well, that is exactly what a group of us did. It was time for the quarterly PMI Agile Community of Practice (CoP) retrospective. We couldn’t all be in the same physical location so some of us from the community jumped online and tried to make the world (or at least our CoP) a better place. 
When you look at the graphic above (or click on the link to Cacoo), you may be left scratching your head, if you are neither an Agilist nor a member of the PMI Agile CoP. If you are either, I hope you nod in recognizing the mechanism we used to interact and make our Agile Community of Practice a better place for us all to belong.
You could describe us as a motley crew of discontents and zealots. You could also describe us as a passionate group of Agilists drawn together, with the hope of helping the PMI community discover the value of Agile practices and approaches. We all hold a sense of belonging to our community. We all believe in the altruistic sharing of knowledge, methods, stories, cases, tools, and documents.
Generically speaking, a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator (in this case Brian Bozzuto), a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event. The meeting is time-boxed to help ensure it doesn’t just turn into an out-of-control complaining session. When properly facilitated, you come out of the meeting with an actionable list for improvement. Though I always recommend doing retrospectives in person, actually having the retrospective takes priority. Do it wherever you can however you can. Successful teams need to take the time to have retrospectives if they have any chance of improving what they do.
The leadership of this community recognizes that as our community grows, some things will work and some challenges will need to be overcome (zoom into the graphic to see what we thought). One thing is for certain: with almost 14,000 members, our PMI community has a lot to offer both members and non-members. Every minute of that Saturday afternoon was well spent. I hope this post and the link to the Cacoo graphic provides some transparency into what we’ve been doing the last three months.
Interested in joining our community or becoming a volunteer? We’d love to have you!
Source: This post was originally written and published by me on the PMI Agile Community of Practice blog
Popularity: 1%
In order to realize the greatest benefits in application development, it is recommended that you use good engineering practices. Those practices include continuous integration, paired programming and TDD (Test Driven Development). Unfortunately, when arriving at a new coaching engagement, it is common that a tool vendor has arrived on the scene before the Agile (engineering and process) coaches. Just as many are sold on Agile being a silver bullet, I find people are equally sold on the idea that a tool can solve all of their problems.
Are clients wrong to assume an enterprise “Agile” tool can transition them away from a “Waterfall” tool? I’m sure that is what the tool vendor told them. Though I would agree some of the leading providers do offer more lightweight solutions, the truth is some people (after the sale) get frustrated when they realize their tools need to be customized, to align with their business processes. Unfortunately, I have seen that customization not happen. Instead, customers struggle with the tools they have implemented. They change their development and delivery process so they can use the tools. They start to practice TDD (Tool Driven Development).
When I show customers they can accomplish what they need with index cards, painters tape, and Sharpies, the next question is how can they modify the tool to align with reality.
Always remember the first value of the Manifesto: Individuals and interactions over process and tools. Fix your processes first. Then, and only then, should you look to a tool for efficiencies.
Image Source: Pictofigo
Popularity: 1%
Free PMI-ACP Exam