Measuring Team Emotion

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.

How David Bland helped my PMI ACP workshop

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.

Zombie Manifesto

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

PMI Agile CoP Retrospective

Agile CoP Retro

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, 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.

Community of Practice

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.

Retrospective

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.

PMI Agile CoP Quarterly Retrospective

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.

Source:  This post was originally written and published by me on the PMI Agile Community of Practice blog

TDD - Tool Driven Development

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

Coke Freestyle VMS

coke_freestyle_menu

coke_freestyle_screen

My family and I went into a California Tortilla the other night to grab a quick dinner. Off to the side I notice a long line of people waiting to fill their soda cups.  It used to be, when you went out for fast food, the people behind the counter would ask you what you wanted and they would hand it to you.  Now, at this location, it appeared it could take as long to get our drinks (in a separate line) as it would to get our food.  Though I appreciate this California Tortilla location wanting to empower the consumer by giving us 100+ choices of our favorite mixture of soda-pop, most people in line appeared paralyzed by the amount of combinations and permutations.  When I went into a different California Tortilla, I noticed an old-school fountain machine.  There was no line and I saw two people filling their soda cups at the same time.  It made me question the value the additional choices offered, especially when all I want is water.

So, I guess my question is, should there be fewer options or a better feedback tool for consumers to respond to?  When doing a little research on this post, I found a poster of a freestyle "menu" at Taco Mac.  I believe the use of this VMS (Visual Management System) could keep the lines short at the California Tortilla location.  But, I don't know.  Are there shorter (or no) lines at the Atlanta Taco Macs?  To shorten the lines at California Tortilla, I would propose they get the menus and hang a poster near the machine.  I think people would be more apt to decide what they wanted before they stand in front of this machine with 100+ choice presented to them.  I think it would cut down on people browsing the menu, while there is a line behind them.  My goal?  I want the cut down lead time and cycle time as much as possible.  Not sure what those are?  I found a great definition by Corey Ladas.

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Lead time depends on cycle time, but also depends on your willingness to keep a backlog, the customer’s patience, and the customer’s readiness for delivery.

Another way to think about it is: cycle time measures the completion rate, lead time measures the arrival rate. A producer has limited strategies to influence lead time. One is pricing (managing the arrival rate), another is managing cycle time (completing work faster/slower than the arrival rate).

I know you usually don't think of Agile or Lean when talking about fish tacos, burritos and soda-pop, but I had to get this off my chest.

Mieruka & Real World Examples

I just submitted my paper to be a speaker  at the PMI Global Congress on the topic of Visual Management Systems (VMS).  Some may know VMS as VCS (Visual Control Systems).   According to Wikipedia, Visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. In the Toyota Way, it is also known as mieruka (making visible).  I love the wild and endless variety of real world mieruka! Today I was driving through a school zone when something caught my attention.  It wasn't a police officer yelling at cars to slow down.  It wasn't a sign that said "Slow Childern at Play".  It was a speed limit sign with a radar speed sign attached to it.  On the top you see the proposed speed limit and on the bottom you see the actual.  It wasn't snapping pictures of people speeding passed.  To the contrary, all it was doing was bringing attention to actual vehicle speeds.  As I wrestled to get my speed below 25MPH, I was amazed how well it worked.

Everyone around me slowed their vehicles down, with no more coercion than knowing their speed through real-time visualization control.

Media Source: Peds.org

Agile Process Posters v2.0

I am happy to announce the collaboration with Pictofigo has resulted with a new Agile Process poster. The new process poster includes product backlogs, sprint backlogs, and user stories. We have these posters in three sizes and they come in both male and female styles.  Want to hang some original artwork in your team area, while helping people understand the standard Agile process?  Check them out!