#NoEstimates? why not?

Being an internal agile coach in a company, as opposed to being an external agile coach, means that you are required not only to know the theory and common practices of Scrum, Agile and so on, but also to know how the company decided to practically practice them. Each company might have different lingo, different view on how it should be done and different pains treated differently.

coach

That’s why, as a new agile coach in CyberArk, I need first to observe how it is done here, and try to understand also why. My boss and I discussed how we should start, and decided that instead of estimating how long would it take to observe and learn, I will simply start my first sprint by joining a couple of teams and watch closely. Once I finished my first experiment, we discussed my insights and planned the next iteration.

Recently I went to a meetup on “Planning with #NoEstimates“. I went there curious to find out if there is anything behind this hashtag, feeling quite certain that estimating is something we truly need.

noestimates

In my view, estimating is to planning just like estimations are to plans, i.e. Estimating is priceless while estimations are useless. Actually, both plans and estimations are worth something, since as opposed to “we don’t know how to estimate” and “a plan is always wrong”, I did see good estimations and I did have some plans that not only we could follow, but also helped while implementing them (usually, estimating small chunks, but looking at the bigger picture, yields good predictability from my experience). But it is clear, at least for me, that the process of estimating (same goes to planning) is very meaningful. It forces us to focus, learn, find out what we don’t know and think about alternatives. The estimations themselves, if taken as a whole, can help most times in driving good decisions.

Though most of the meetup was about estimations (and not alternatives to them), the very last slide was actually very interesting. It talked about doing experiments instead of estimating. The idea is to accept your ignorance and the fact that you don’t know how long it will take to do something you have never done before, and instead of guesstimating it, plan to learn by experimenting. The more you experiment, the more you learn, the less ignorant are you and the better you can do the job (and also estimate in larger confidence).

The funny thing is that this is exactly what I was doing as a new agile coach – doing experiments instead of trying to estimate something I didn’t do before…

experiment

Scaling Agile

It has been a long time since my last post. I know. What can I say – moving is difficult. Especially when you are moving to a new apartment that you just renovated. Even more difficult when you do it with children.

We had a Trello board for the renovation (see Renovating the apartment) but this doesn’t necessarily mean that everything would turn out as it should. There are always the unknowns, the unexpected, the things that are out of your reach, and there is always the contractor that doesn’t show up when he needs to.

Anyway, a lot has changed since my last post. Sadly :-(, I left the startup I worked in (SQream) and happily :-), I started recently working as an Agile Coach in CyberArk. The most evident meaning of this, is that it is time to scale up. If till now I dealt with 2-3 development teams, here in CyberArk there are that many in a single group, and there are several groups such as this.

Screen-Shot-2015-10-28-at-12.54.43

So how do you scale Agile? Well, there’s SAFe and there’s LeSS (is it by chance that both have a small ‘e’ amongst other capital letters?). SAFe has a very clear yet complex structure to it. Just look at the picture below. A lot of instructions on what to do, which roles to introduce and how to make it work. On the other hand, LeSS talks about less roles, trying to keep it simple and let you find out how to answer the difficult questions during the adoption.

safe
The SAFe framework. Very detailed and prescripted.

As I am new to both, I am still struggling to figure out which one makes more sense to me. LeSS sounds like my first Scrum coach, which had very few answers and usually answered my questions with more questions. Though this was frustrating at times, it made me think. SAFe sounds like my second Scrum coach, which was much more helpful with examples, best (good, for the LeSS readers) practices and answers to many of my questions. From him I learned by example. Maybe this means that the best approach is to learn, and maybe even try, both.

less
LeSS Framework – looks much simpler, yet leaves a lot unanswered

What do you think?