19 January 2017

The Art of Asking for Feedback - How to Avoid Feedback Failure Modes?

I was asking for feedback. It is a habit of mine. Maybe I am doing it too much. I learned much from feedback that I can not live without it! It was for a session I taught and facilitated. I asked for feedback in different ways.


The outcome was very interesting. Some of the feedback I received was useful, some were not at all. What has happened there? What could I have done differently? Why did I receive productive feedback in one situation and not in the other one? I was open to receive feedback, I was asking for feedback and eager to hear. I have called this situation "Feedback Failure Modes". Let's together explore them.

Feedback Failure Modes

There are many failure modes when asking for feedback. I categorized them into five.

Figure 1 - Feedback Failure Modes

18 January 2017

My Learnings from a Session I Taught, Myself (XP, Feedback + Notes)

I facilitated a session to simulate planning, development, feedback and iteration in an Agile fashion. I used a simulation called XP Game. This game originated based on the concepts introduced in eXtreme Programming book by Kent Beck. It provides a visual and interactive way to understand the values of XP, and to a wider extent Agile.

I am not going to elaborate on how I did run the session and what I learned. It is a very lengthy process to talk about. I want to talk about my observation facilitating the session.

I am very eager to receive feedbacks from the audience at the end of my sessions. Every time I am running a session, I am asking for feedback. I learned and improved myself a lot based on them. I strongly suggest you give it a try.

Let me give you a little background. I ran the XP Game session as a substitute for another facilitator that usually runs them. Let's call him Chocolate King, as he loves chocolate a lot. Some of the participants in my session had taken part in the same session ran by Chocolate King earlier.

At the end of the session, I asked everyone to rate the session they've been part of from 1 to 5, with 5 the highest and write a comment if they want. The session got an average of 4.5 out of 5. There is still room for improvement. I would consider this as a session that provided value for the attendees.

Feedback Wall

6 January 2017

A More Effective Decision-Making Framework: Cynefin, A Domain Driven One!

Let me introduce you to the Cynefin framework. If you are having a hard time pronouncing it, you are not alone. It is Welsh and is pronounced as /kun-ev-in/. It is a decision-making framework. Cynefin helps you to make better decisions based on the domain you are in.

Cynefin Decision Making Framework

Let me start by talking about four major categories, one minor common area and one dangerous edge in Cynefin framework. The Cynefin framework categorizes domains into Simple, Complicated, Complex, Chaotic and Disorder ones.

Figure 1 - Cynefin Framework

19 December 2016

My Notes on Cynefin Framework

These are my notes on Cynefin Framework. It is a very powerful framework. You can use it for any causal relationship modelling, decision making being one of them.

14 December 2016

Leading Conversation at AgileOntario about Standardization in Agile

I spoke at the Agile Ontario Meetup on December 10th for the December meetup. I have been attending to this meetup for a long time. This time was different, I was speaking at it. The topic that I was talking about was standardization of practices and processes amongst the teams and how will or will not help the team. It was an honour to be a speaker at that meeting. When I look back, I am feeling that the Agile Community in Toronto inspired me, guided me and helped me florish. This is a community that you feel like a family when you are part of, and you want to be part of it. It truly felt like a family to me. I even spent one of my birthdays with them, two years ago. And the day that I was speaking at was a very special day for me, both good excuses to spend with good friends.

My birthday, celebrated with my Agile family two years ago
My birthday surprise at the end of AgileOntario Two years ago
Special day, spent half a day with my Agile family

As you might imagine, this is a very wide open topic to talk about. It was a very interesting conversation, obviously, I'm biased, as Fernando and I were the conversation leaders. It was a very engaging one and the fact that heard everyone talk was something that I rely my observation upon.

We started by prescribing the audience a Standard protocol for this meeting. We told them that we have hired many advisors and coaches to help us with finding how we can be more efficient. The only way that we could find was to standardize the meeting.

That was obviously an ice breaker, we continued by asking the participants on what they have in mind when it comes to standardization. If they have any examples or thoughts in their mind to talk about. I am summarizing some important conversation starter points below based on the two hour conversation and some of my thoughts based on the research that I did.

24 November 2016

My notes on Toronto Agile Conference 2016

Toronto Agile Conference 2016 has happened in November. It was a great selection of Agilists and Agile enthusiasts. It was jam packed with great stuff to learn. I have attended three sessions about leadership, project management in Spotify and Leadership again and one keynote about the Host Leadership. The followings are my notes from the conference. You can also find others & my tweets on that day with TOAgile2016 hashtag.

23 November 2016

The Legend of HOW!

One of the practices of Agile Teams, that you might have heard of and is very popular, is writing "user stories". A very important part of the User Story is the absence of the HOW. A good user story is one with no HOW.

For the Business Analysts (BAs) audience, user stories will resemble Business Requirement Document (BRD). I usually get that talking to BAs about user stories. A good point to bring up comparing the user stories to BRDs is that there is no HOW in both of them. 
Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on what is required, rather than on how to achieve it, which is usually delegated to a Systems Requirements Specification or Document (SRS or SRD) or other variation such as a Functional Specification Document. 
Agile has 4 values and 12 principles. If you look at the history of software development, you will find that these values and principles are not something out of ordinary for its time. These are basically a collection of better practices put together, which is well thought through. Nevertheless, there might be new slogans and names used for them (and for a reason). 


My advice is not to simply forget the practices in place all at once and try to learn from scratch. Ask yourself, why there was a process existed and if it is important to continue having that or not. Agile is about knowing what and why to do to get to the goal more effectively. Ask yourself, why there is no HOW in BRD before questioning why there is no HOW in user stories. What would be the reason(s) that we leave the HOW for other people to figure it out?