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

https://www.flickr.com/photos/27147/3897664623/

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?

16 November 2016

There is no Leadership with no Approachability!

If you are a good leader, want to be, or think you are, you need to think about your approachability all the time. If you are good at it, you want to make it better, if you are better, you want to become number one. There is always somewhere you can push your approachability skills to become better.

https://www.flickr.com/photos/horrigans/5892256148/


The following is my cheat sheet for approachability, summarized from different sources.

2 November 2016

35: An Excellent Facilitation Technique For Big Crowds

You are going to facilitate a session. The session has a large number of people attending. You are not confident with your facilitation skills for large meetings. You are not sure how to ask them to come to an agreement on the next steps, what to work on, what, as a team, they need to focus on? If you find yourself in situations like that the 35 retrospective comes in handy.

This is how it works:
  • Distribute blank cards to everyone. 
    • I suggest to use a thick paper card and avoid using sticky notes. I also suggest the card to be colored on one side and white on the other side.
  • Come up with one thing
    • It can be idea, it can be an action item, it is mainly based on what you are looking to get out of the meeting. 
    • You would ask participants to write their idea on one side (e.g. the colored side) of the card.
    • You also need to remind them to only write one thing.
    • The writings need to be readable, this is very important.
    • Everyone should write something, or they are out of the game. This is also important.
  • Get them moving
    • This is the fun part. Now, you would ask everyone to stand up and walk with their cards in their hands.
    • You ask them to face the colored side to the floor.
    • They are going to exchange cards rapidly with other people. 
    • After a while, you would ask everyone to stop and find a partner
  • Scoring begins 
    • At this point you ask the couples to read each card and discuss it. 
    • They are going to score the cards up to 7 points. They are going to spread 7 points among two cards.
    • They can give one card 0 point and 7 points to the other one, or any other combination.
    • By the end of the discussion, they will write the points assigned to each card on the other side (e.g. the non-colored side) of the card.
  • Repeat 5 times
    • You would ask the participants to do this 4 more times, exchange their cards, find a partner and score.
  • Calculation of the points. 
    • After the 5th round, everyone needs to add up the points on the back (e.g. non-colored side) of the card and write it down. 
  • And the winner is ....
    • There is no winner per say1
    • You would ask who has a card with 35 points? If there weren't any you ask for 34 points? If there weren't any you would ask for 33? And so on. 
    • The cards with the highest points are the cumulative agreement of priorities based on the people participating. 
35 used in a retrospective

Update: I have found a post on gamestorming defining this exercise from Dave Gray.


1 The winner is of course you, if you insisting of finding the anwer. You managed to facilitate a session with full of energy, good discussions, and an outcome.

27 October 2016

My Thoughts on SAFe and Leading it safely!

I had the opportunity to learn more about SAFe by attending a Leading SAFe course. To be honest, I didn't have a positive overview of SAFe and its implementation (despite the fact that I had a blog post about it some times ago). After learning more about SAFe, my perspective has changed and I want to share with you what I have learned, what helped changed my perspective and what I think is great in SAFe.

First of all SAFe is safe. This is by design. It is a great comfort for the leaders to hear it. The first thing they are hearing is SAFe when talking about transforming the organization. Don't underestimate that! How many times have you seen or heard stories of the leaders buying into the Agile or Lean transformation ended up being confused about what they got into? They found themselves confused about what they bought into and then finally decide to abandon the transformation ship. Change is not easy and whatever you do to make them feel safe is well received, even by just calling it SAFe.

Second, SAFe is not confusing leaders with Agile / Lean mumbo jumbo at first sight. I am very sad to say that, but it is the way interpreted by the leaders. When you are talking about Agile Manifesto, you need to connect the dots for them, you need to tell them for example why less documentation help their organization deliver better value for their customers. On the other side, SAFe is talking their language. They came up with their own principles, 9 of them. And the first one is "take an economic view". Don't you agree, as a leader of an organization, you would relate to "take an economic view" more than "Individuals and interactions over processes and tools"?

If you look at SAFe as a start state, in which you introduce awareness for an organization transformation, it is an awesome approach. If you look at SAFe as an end goal, it might seem too immature. This is my perception and comparison of SAFe and LeSS.

SAFe -> Cloudy -> Sunshine
LeSS -> Sunshine

What did I like about specific SAFe practices? I am glad you asked. These are some techniques that I really liked and I am going to use them in my (and other's) daily life.

Decentralized Decision Making

SAFe is providing you with a really nice mechanism to make decisions easy to be made. It helps you to determine which decisions to delegate and which ones to keep it at the leadership (or your own) level. You can read more about DDM here. It basically makes you think on Frequency, Urgency, and Economic at Scale. Then it will ask you to rank for each category from 0 to 2. If the sum of any decision is higher than 4, you decentralize the decision. 

Y=2, N=0

ROAMing (Risk Analysis)

At the end of Iteration Planning, Release Train Engineer (RTE) gathers all the risks defined for all the teams. He/She then ask the people in the IP to categorize it in 4 categories. It is a forum to talk about the whole program and its risk with the bigger audience. 

ROAMing

Weighted Shortest Job First

I really liked the idea have used it before in a different format. I used it as Business Value over Job Size (or estimations / story points). However, in SAFe it is suggested to use all the following category for weighing a job:
  • User-Business Value
  • Time Criticality
  • Risk Reduction
  • Job Size
WSJF = User-Business Value + Time Criticality + Risk Reduction / Job Size

SAFe is suggesting to have at least a 1 in each category among all of your features. I am not sure if I like that. This means that the user business value has a similar scale to a job size. I like a weighted approach to that. Something like: (You can decide the parameters based on a discussion with leaders)

WWSJF =  (.40)User-Business Value + (.30)Time Criticality + (.40)Risk Reduction / Job Size

You can read more about this feature in SAFe here.

Definition of Done

SAFe explicitly defines Definition of Done on 4 levels, Team, System, Solution and Release. By doing that, you are explicitly saying that a team is not responsible for an end to end delivery of value and the whole organization is. Again, if you look at as an introduction to transformation and your goal is to move from four levels of definitions of done to one level and only at the team level, it is a very great idea. Otherwise, it is a terrible idea to have four definitions of done.

*In LeSS you have Definition of Undone. And you are trying to make it fade away and include everything in Definition of Done.

Value Stream

The introduction of Value Steams was a great idea. I am not sure if it was well thought of. It seemed to me as another layer, which is basically called Value Stream. It felt like more of a portfolio of portfolios to me rather than Value Streams. I am predicting that in next version of SAFe, we will see major changes in Value Stream.

Set Based Design

I looked at this as a way to have emergent architecture capability in SAFe, which I am all about. I am not sure how the implementation will go. It looked to me more of a Lean Startup approach formalized. I am not sure if that's a good idea.

Program Board

I really liked this visualization. It is basically after the PI planning session, all the features to be developed are mapped on a board. Then dependencies are mapped between then using strings. In the program time-frame, whenever there is a change, you can simply see what it is affecting, a great visual tool!

courtesy of https://mobile.twitter.com/michael_p_stump/status/721007389298663424/photo/1
An example of Program Board
Cadence has to do with predictability! I just liked this.

Thanks to Bertieg for making it happen in Canada, and kudos to Jerry Doucett for delivering content with a great attitude. You know you are challenged when your head is hurting from learning valuable materials and finally making you think in a different way. Jerry's delivery, the least it did, helped me to change my view on SAFe and scaling agile.

11 October 2016

Agile Coach Retreat 2016 - Fall Edition

It happened on a Saturday morning at 8:30, in Financial district of Toronto on the first day of October. It was nice to see new faces and the old mates. It was a rejuvenation of the old habits and learning new techniques on coaching. At the core, as always, it lived the same great spirit of community, to help each other and to grow together. I can't imagine that I grow this much since the time I attended the first Agile Coach Retreat. I am astonished how many new faces showed up.

Early Morning - Ready for Agile Coach Retreat
The format of this coach retreat was different, the organizers (one of them being me) learned from the past. In the morning, a session has been held by Don Gray talking about container based analysis. It was a very powerful approach looking at a topic from different angles, the relationships between them, their correlations, and most importantly how you can use it to pinpoint the main problem for the person you are coaching and helping them realize it.

Don Gray - Teaching From Back of The Room
In the above picture, you can see Don Gray introducing the technique and helping with different groups on their approach (This is the presentation from Don Gray). We have dispersed three times into smaller teams to create the model, discuss the differences and come up with the relations in it.

Discussion Panel

Discussion at the same time
In the two pictures above, you can see people are discussing in pairs or triads on the problem space and trying to come up with a container-based model and have a better understanding of the situation.

6 October 2016

Writing Better User Stories!

Writing a user story is easy. However, a great user story is hard to come by. It is an art to have one! Introducing the values and specifications of a great user story to teams and individuals, I put together a session called "Better User Stories". I am sharing the presentation I used. I divided the techniques and skills into three sections, "Better User Stories", "Much Better User Stories" and "Much Much Better User Stories". I hope you find it helpful either for yourself or for the people you are working with.



If you ask me to describe a user story I would summarize it as "Is about locking a shared understanding of smallest deliverable value possible"

Also, note that this is the start of the conversation for writing better user stories. Similar to user stories, which are for the understanding and embracing collaboration around value creation.

It's all about the conversation!


Did you know that user story is a term in XP and Scrum calls it Product Backlog Item or PBI for short?

3 October 2016

What is your Agile journey? Where does it take you? This is mine, kind of!

I began learning about Agile when I was a developer. I was looking to find better ways of collaboration with the business and my team members. There was a point in time that I figured out I can't deliver great code on my own; I need to help others to do great things from coding to analysis and so forth. I tried some ideas, some worked, few didn't. Later on, I got introduced to Scrum framework. Scrum seemed easy and straightforward at the beginning. The more I read about and got myself into, I figured out it is deliberate to be silent about many issues. The rationale is that if you stick to the values of Scrum, you can figure out what to do in a situation by situation basis (it can be very hard though).

I then started helping teams to adopt Scrum and then at the organisation level. The more I got myself into these kinds of challenges, I noticed that I need to educate myself more and become more knowledgeable; so that I can more efficiently help other people. I have attended several pieces of training listed as Certified Scrum Master, Kanban, ICAgile Certified Professional, Coaching Agile Teams, Certified Disciplined Agilist, ICAgile Facilitation For Agile Teams, Certified LeSS practitioner & Lean Change Agent. I have also been to many community events such as coach retreats, coach camps, agile meetups and so on. On the side, I was reading many books and maintain a blog to share my learning with the community as well. Still, I am learning and try to implement unique techniques and skills to specific challenges. (You can take a look here for a list of books/blogs/articles/activities I enjoyed and favourited.)

I have helped one Telecommunication company to embrace Scrum. I helped their leaders to shift their mindset from faster delivery to a more effective and frequent delivery standpoint. On another engagement, I am helping a big financial institution with their Agile initiatives. I have helped several teams to adopt the Scrum framework. The adoption was helpful in surfacing up the fundamental issues that they have in order for the teams to be more effective. Thus leading to initiatives on how to effectively change the organization.


Although I have touch points with different concepts of Agile here and there before Scrum. I feel that Scrum was the official starting point of my Agile journey. It won't be the last point of my journey for sue, but I have the feeling that within this journey constantly I am going to refer back to Scrum and learn more and more about it.

28 September 2016

LeSS of an Introduction, More of an Implementation!

I was so touched by the LeSS framework that I had to implement it. The perfect opportunity presented itself, a big team (or shall I say a group of teams) that were working toward the same product.

I'm sharing with you a presentation I prepared to move a team from a ScrumFall into more of a LeSS framework. Prior to this presentation, you could think that many conversations took place, many questions got asked and many thoughts put into it.

It is not easy to work with LeSS, as similar to Scrum, it leaves many of the questions unanswered deliberately to leave it to you.



The link to the presentation can be found here.

If you like to read more about starting point of my journey with LeSS, you can find it here. You can also find my profile on LeSS website here.

12 September 2016

A Great Coach is a Lazy, Curious & an Often One - Notes on Michael Bungay Stanier's Talk

I had the pleasure to meet one of the greatest coaches in the world, Michael Bungay Stanier. As the second greatest coach in the world, as per introduction & here, he used some spectacular techniques in facilitating the session with at least 200 people. I am sharing some of them here with you.

First of all, you wouldn't find any presentation for his talk. There were only 6 or 7 titles written on a chart paper.

At the beginning of the sessions, he asked everyone to stand up and greet another person that they don't know. Then he asked us to answer this question talking: "What cross roads are you at?". At the end of the 5 minutes, he asked us to repeat our names once again. We have repeated this exercise after a while with a different person and question: "Talk about your high points in the last week", on your foot!


Then he asked us to give a number from 1 to 7 for the following questions (7 being the highest). We didn't share the answers but just to have an idea of where we are standing. The questions were as follow:
  • How much engaged and active you are going to be in this session?
  • How much risk are you taking with me (Michael)?
  • How much effort are you going to put in to know other people?
This helped me to align my thoughts with my goals in the session. It will be a great tool to use in the start of a meeting / session you are facilitating. 

Then he talked about the bad, good and great work, based on his book. He used the following questions to engage the audience in checking the process: "Let me do a quick check, doesn't anyone know what I am talking about?". 

One of the definitions of the great work that I really liked was "more impact, more meaning". You can start your conversation with just this and then get into details of how a great work might look like. 

Some of the cool learnings from the session are the followings: 
  • Advice Monster: This is the reverse of Active Listening 
  • Advice Giving Maniacs: You can tell what that is, this isn't something a good coach would do.
  • The first thing that shows up is not the real challenge most of the time.
  • The first answer they are giving is usually not the best answer. 
  • Coaching is to be lazy, curious and often!
  • Nothing is more scary if there is there is only one option you got
  • The person with the longest hair / longest feet / more hair / more colorful goes first
Great Resources:
  • You can listen to Michael talking about the last statement here.
  • A great article in Globe and Mail summarizing the "coaching habit" from Michael.
  • The session by Michael (embedded below)

2 September 2016

What and Why You Ask Is Very Important!

I was shouting "do not give out the solution"! The worst part was that I shouted right at the beginning of the meeting. I felt like I was derailing the meeting even before it even started and I wasn't very happy about it. Before getting into what happened consequently to make me do this, let me tell you the whole story.

In a meeting that I was part of, the facilitator was asking participants to make a fan. It wasn't a norm for people to make fans while in meetings at an IT firm1. Most people looked confused, they were just looking at each other and no single sign of creating fans was on the horizon. At that moment, one of the participants took the initiative and started to guide the others on how to make a fan. Let's call him Strive. Strive was telling people in detail what they need to do; That they are going to pick their favorite color paper, any color that they want, fold the papers, glue them together and then glue a piece of stick to them; and the result would be a fan.

Don't we all like being told what to do? And in detail? This was when I felt the urge to say something. I raised my voice to stop Strive on providing one of the possible solutions. Then I brought out my cell phone and loudly said to myself: “I don’t know how to make a fan… but I am going to search how to make one.” This was followed by one of the participants asking if they are allowed to use their phones. The answer was yes. The crowd then became busy, everyone with his/her own style of coming up with a fan. Fifteen minutes later, everyone made a fan. I think it’s important to mention that not even two of them were the same. One person used staples instead of glue to make fans2. Another one didn't fold the papers at all. One person decorated her fan with drawings, another one used a prototype on a plain paper to test his skills and the outcome before committing to creating the fan.

The followings are some of the fans created by the individuals.


Let's think what would have happened if Strive continued leading the participants on. People in the room probably would have followed his instructions or most of them at least. I predict that most of the fans would have looked similar to each other as a result of following same steps. What about taking ownership and being proud of what you’ve created? Would you think that they could have been proud of what they have built? Proud of the thought and craftsmanship they put in? Would you ponder if there is any pride following the instructions blindly?

29 August 2016

How To Coach The Uncoachable?

Have you ever encountered situations in which you've been asked to coach people whom are not coachable? What would you do in those situations? What are the options that you might have? There are not too many options.

Courtesy of https://www.flickr.com/photos/crdot/7827384514/


There are these actions you might take into consideration:

  • Just Give up, ignore the un-coachable. This is the simplest thing you can do. However, there are two ways of doing it:
    • To not tell the coachee
      • This is an option if you don't find your interaction and the outcome of that coaching exercise valuable at all. You will find that even having this conversation is a waste and no outcome will be realized. I highly suggest to avoid this option.
    • To have a conversation with the coachee 
      • This could simply opens up the coaching conversation. It might help you with the situation and awarness for the coachee. Your client then might be more open to be talked to and receive feedaback. You can leverage the conversation you are having and build on top of that. Hopefully in some days later you can have the coaching arc conversation with him/her.
  • Talk to him/her
    • To have a chat with him/her and let him/her know about the coaching arc. It will open up the conversation about where you are standing and what both of you need from each other. You might come to a conclusion other than a coaching agreement. You might end up with teaching opportunities or a mentoring one.
  • Talk to his/her boss
    • If you've been asked to have a coaching conversation with a person, there must have been a reason for that. If it hadn't come from him/herself, it should have been come from someone higher than him/her. You can use that opportunity to further investigate the situation. May be it is not the coachee that you need to coach, may be it is the boss, or may be it is both of them. 
  • Find out Why
    • Find out why you have been asked to coach the coachee. Then you have to figure out if that is the valid concern for the coachee and have a conversation with him/her or his/her boss. Then, you truly can unlease your coaching potential. 
  • Be Influential
    • You can influence the coachee by understanding him/her and coming up with innovatve ways of influencing that person. There are lots you can do here, you can show geniue interest in what the person is doing. You can give him/her some tips and see if it gets caught by him/her. 

18 July 2016

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

https://www.flickr.com/photos/ibrotha/2373453050


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 June 2016

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 June 2016

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 May 2016

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 May 2016

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 that 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 to begin with.


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

29 April 2016

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 April 2016

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

23 March 2016

Postcard Retrospective - Travel Through The Last Sprint!

During one of the retrospectives, I asked the team to write a postcard to one of our ex-team members. Amer left the team to pursue new endeavours in Montreal. I thought this would be a great opportunity to write him back and send him some postcards. Having that in mind, I asked him to write the team in the first place. I presented his letter to the team and asked them to write back. I didn't specify the context on which to write back to him. Whoever needed clarification on what to write back, I suggested talking about what have changed from the time he left and what they are missing about him. You can see the presentation I put together for the team below, I called it Travel Sprint.



This is all the postcards the team wrote back to Amer.



What was good about this type of retrospective?
This would be a good exercise for the setting the stage and gathering info section of the retrospective. Great conversations can be started based on what the team members are writing on the cards. You just need to direct the conversation into generating action items.

This exercise will also unintentionally bring up the concept of "not being a resource" in each team member's mind. We are talking about a specific person with specific characteristics. You can expect different personal aspects to be talked about.

This exercise will give you a good understanding of how different your team members are. You can put all the postcards on a table and ask them what do they see. Also, it helps them with understanding each other's different perspectives.

As you can see through the rest of the slides, I ran the expectations exercise and the four Qs building on top of the postcard exercise. Finally closed the retrospective with the dot voting on action items.

PS: Please be more pro-active running this exercise. Try to use coloured markers and some stickies to make it more fun. I didn't have time to grab all those and just did it with plain papers and sharpies, hence the quality :-(.

4 March 2016

Notes from Agile Facilitation Tools & Techniques Course

These are the notes from the facilitation workshop / course held by Sue Johnson.

My Aphorism

You need to show the same audacity for not facilitating a session having no or negative value, as opposing a team's decision contradicting Agile values.

Great Facilitation Skills

  • Having made them write it down => great facilitation skill for helping with the introverts  
  • Put someone on the spot, a big NO NO
  • Bring it to the team, they are there with their best interest
  • Good to do process check in intervals in the meetings
  • Secondary Facilitator
    • Originally from Group Gold Mining book
    • I want to use it as an opportunity to coach a person to become a good facilitator
  • If it is about your job, you don't want to facilitate that meeting, an example of what not to facilitate
    • Even the meeting is not a good option
  • Facilitator needs to make sure it is not becoming a slugfest
  • Do we get instructions to become a parent / husband / wife? On how to become a good communicator / facilitator
  • Get the participants in group first, before introducing the group activity
  • Give them what and let them find the how, on how to facilitate neutrally
  • Facilitator is more about facilitating than being a facilitator
  • Will you be tempted to influence the team? And can you be a team member? To ask a manager before attending a team meeting
  • Facilitating a group is much harder v.s. a team. You need more time to prepare, as they don't know each other to the extent of team members. 
  • Use of Empathy Map 
Empathy Map (Source)
  • If people are flooded with emotion, you can't work with them (and facilitate the session), you need to take a break
  • You need to understand that an angry woman most probably will cry at work. It is not appropriate to be angry at work for women. 

Good to Remember Questions

  • What's your gut feeling, are we missing any of those? (Referring to your feeling in an indirect way)
  • Do You want to say more about this?
  • I want to hear from the people I didn't hear
  • Stand right by a person, works both for quiet people and talkative people
  • How do you know? A god way to asking if it is really the case
  • Ask for an example, good one or BS
  • Is that true or is that your opinion (stronger word to use: story)?

Conflict

  • Everyone is right but only partially (our own version of truth)
  • Distinction between Interest & Position
  • Go back to facts, we need to walk those people down the ladder when resolving issues
  • UNMET NEEDS => Reason behind having conflict, look for what's missing 
  • You Are Always Right! From each person's perspective they are right, try to use that a lot and believe in it sincerely. Look from their perspective. 
  • Conflict around ideas not people
  • You can improve on Negotiation Training
  • Conflict, alternatives to:
    • Disagreement
    • What wants to happen?
    • Emerging things

Spiral of Doom
Who it is going to be won
Fantasy
As we start to files attached, we start to move to world of fiction
Fiction
Fact going through our believes
Faction
There are facts supporting that conflict
Fact
¢
¤
¢
¤
¢
¤
¢
¤
¢
¤
¢
¤
Fact
Fact
Faction
Fiction
Faction
Fiction
Fiction
Faction
Fiction
Faction
Fiction
Fact

Powerful

We are powerful people, we thrive on:
  • Powerful Observation
  • Powerful Question
  • Powerful Request

Open Space

  • Open space is for complex problems that there is no simple answer to it. 
  • A theme is good to have for an Open Space

Individual interaction

Individual exercise -> group exercise
(time to reflection, talk before think)
introvert -> extrovert
small group -> big group

Haiku for Team Dynamics

Work togetherish
Live happy with conflictish
Grow with each otherish

Miscellaneous

5 to 1 ratio for positive to negative feedback ratio
Radical Candor
Deep Democracy

Arc of Facilitation (Very similar to 5 Retrospective stages)
Learnings Summarized at the end of the session