18.7.16

How to improve feedback culture in a team / an organization ? - A Thank You (Hot Seat) Retrospective

What always puzzled me was how to improve on a feedback culture within a team. Once, I had a pleasure to run a 360 feedback retrospective for a team. It was a bad decision to call it 360 feedback, please don't do that. However, the result was very dramatic. It was a huge culture change in the people and how they interact. It was an easy meeting to run, the rules are simple.

One person is being criticized by the whole team, one person at a time and the only thing he can reply back is "Thank You".

Everyone will go through this criticism circle. You might need to time bound it to 5 minutes for everyone if you have limited time.

You need to make it clear that the criticizers need to provide a positive feedback and a negative feedback following that. They are not allowed only to provide positive or negative feedback.

This is a sample presentation that you can use for a team. I found it easier for people to follow the instructions while talking to many people.



Thank You Retrospective Presentation

What do you need to run this meeting?

  • You want to make sure that people in the meeting, or the majority of them, are feeling safe to provide feedback.
  • You want to make sure that they are trusting each other's opinion; otherwise, it will be a waste of time.
What do you need to do after this meeting?
  • You want to follow up with them to see if they have talked about the feedback with the people they trust. Leave it up to them to share with you if they want to act upon it or not.
What is the next step?
  • If you want to make it to the next step (which I suggest you to do), you want the feedback to be spontaneous. You don't want people to wait for a meeting to show their affections, thoughts and feelings. 
  • You may have a feedback circle at a random time, when you are having your stand-ups, just out of nowhere at the middle of the day (please just don't have it over food).
  • What I strongly suggest is to use the Kudo Box from management 3.0. You can read more about it in Jurgen's new book , management for happiness. You can get the cards and the basic idea from his website.


Do you want to improve the feedback culture in an organization? You can build upon this exercise but with teams giving each other feedback. Do not allow one person from one team to provide feedback to another team.

30.6.16

Quick thoughts on Metrics from Gojko Adzic & I

As an aside, please don’t use activity metrics such as velocity or burn-down scope to measure progress. They only show that people have been busy, not that they were working on the right things or even producing something valuable. Activity metrics are great to measure whether the team is working well together or not, but they can’t show real progress. Measuring progress with activity creates a completely wrong set of incentives for prioritisation. Instead, create a model for expected business value delivery and report progress towards it. 

It is a very well said about metrics. I would add to it if a team wants to measure velocity and use it as a diagnostics to improve and grow, let them do that. However, you want to make sure that this metric is only used by the team; and to share it if and only if the team decides to be shared with externals.

21.6.16

Agile Coach Camp West 2016 @ Vancouver's BCIT

This year I decided to take part in Agile Coach Camp Canada West edition (as well as East). It was a unique experience. The format as always was an open space format. It began on Friday, June 17th and ended on Sunday, June 19th.



In this Agile Coach Camp, I talked on two Topics and co-hosted on one topic. The first topic that I picked was about "Leading the team you inherit" based on an article I recently read from HBR. The outcome of the discussion was very interesting. We, collectively, were not agreeing on the hypothesis in the HBR article that the Tuckman model can not be used with the team you inherit. As an outcome, I volunteered myself to contact the author and ask about the assumptions.



The second topic that we talked about, thanks to Simon for proposing it (and asking me to co-talk it with him), was about bloody metrics. It was a fun talk to see different people's ideas and where they are coming from. Cleverly, Simon picked the title of Metrics Damn Metrics.




Part of the first day, there were several topics on scaling agile and many discussions regarding that. After going to LeSS with Craig Larman, I have felt obligated that I need to talk more about scaling and what needs to be truly discussed. So, on the second day, I have talked about "The correct questions to ask is "How to de-scale organizational complexity?"." It was a very interesting topic and very interesting discussion. I basically asked the question of how to descale the complexity of an organization, and we got into many topics of local optimization, system thinking, metrics and even politics. The followings are the notes from the talk:




Some points I would like to mention:
  • I felt that the organizers could have done a better job of organizing food, lunch and dinner and even facilitate better activities. Although, I should thank them for their time and their dedication to making this happen.
  • The crowd demographics was more toward Agile enthusiasts rather than Agile Coaches. I leave it up to you to decide if this was a good thing or a bad thing. 
  • I have got to known 5 people coming all the way from Toronto for Agile Coach Camp West in Vancouver, such an enthusiastic crowd from Toronto.
  • I have learned a lot after talking to so many people and taking part in so many discussions. That's what it all mattered and I am very glad to be part of it. I am hoping to see these kinds of events happening more often on the west coast. 

18.5.16

The Core Protocols Cheat Sheet

I have gathered a very simple cheat sheet for core protocols and when you can use them. You can find them here and embedded below.

5.5.16

Test Driven Development by Example

After taking LeSS course with Craig Larman, my mindset toward coaching teams has changed. I inspired to include coding practices alongside my liftoffs. That's how I started to do a lunch & learn with some teams and introducing them on TDD. The problem I picked was exactly the problem that Craig picked, prime factorization table. It was a very well thought of problem and the way the algorithm will evolve is very intuitive and mind-blowing at the same time. At each step, you are only worried about the test you want to pass and that's it, the algorithm evolves by itself; of course, driven by tests.

I tried to capture the steps in a powerpoint, to show how we the algorithm of finding prime factorization was evolved from one line to the full algorithm.



What I tend to do in the coding session is to ask for help, to see if there is anyone that wants to help me with coding or even thinking and getting it going. In the last one I ran, one person got up and sat on my laptop and did the rest of the coding. I then told them this is how a pair programming would look like, at least this is how you can try it to begin with.

I found out that Uncle Bob had a very similar approach called it PrimeFactorKata.

29.4.16

Notes on LeSS with Craig Larman

I was very lucky for Craig Larman to be my fellow traveler in my Agile journey in April 2016, although for a very short period of time. I had the honor of taking part in LeSS practitioner course offered by him. I immensely enjoyed learning from one of the Agile Gurus, not only about LeSS but more importantly about Agile. I have heard stories leading up to the Agile Manifesto meeting at 2001, philosophies behind defining Scrum and why things have been named the way there are now. My mind has officially been blown. It completely reignited me to learn more and try new things while not forgetting the principles. Notes below is the ones I took at the course. It was the first time that it has been offered in Canada, thanks to Bertieg.

This is the big picture of LeSS. There are lots of details in the picture. You need to pay attention to all the details. For example, there is one scrum master that is helping with two teams and there is a team with a dedicated scrum master.


And this is my first attempt at describing LeSS to one of my colleagues.


1.4.16

Characteristics of a Great Scrum Master

Finding a great Scrum Master is not trivial at all. Anyone can take a course for two days, take the test and become a Certified Scrum Master. However, you are not mastered in anything. Your journey has just begun. Through my experience looking for great Scrum Masters, I came up with the following list of characteristics. This list summarizes what I am looking in a person for a great scrum master. It is important not to forget that a Scrum Master needs the knowledge of basics of Scrum, before even being considered a good one. 


I also have assigned points to each characteristic. By looking at those, you can have a better understanding of which quality has a higher weight in determining a great scrum master. 
  • Innovative / Creative Solutioner
    • A great scrum master is someone who is innovative, someone that can come up with creative solutions on the fly  depending on the situation. Someone that can understands complex situations or if he/she doesn’t understand the situation, to find out ways of understanding the situation.
  • Good Communicator / Facilitation guru
    • A Scrum Master is needed to be able to communicate his messages to the team flawlessly. He needs to be felt part of the team when communicating to the team. He needs to be more direct in communicating the message with the leaders. He need to be direct if communicating with people helping removing impediments.
  •  Team player (Lead by example)
    • Leading the team needs someone that is a good team player and know the rules of the game. You can’t be a great mentor for the team if you haven’t played in the field yourself (even if you failed while playing).
  • A good Agile Tour guide / Knowledgeable about Agile values and Principles
    • A good scrum master needs to lead people into the Agile world. Leading people needs prior knowledge of where we are getting them and how we are getting them to. What challenges might be in different paths and how to overcome it.
  • Be prepared for the unexpected (fearless)
    • In an Agile team unexpected(s) are expected. A good Agile guide needs to be prepared for those. You need to have tools in your toolbox to deal with those. 
  • Be a good psychologist  
    • As someone leading the team, the scrum master needs to be a person that listens well. The listener needs not only to hear but also observe and feel the team’s feeling. He needs to have an empathy muscle. 
  • Be comfortable making people uncomfortable
    • Scrum master is the agent of change. He/She needs to be able to sell changes inside the organization. Doing so, the scrum master needs to have people skills to make people uncomfortable.
  • Be patient
    • A good scrum master understands that change does not come fast. You can introduce a new concept or a process to people and don’t see the effect right away. A great scrum master has follow-up plans. 
  • Continuously improving
    • A great team is a team that always looking for improvements and growing all the time. Leading a team  with such great qualities, you need to live and breath that quality by yourself. 

  • Personality Qualities (A Qualities) (+45)
    • Innovative / Creative Solutioner (+13)
    • Great Communicator / Facilitation guru (+12)
    • Be a good psychologist (+5)
    • Be comfortable making people uncomfortable (+10)
    • Be patient (+5)
  • Professional Qualities (B Qualities) (+25)
    • A good Agile Tour guide / Knowledgeable about Agile values and Principles (+15)
    • Be prepared for the unexpected (fearless) (+10)
  • Personality & Professional (A + B Qualities) (20)
    • Team player (Lead by example) (+12)
    • Continuously improving (+8)

90 total