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 be number one. There is always somewhere you can push your approachability skills to be more.

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.

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



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.