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?

Can TOC and Agile work together? Sure they can! (part 4)

In the past few weeks I published three posts in regards to the question whether one can implement both Agile and TOC together. In this post I would like to summarize this topic, at least for now (I am looking to try a couple of things in my new position as Organizational Scrum Master, and I will update on that once I have results).


In Part 1 we saw that while Agile was inspired by Lean, TOC is a competitor of Lean. Even so, both are concentrating on the mindset. Both are ways of thinking how to improve, how to create an environment of ongoing improvement, and both suggest different tools and techniques in order to do that. So, even if some of the tools may collide, the rest can be utilized together.

In Part 2 I gave a real life example of using the TOC mindset, specifically focusing on the bottleneck and subordinating to it – the 5 focusing steps, while doing Agile. The fact that Agile gave us a clear notion of where is the bottleneck, and TOC prepared us regarding what to do with the bottleneck, and what to expect once we successfully overcome it, is a great example of how both work well together.

In Part 3 I gave a real life example of using techniques from TOC’s critical chain, specifically the use of explicit buffers (instead of having them implicitly within the task estimations) within a sprint of Scrum. Though we lack the tools for it, this was a good experience in combining two tools into one.

The question how TOC and Agile relate to each other is a question that is out there for quite some time now. For example, back in 2011, Yuval Yeret wrote his thoughts on how Kanban and TOC relate. Yuval summarizes by saying:

I believe there is potential for a lot of synergy between Kanban and CC, especially in the world of complex programs/portfolios.


In Tom Sedge’s article on Demystifying change, he concludes :

I hope you can see that none of these approach is a “silver bullet” and they each have strengths and weaknesses. Equally, I hope you’re already seeing how many of their aspects and tools are complementary and can be used together.

In Shirly Ronen-Harel’s roojoom on Theory of constraints and what has Agile got to do with it there are a lot of other links about the synergy that can come when implementing both.


In summary, I believe there is no real question. TOC and Agile can and should work together. None of them are a silver bullet, none of them demand exclusiveness. It is just a matter of thinking straight, focusing on what’s important and trying to utilize smart tools and techniques, doesn’t matter where they came from.

Agile – through the eyes of the one and only Obi Wan Kenobi

While trying to prepare to my interview in FasterAndMoreIntense, I was thinking about what to answer if a question about my favorite Star Wars character would be raised. The thing is that my favorite character was Han Solo for quite a long time. Before the prequels, if you had to choose between Han Solo, which didn’t take himself too seriously, or Luke Skywalker, which of course is a Jedi, but let’s be honest – not the most inspiring one, I think the choice is simple – Han Solo. Not to mention that the character is played by one of my favorite actors ever, Harrison Ford…


But, how could I represent a blog talking about Agile and the Force, connecting between Jedi Masters and Scrum Masters, if I choose a non Jedi as my favorite character? So it’s a good thing that the prequels came out. Like others, I was disappointed with The Phantom Menace. It was way beyond my expectations, which were very high to tell the truth. But in one area I wasn’t disappointed. That was in the matter of Jedi craftsmanship and lightsaber combats. At last we could see Jedi’s as they should be – quick, powerful, able to fight many rivals etc… That’s when I started to like the character of Obi Wan Kenobi. First of all – I already was a fan of Ewan McGregor. Second – he sliced that Sith in half – that was amazing. Third – Obi Wan is the first Jedi we see, in the original trilogy and also in the prequels – that must mean something… But most of all – he was someone we could trust. Someone we knew will survive and will be faithful to the Force. Someone we can cling to.


So, thinking about it, and then realizing that it is not by accident that I am using Obi Wan’s pictures as avatars for myself, I became aware that my new favorite character is Obi Wan Kenobi. (This could change, once Star Wars 7 is out, and Han Solo becomes an old friend that comes back, but we shall see).


I have already shared here a few links to articles focusing on Yoda’s wisdom and how it relates to Agile. There is no dispute that Yoda’s character is the best for that. But since I chose Obi Wan, I feel I need to show some words of wisdom from him too. For that, I looked around for Obi Wan’s best quotes, and took upon myself to select a few that, in my mind, can help the young Agile padawan. So let’s go for it:

Only a Sith Lord deals in absolutes

This is a very nice reminder that we should always look at ways to break the dilemma between two seemingly contrasting sides, not by looking at one as just and the other as wrong, but by looking at what they have in common, and finding a way to secure both needs (and not necessarily what they want). This is similar to TOC’s Evaporating cloud, and is very important for an Agile practitioner, remembering that there is no absolute right or wrong, there is always a need that needs to be addressed.


Many of the truths we cling to depend greatly on our own point of view

Almost the same notion – our point of view usually is not the only one, and it may affect the way we understand things. Trying to look at it from different angles, will let us bypass this bias and be able to solve problems that otherwise will be very hard. In Agile this is very true – you always need to consider the way things look at from Product, Marketing, Business Development and not only from R&D’s point of view.

Who’s the more foolish, the fool? Or the fool who follows him?

This is for everyone – if you feel like you are being led by a fool, do something about it, since it is on you if you continue this way. For Agile – I think this is saying that if you are not satisfied with what we are achieving, step up! Don’t let it slip.

Can TOC and Agile work together? (part 3)

About 4 years ago, while I was already working as an “Agile project leader”, working with two Scrum teams, helping out the Product Owners and Scrum Masters in their routine, I was asked to form a new Scrum team that would take upon itself a challenging task of finding a way to make the performance of one of our services to be much better. This was needed in a hurry, since a new customer has just signed a deal, with the extra fast performance as one of its prerequisites.

Since the team was ad-hoc and was assigned to this project for a couple of months only, I decided it was a good opportunity to do some experiments within the team with some TOC ideas, mainly from TOC’s Critical Chain Project Management (CCPM). (Having the Scrum Master as one of my subordinates, and a friend, was helpful to convince that we can experiment a bit, though the project was highly prioritized).


My idea was to take the idea of buffer management as it is done in CCPM and use it within the sprint’s planning and during the sprint itself. To be precise, I started by explaining the idea to the team. I explained that tasks are more likely to take more time than less time due to Parkinson’s law, Student syndrome, or other reasons, and that usually, when one estimates a task to be 2 days, one will either finish the task after 2 days, or more. parkinsons-law1We all recognized that there are tasks that finish early, and that part of our estimation is a small buffer so that the estimator will not need to explain to the team why the task is taking longer than estimated. I then introduced to them the idea of buffer management, where each one will estimate the “best scenario” duration of the task, and will add an additional “buffer” duration for that task. We then took all these buffers, and put them as Resource buffers, Feeding buffers and Project buffers and planned the sprint accordingly.


During the sprint execution, we were able to concentrate during the dailies and status meetings on the buffers, making sure that they are not exhausted before the end of the sprint. Once a buffer was almost maxed out, we could understand that there is a potential problem here, and the team tried to figure out how to overcome it.


All-in-all it was a very nice experiment. The team felt it had potential, though it lacked the software behind it (we used sticky notes and did everything manually, so that the buffer management was a bit of an additional overhead the team had to spend effort on). Since the team was temporary, and once we finished (successfully) our task, the team members were moved to other projects, we did not continue with this idea. If I have the chance again, I would like to experiment with that again, maybe this time also looking for some software that can deal with the buffers.

Can TOC and Agile work together? (part 2)

In part 1 of this series of posts, I have looked at the origins of both Agile and TOC, and established that both talk about mindset and ways of solving problems, and not necessarily about specific, maybe contradicting, actions that need to be taken.

In this part, I will share with you an experience I had while being an agile project leader and thinking the TOC way. I think this is a nice example of how TOC and Agile can work together.

As an agile project leader, I was helping 3 scrum teams to work on their projects. I was mentoring the Scrum Masters, the Product Owners (sometimes acting as one myself) and the relevant team leaders. One of them was the QA team leader, and she was bringing to my attention that usually, when a project starts, there is not a lot to do QA wise, but always, when the project is about to finish, the amount of work left for QA is much more than they can handle. Not that I didn’t notice this before, but it came to be very apparent and visual once we started using Scrum and agile techniques.


TOC was not something that was officially considered where I worked, nor did we even discuss it, but it is always with me, ever since I participated in the Jonah program in 1997. So when the TL approached me, concerned about this problem, it immediately struck me that QA is our Herbie. The last milestone of almost every task is its testing, and there is always not enough testers to do the work right at the end, though they are almost idle right in the beginning. This is our current constraint/bottleneck!

A businessman trapped inside a bottle trying to crawl out through the neck with his partner pulling on the cork from the outside

So we started to come up with ideas on how to exploit this constraint, again without really mentioning the TOC steps or anything similar. First we looked at all the tasks that the QA team members are doing and started to find tasks that can either be postponed to post-release (which is best, considering they are usually less busy at this point of time), or can be done by someone else. This was a start. We then came up with the idea to plan the project in such a way that the testers can either start testing right from the start, or can participate in some other tasks in the early stages of the project, that originally were done by coders. This changed a bit our prioritization of the project’s User Stories, but all in all we saw that the throughput of the team has increased.

A project or two later, it became obvious that QA was no longer our bottleneck, which was a very good sign that we exploited it well, but we now had to deal with a much more complicated problem. Knowing TOC, I knew this is coming and was prepared to shift my attention to other areas, which now needed help. More on this in a future post.

So, to summarize, while working in Scrum, and thinking TOC, we were able to find our constraint and exploit it so that the throughput – the amount of work that the team was able to do in a time period – was getting higher noticeably. Agility and Scrum gave us the visibility and the collaboration of the whole team to solve the “QA” problem, and though probably we could have come up with the same solution without using TOC, for me it was very clear that the 5 steps and the notion of finding the bottleneck and exploiting it was the thing that helped me to increase our velocity in this case.


Can TOC and Agile work together? (part 1)

A little background, before we dive into my answers on this question: (oh, and by the way, for all you Star Wars fans, this post (and the other parts to follow) are not Star Wars related in any way. Sorry).


When I first came to know TOC, back in 1997, its applications were primarily around production lines,  floor manufacturing, distributions, even sales, but very little around project management and software development. Actually, in 1997 Goldratt’s Critical Chain was published and the project management application started to take off. You could argue that Software development had started around year 2000 when Necessary but not sufficient was published. Anyway, back then, using TOC for software development was not very common.

Back then, Agile was not invented yet.

Thinking about it, both TOC and Agile were developed while inspired by Lean. TOC was invented while working on the Drum-Buffer-Rope solution for manufacturing (which later on became the TOC application for operations) which was a competitor of the Just In Time manufacturing principle of Lean. drumAgile was invented as the Lean way to develop software. So it will not be wrong to say that while Agile is very similar to Lean, TOC is a competitor of Lean, and not a follower. This is why my question in the title is relevant – it might seem that Agile and TOC are two different ways of managing a software project, thus will probably not work together.

This is of course not the way I see it. I will try to explain my view on how Agile and TOC can and should work together in a few posts. I am also planning on doing some live experiments (already did one a few years ago) and will post here how they went.

So let’s start with a very simple explanation why there shouldn’t be any problem in applying both TOC and Agile. The reason is that TOC in general, if you put aside the different applications it already has, is mainly about helping you to think straight and come up with ideas to solve your problems. These are the thinking tools of a Jonah, these are the 5 focusing steps to exploit a constraint. FIG-toc-5fsAgile is also a mindset, with different frameworks, but still a mindset of how software development can get better. At least in my view, neither TOC, nor Agile, claim to be the only correct way to solve your problem. Instead, they both try to help you, giving you some tools, some ways to focus, some directions to look at. In that sense, as long as you are not a fanatic about neither of them, it is obvious that the more tools you have, the more options you have, the likelihood is that you will be able to solve your problem and do better. Once by discovering your current constraint, the other time by making your team much more collaborative. It may even be the same solution to the same problem.

Theoretically, I believe we established that there should not be any problem doing both. In the next parts of this idea, I will get into the more tactical options of using TOC and Agile together.

As always, if you have any comments, or disagree with anything – please let me know.

Return of the Jonah

Back in 1997 I finished my army duty (serving 4 years instead of 3, since I became an officer) and I had a little over six months till I started University. Most of the discharged soldiers like me go off to a few months of hiking in South America or in the far east. I flew to the US to learn the Theory of Constraints. I took part of a TOC Academy, where a few students from all around the world spent around 5 months to learn TOC and become instructors of TOC. (TOC talks about looking for the bottleneck, the weakest link, and exploiting/eliminating this constraint).

The first part of the course was a Jonah course in which we discovered the thinking processes suggested by Eliyahu M. Goldratt. Once we finished this course, we were certified Jonahs!

As a Jonah, you master the thinking processes and are able to help others put their intuition into developing a solution to their problem. You probably know where I am going to – the comparison to a Jedi was straightforward.


It’s true that the Jedi’s powers are much greater, after all, a Jedi can talk people into changing their minds and be blind of their presence. But then I thought that a Jonah can also talk people into changing their minds – the only difference is that the Jonah does it for the interest of the person he is talking with, and not his own. So actually, a Jonah is almost like a Jedi with no self interest. (Maybe if Jedis were more like Jonahs, the Emperor would have left them alone :-))

This was 18 years ago; before the prequel; before Jar Jar Binks.


I came back to Israel, started my studies in the University, and discovered the joy of coding and software and have been involved in software since then. TOC was never part of my career, but it is always part of my way of thinking, and I am waiting for the chance to bring some of its insights into what I do. TOC is also one of the ancestors of Agile, and at least in my view, part of the Force.

Continue reading “Return of the Jonah”