Is Agile dead? I don’t think so! part I

A friend and an ex co-worker of mine sent me a few days ago a post on the death of Agile – The end of Agile. Since then I did some research on the subject, and indeed there are quite a few who claim that Agile is either obsolete, abused or simply doesn’t work and fit the current industry. I will try to write in a series of posts my view on the subject, referring to other blogs and articles. In this post I will try to explain why I think the  post above is somewhat missing the point.


Hayim Makabee, the author of “The end of Agile” claims there are a few myths that Agile consultants believe in, which underestimate the complexity of software development. His list includes statements like

“Good design will emerge from the implementation of user stories”, “It will always be possible to pay the technical debt in the future” and “Constant refactoring is an effective way to produce code”.

I wouldn’t say that any of these are accurate phrases of Agile thinking. First of all, I would claim that “A good design will help the implementation of user stories” and not the other way around. Whenever we need to implement a complex feature, my experience shows that taking the time to design it is a necessaty to have good results. Usually the design yields the idea of how to divide the implementation into steps or user stories, which in turn can be executed in a sprint.

As to always being able to pay the technical debt – I must admit I never heard this phrase before. Technical debt is just one way of relaxing the scope of a feature so that you can implement it in small bites and iterations. Nobody I worked with ever claimed you can always pay the debt in the future, nor was glad to add more debt. In certain circumstances, there is no choice but to avoid a few known issues, some of them technical, and put them aside for future implementation. This is not an easy decision, nor is it one that you are glad to do, but it is something that reality forces you to always consider. Just recently, in SQream Technologies, we faced a problem of either adding additional technical debt to the backlog and finishing the work on time, or doing the work “right” and delivering it late. This was no easy decision, but both R&D and Business decided to go with the former, because of the need to finish on time. You could even argue that it wouldn’t matter if we were using Agile or not, the situation and decision would be the same (the need to deliver on time is not coming from a sprint or any other Agile concept, but from the business needs), however I would think that if we were not using Agile, R&D would probably decide to work “right” and eventually, in some future day, Business would learn that this is the case and that there is nothing to do but to delay the time to market. Having the ability to decide on this together, by putting R&D and Business together in one team, is one of Agile’s biggest advantages.

As to constant refactoring – again I would argue that in all my career, I never heard someone say that it is one of the most effective ways of coding. Refactoring is sometimes needed. It may be needed because of bugs. It may be needed because of changes in the technical aspects, or business aspects, that were not foreseen and it may be needed because we were in a rush. I agree that the Agile mindset does allow refactoring as another tool to cope with the timeline and the time to market, but this is just another tool in your toolbox to choose from. Having more tools is better than having less, as long as you know when and how to use them.

Hayim finishes his articles, stating the following:

In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse, component-based software development. Only when we are able to incorporate these basic principles in our development process we will reach a true state of Agility, embracing change effectively.

This is where I think Hayim, and others, are getting it wrong. In my understanding, Agile never said to stop designing, stop using patterns or reuse code. It just says to use them in the appropriate place, at the appropriate time, and in iterations where possible. In my opinion, we were always able to incorporate them in our development process. This doesn’t mean we are doing it the best way possible, there is always how to improve, but we never said to stop doing them just because we are in a Scrum team. Agile makes you think more about what to do and how to do it, giving you more tools to use but seldom requires you to let go of a tool or process.

It is true that Agile can fit very well when working on very simple software projects. It is also true that almost everything would work in such simple projects. Saying Agile doesn’t fit in complex projects is, in my eyes, misunderstanding the true meaning of Agile. But let’s save that for another post in this series.

[Reblog] Learn Agile Marketing SEO from Star Wars Stormtroopers

Here is an interesting presentation, in the form of a video, about agile marketing.

Jonathon Colman, who wrote this presentation, chose Stormtroopers and Star Wars in general, as a metaphor for his ideas and as the concept of the pictures being used within the presentation.


Putting the internet to work for me

A few weeks ago I wrote a post about my new Fitbit and the way its measurements affect the way I behave. One of its features is measuring my sleep time, which is very neat. Finally I can monitor how much I sleep, and how good I sleep (or sadly, how bad, see below… 😦 ). The thing is that I need to remember to open the Fitbit App and take a look. Well, thanks for my good old friend IFTTT, I now simply get an email if I sleep less than six hours at night, which gives me a bit of a push to try and meet my threshold.


My actual sleep last week… What happened on Thursday? :-~

So what’s IFTTT? Simply put, If This Then That. If something happens, do something. Back in ClickSoftware, when we worked on a similar idea, we called it the Butler. The idea is that you want something to happen when some other thing happens, and if some software can do that for you, that’s much better then doing it yourself. For example, let’s say I want to let my brother know that I left some nice new video on our shared folder in Dropbox. I can email him whenever I do that, but isn’t it much cooler that it is done automatically by IFTTT? Another example – let’s say that each time I post a status update on Facebook, I want it to be twitted (or vice versa). IFTTT can do that for you.


I have been using IFTTT for a few years now. Every month or so updating my recipes (that’s how they call each configuration you do, setting the trigger and the action), finding new channels and getting something to be done a bit more automatically. Last month, when I discovered they have a Fitbit channel, I was SO happy!


IFTTT has also a few apps, one of the called “DO” which instead of having a predefined trigger, you simply launch it to DO something (for example, send yourself an email with the current location). The IF app, which is the equivalent to IFTTT as an app, can also let you know each time your recipe got triggered.

All in all, this is a very nice tool, which can really save you time, alert you on things otherwise would take time to notice, do some annoying paperwork for you and much more.


While working towards a Scrum workshop in the office, I noticed, again, that there are quite a few animals in Scrum. And then I remembered Manimal, one of the best TV series I watched in my childhood (that and McGuyver of course).Manimal_66382 Immediately I imagined the Scrum Master, tackling another impediment by turning into a tiger and hunting the problem down… Wouldn’t that be amazing… (all of you who haven’t been here in the 80s, my apologies).

Anyway, I thought it would be nice to summarize here all the animals, at least those that I know of, that have to do with Scrum. And I am not talking about these alligators, that for some reason are scrumming around…  scrum animalscrum men(aren’t the pictures almost identical?)

First and formost – the pigs and the chickens:


This comes to explain that the ceremonies are first of all for the Scrum team (the pigs) which are committed to the success of their sprint, and only then to the rest (the chickens) who might gain a lot, and probably have a lot to offer, but are not the ones that gave commitment to the sprint.

Then comes the elephant carpaccio:


This comes to explain that we need to divide every task or user story to smaller tasks and stories, as small as possible, so that we can understand where we are, remove ambiguity, identify problems in advance and be able to see fast achievements and progress (and probably more).

How can one eat an elephant? piece by piece…

Not too long ago, I came to know my favorite animal – the dog (DevOps Guru):

sheleg(this is my passed away dog, Sheleg, and one of my kids)

The DevOps Guru, or DOG in short, is a DevOps expert who guides the company to a more successful implementation of the DevOps spirit (see a dog will guide you for more details).

Another dog in scrum, was at my graduation in the Scrum Master course (back in 2009). We had to bark to get our diploma…

There are some more animals in Agile – you can find more info on that in Ade Miller’s blog on Scrum Bestiary

[Reblog] A few items for Star Wars fans

This time I am bringing a few items that any Star Wars fan might find interesting.

Some of them are in Hebrew, like this one, from Geektime.

The next one was sent to me by a teammate of mine from India. How to make Star Wars gummies. Thanks Tanuj!

This one was sent to me by brother. It talks about a Star Wars event in London (in hebrew). Star Wars London event



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.

[Reblog] Yoda Star Wars – Yoda’s top 10 tips for a new Scrum Master

Here is a link to a post which talks about Jedi tips for a new Scrum Master.


This is another example of Agile and Star Wars mixed together, taking words of wisdom from a Jedi knight (like I did with Obi Wan in the last post), this time from the ultimate Jedi – Yoda himself.

Yoda’s top 10 tips for a new Scrum Master