World Retro Day

It’s been quite a while since my last post. Yeah I know. It was hard to find time and energy in the last year or so. But – at least I am writing now…

Yesterday (27/02/2019) was World Retro Day and we in CyberArk decided to host a retrospective on retrospectives.

I must admit, it was actually very nice to be part of a world event, even if there was hardly any real connection between the different events all around the world. For me it was enough to see that we are “on the map”:

The (1) in the middle east is us!!!

So what did we do? We had a retrospective on doing retrospectives. We used the 5 steps of the retrospective structure, each step with a fixed time box (between 5 to 15 minutes) and we picked in advance the techniques to use in each step (e.g. one word, five whys and more). We also had pizza and bear of course 🙂

We had guests from outside the company as well as a few Scrum Masters from CyberArk, all looking to take away some new idea to make their retrospective a little better. Seems like we succeeded, looking at the list of takeaways we created:

• Present motivation for games at “set the stage”
• The retro structure is critical for getting good insights
• The problems of the Scrum Master are common, so there is hope
• Do “Set the stage”
• Use the results of “Set the stage” in the rest of the retro
• We can start with a period of basic retros (to maintain/to improve) and only afterwards add additional techniques
• When you try a new/different thing in the team, explain why and the value you want to achieve
• Define/Design “using games” as an experiment for several sprints

Finally, we took a picture:

I had a really good and interesting time, and I must admit I gained some new ideas and understanding on retrospectives. It was also a good practice to facilitate a retro with more prescribed and time boxed steps than usual. It works quite good.

The last Jedi

How exciting! This Thursday we are going to watch the latest of the Star Wars saga. I am extra excited since I am going, for the first time, to watch it “live” with my two sons. I must admit that I don’t know what to expect. Is it going to be as good as The Empire (there was a lot of things in common between A new hope and The force awakens, so one can expect that the resemblance will continue to the second movie of the trilogy…)? Is it going to be break our hearts in regards to Luke? Is it going to entertain us, or give us more to think about? I really don’t know.

Bored of your board?

 

Elephant carpaccio

Planned vs. Actual

Release board

Zoom in to the release board

Release board – backlog

Brainstorm on challenges

Feedback board

Physical vs. Digital

As an Agile Coach in CyberArk, I am exposed to many groups and teams, each trying their own version of Scrumban and Agile. One of the most common practice is of course visibility, specifically, visibility of the work in progress, a.k.a the board. Most boards are digital by now, using either LeanKit, Jira or Trello, but from time to time you get to see and use actual physical boards. Obviously, these are usually used during sessions while creating the board (and later on it is digitized) but there are boards that stay there and are even updated daily or weekly.

Though there are a lot of benefits from digital boards (I remember the time I was an organizational Scrum Master in SQream, and we used whiteboards and sticky notes, but the sticky notes weren’t of the best kind and the board was right beneath the A/C – which resulted in a daily effort to pick up the notes from the floor and try to figure out where they belonged to :-)), I must admit that whenever I find a physical one, I get immediately interested and try to figure out what I can learn from it. In fact, that’s one of the ideas behind visibility (and transparency to be exact) – letting anyone see the status and engage in what the team is trying to do. You never know what kind of help you can get from someone that passes through…

The amazing thing about physical boards, is that they enable you to try out anything you would like, very few constraints, no need to ask a favor from your Jira admin, or get help from a friend on how to configure this or that in Trello or Leankit. You just do whatever you want, and re-adjust when needed. So easy… Just yesterday, my division (more about that in a future post) had a meeting where we sat and thought about challenges we would like to take on towards 2018. We didn’t know exactly what we are going to end up with, we just knew we wanted to start off with some brainstorming, and pick it up from there. So naturally we started with sticky notes, hand them on the wall and started to cluster, re-form, measure and vote on them. The “board” changed its configuration around 10 times during a 1.5 hour talk, each time answering the specific need we were trying to get.

So – what am I trying to say here?

Basically – whenever you can, try to use physical boards. They are much more attractive (at least can be, if you have at least one team member that has an eye for aesthetics), much more agile, much more effective (no need to search for them – they are there, literally) and much more visible and transparent. Even if it doesn’t make sense to use physical boards on your day to day work (and sadly there are many reasons why digital boards should be preferred), try to find the places and times where they can give you that extra presence, extra freedom and extra engagement.

Family Kanban

Last weekend was a very long weekend in Israel, having the new hebrew year’s eve on Sunday (“Rosh Hashana”). According to tradition, we had a holiday feast to enjoy, this year hosted by us (my family).

There was quite a lot of work to be done to prepare our flat, including tiding up, organizing the table, the dishes and everything towards hosting our guests.

We also had to make sure the children (ages 10, 7 and 3.5) have something to do and do not cause anymore mess than we already had.

We knew we need to get the kids on board and that’s when we had the idea – create a real board and have them on board literally.

So, I created a small Kanban board from a white board, added three columns (TODO/לעשות, In progress/עושים and Done/גמור) and wrote a few tasks on some sticky notes.

I then introduced the idea to the kids and my wife, and asked them to look at the tasks, take ownership on them (by coloring a spot on them, each with his/her own color) and move them to the correct column.

Around 4PM, my 7 year old son already created the new ‘Also Done’ column…

 

What can I say – the kids loved it. Especially my 7 year old son, who after a short time started to create his own tasks/cards and even added a “Break/הפסקה” task so that he can take a break and watch some TV… He also changed the TODO column to Also Done/גם גמור since there was not enough place for the done cards in the original column.

Towards 6PM, not a lot of tasks left…

We all worked as a team, figuring out which tasks to do first, asking each other to add tasks that we have forgotten and even did a short daily making sure we all know what we have left.

I always new about the idea of The agile family, but never had the chance to do it with mine. Now that we did, I can fully recommend it 

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

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.

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…

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.

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.

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 Framework – looks much simpler, yet leaves a lot unanswered

What do you think?

Renovating the apartment using Trello

Hi there,

It’s been a long time since I last posted in this blog. I reckon that’s because I was too busy at work and at my second work – my wife and I started a project of renovating our new apartment, which is taking quite a lot of percentage or our (used to be) spare time.

Tamar and I discovered that even when you take an interior decorator and a contractor to design and perform the actual work, as the owners of the apartment you have so much on your hands that it seems like the project owns us and not the other way round.

As an agile practitioner, I was disturbed with the chaos we initially had and tried to find a constructive way of following the work being done, the backlog and the impediments. Soon enough I found the perfect tool for this – Trello. I knew Trello of course from work, having boards on numerous projects and flows, but didn’t quite use it at home yet.

So I started filling in the lists and items and the current board looks like this (sorry it is in hebrew):

This board reflects the status of the apartment (including the actual planned move) 4 weeks before D-Day.

In the beginning, that seemed to be enough, but lately, when the time started to be short, and every day matters, my wife and I started to have nightly sessions on the project, discussing the status and reflecting it on the board. We actually started to have “dailies” you could say, where each of us answer the three questions – what do we know was done since last time, what is planned to be done till next time, and what are the impediments. We also go through the backlog and prioritize it according to the new knowledge we have accumulated.

How will the project end? We will probably know that only in a few weeks time…

Oh, and May the 4th be with you, always (thanks Ben!)

[Reblog] It’s a Trap! Agile Lessons from Star Wars

Here is a nice blog post that links Star wars, specifically “Return of the Jedi”, and Agile or software development in general: It’s a trap

Wicket was just trying to hunt when he stumbled upon…

 

[Reblog] Say “agile” one more time

Here is a nice blog post about Agile, and how it can be wrongly misused/misunderstood: Say “agile” one more time

While reading it, I thought again about the idea of Agile being old, dead, inappropriate to the current industry. Is it really? I think it really depends on what you mean by Agile. If you mean that you must follow all the Scrum artifacts and ceremonies, no matter what, then it might be good for you, but it might also be misleading you to places you don’t want to be (like in Galina’s post). If, instead, you understand agile, and any of its frameworks, as a mindset of quick feedback loops, a way to organize your teams (as opposed to chaos) and a way to help the people focus on the correct things, then probably Agile is still good for your needs.

 

Is Agile Dead? I don’t think so… Part III

As a Bachelor degree Mathematics student, I came across the ‘Proof by contradiction‘ form of proof and immediately liked it. This is a very elegant and logical way of proofing something that otherwise might be very difficult to prove. One of the very few proofs I still remember from the good old college days is Euclides’ proof of the infinitude of primes, which is a proof by contradiction. It is so elegant, you can recreate it yourself without needing to remember almost anything, only that you need to start off by assuming there is a maximal prime number.

What does this have to do with Agile, or the death of it, you ask? Well, on my journey looking for clues of Agile’s death, I decided that maybe it would be a good idea to use the proof by contradiction method here. So, I stated the following: “Agile is dead, therefore there must be other alternatives rising and taking over the industry”. I admit I didn’t look into the possibility that Agile died and nothing is replacing it, just chaos. This doesn’t seem to be a relevant option, since Software development can work in chaos only in very small and very few companies, and all the others must find some way of managing it all.

So, if there must be alternatives, let’s find them. One interesting alternative I found was the Manifesto for Async software developement. This manifesto resembles of course the Agile Manifesto, looking at valuing ‘this’ over ‘that’, where ‘this’ are different than what the Agile manifesto values. The ideas of this manifesto are quite good and at least interesting. I don’t have much against them, if any. However, at least for me, they seem to be a spin-off of Agile that best fits some specific use case. Let’s look at their principles: Modern Tools, Meetings only as a last resort, Flexible work environments and Document everything. Modern tools – no contradiction to Agile. Meetings only as a last resort – well this does seem to be in contradiction to the ceremonies in Agile. But I believe that Agile is agile, meaning that we are flexible in doing what is right for us, while implementing it. So if it is right for us not to have dailies – then we can skip them. I truly believe dailies are very valuable, but I can’t argue they must be valuable for everyone every time. So if in certain extreme cases, the PO can be the one collaborating between everyone, and no one else will care about that, then maybe it is correct to skip these meetings as much as possible. This does not contradict Agile in my eyes. Flexible work environments – sure! Document everything? of course. I mean we should document everything worthwhile, and in the best suitable way. Right?

So my conclusion here is that although it looks like something different than Agile, the Async software manifesto is just another version of it. Maybe even a new version of an Agile workflow, like Scrum and Kanban. This of course doesn’t prove yet that Agile is not dead, I am still looking for the alternatives or successors. Once I find them, we might be able to accept that Agile is ending. If not, then I might have just proved that Agile is not dead. At least, not yet.

If you have any other alternatives for Agile you would like to recommend, please let me know!