Retrospective ingredients continued...

Kaizen vs Retrospectives

In Kanban, Scrum retrospectives have been replaced with Kaizen meetings (kaizen in Japanese means “continuous improvement”). The difference is subtle but powerful. We have Kaizen meetings every two weeks; engineers and product owners discuss how the process should be modified to improve velocity and quality, while reducing overhead. Instead of looking back and critiquing what we did, all the energy is forward-looking and focused on process improvement. Defensiveness down, collaboration up!  

Everything in the process is fair game and any new idea is treated as an experiment to be tested. Most ideas are given a try, and very few are shot down. As a result, kaizen meetings have an upbeat, creative feel and the process runs very smoothly.

The risk and rewards of Kanban

Kanban isn’t perfect
We’ve successfully moved to Kanban and are really happy with it, but it’s by no means a perfect solution.

The Software Tools For Kanban Are Nascent
We use and love Atlassian Jira and Greenhopper. They have some nice Kanban features, but their Kanban board is relatively new and lacks the planning coordination we so hugely desire.

Loss Of A Systematic Focus On Urgency
With Scrum, that sprint clock ticks loudly. Everyone feels the pressure to get their work done before the sprint ends. Urgency is baked in. In Kanban, urgency is more abstract and doesn’t have quite the same emotion pressure. We’ve had to impose a sense of urgency in our team through culture and management—harder but hopefully healthier.

Keep Calm and Kanban
Kanban’s power comes from its focus on getting fewer items out faster through work in progress limits. Like anything, it’s not perfect and it may not be right for everyone in every situation but ultimately, we ended up with a happy team, higher productivity, less tension between the business and engineering, higher quality software, and A LOT less overhead. Win!

7 Habits of Bad Bosses

1. Poor communication skills
2. Bad judgment
3. Inability to lead teams
4. Problems in relationships
5. Poor conflict resolutions skills
6. Inability to manage themselves
7. Inability to learn from their mistakes

6 Baseline questions regarding scrum

Click Here to the main article

1. What’s your elevator pitch for Scrum and agile software development techniques?
1. Help people build software in 30 days or less.
2. When you were initially coming up with these concepts, did you ever envision that the methods would become as pervasive as they have?
1. We, (Jeff Sutherland and Ken Schwaber) came up with it for our own survival, and then we experimented with it in a number of companies that we were in. I would have never guessed. But I view Waterfall as the worst thing that ever happened to our profession, ever. So I’m delighted that it happened.
3. Why was Waterfall the worst thing that ever happened to the profession?
1. It starts with the expectation that you can take complex technology, people, and changing requirements, and you can predict exactly what they’ll be a far point in advance, and you put someone in charge of it that tries to maintain and stick to that plan. 
4. Are Agile and Scrum techniques equally applicable to other areas of business, and life?
1. David Starr runs his family using daily Scrums and weekly planning meetings (PDF). A sales operation is run by Scrum. They lay out the yearly goal, and then every month they lay out what they’re going to try to do, they look and see what they were able to accomplish, they adjust the business accordingly, then they move forward. The only thing that wasn’t done with an emperical, iterative or incremental approach was software! Which is the most complex of them all. It’s so weird.
5. What’s the biggest mistake that a company makes, or a software development team makes, in trying to implement these principles?
1. We’re trained in our organizations to believe that there’s someone in charge, who has people working for him, and he can tell people to do things and it will happen.
2. Companies think that people’s creativity can be mandated.
3. The hardest thing is to get the manager to see that his or her job is to see, what is the best the team can do, and help them do it, rather than get them to do what the manager thinks they should do. Anyone who’s been a parent knows exactly this problem with their kids.
6. How do you balance the need to collaborate with the need to concentrate?
1. People think opening up space and letting the noise vibrate is collaboration. Having people so you can see them, and go over and start writing on a board, or you can get the people you need right there, that is collaboration. There’s often a mistake that this ominous noise is collaboration. Visual cues and access are the keys.

Agile Consulting

I thought this was a great advertisement for consulting services.  

Franklin Theater

Franklin Theater

Ingredients for a successful Retrospective

Over the years I have had the opportunity to conduct many Retrospectives and lessons learned sessions.  Admittedly, some have went extremely well.... and others were lacking the original zest or spirit of the ceremony.  At times the meetings were perceived as punishment rather than opportunities to improve.  None-the-less we as a group pushed forward, looking for topics to highlight and possibly squeeze out some beacon of light to reassure us we were doing the right thing.

I have made a point to express my gratitude for the concept of Retrospectives.  The ceremony itself should not be taken for granted.  I have worked at several other companies where the primary focus rested soled on the term productivity.  Although I am not diminishing the the importance of velocity within the workplace, I am excited to see a company invest in itself and its employees by setting aside time for everyone to look at ways to improve.  It is for this reason, I have taken this event so personally.  If someone was going to invest time in me and my work, then I want going to take advantage of it.

Throughout this journey I have since discovered monotony and retro fatigue is a universal problem.  Many coaches struggle with finding creative ways to keep their teams engaged and the retrospective successful.  I have found a few universal themes that should be considered to combat a disastrous event.

• Time box the event.  Preferably 60 minutes max.  However if you do not need the entire time call an end to the meeting.
• Have an agenda advertised.  Issues do not magically appear the day of a Retrospective.  Make the retro agenda a dynamic list everyone can engage at any time. Sometimes there are surprises, though often the subject has at least some notion of where things are not going great.  This will help stimulate collaboration and remove selective amnesia on the day of the retro.
• Turn the computers off.  Removing distractions from the meeting will assist in keeping everyone focused on the discussion.  I am a strong advocate of collaboration.  There are several proven techniques to encourage collaboration and ensure even the most introverted disposition has a voice.
• Solicit feedback regarding the coaches performance.  Recently I had the opportunity to participate in my own Personal Retrospective to evaluate current performance as an Agile Project Manager and Coach.  It was humbling to hear coworkers who I respect greatly speak both positively and critically of my role.  In the end though, I was appreciative of the feedback as it worked to quiet the distracting internal voice of insecurity and help me focus on the team members perspective. Additionally, it helped me understand where I have been dropping the ball, along with recommendations on how to get on the right track.