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.