The four species of Agile

1 comment

Tuesday, December 23, 2014

SukkotI’ve been a professional software developer since 2002 and worked for several software companies over the years - some practiced SCRUM, some used Kanban, some had a tailored made methodology and some didn’t have any methodology in place.

When starting with Agile a few years ago I found out that

“All waterfall companies are alike; each agile company is agile in its own way.”

Over the years I learnt to classify each company’s methodology using two factors:

  • Ceremonies – whether the company follows the methodology practices – iteration planning, retrospective, and/or daily standups.
  • Intent – does the company understand the agile values, strive for continuous improvement, quick feedback and embrace change (among other things).

And so I bring before you the four types of agile companies that I had the pleasure (in most cases) working for in the past:

Neither ceremonies nor intent (Aravah)

I got to work for several companies that had no visible software development process - or had a process which made no sense.

It doesn’t necessarily means that those companies didn’t had a project management “methodology” – in one case we had a whole division “planning” and “tracking” the various projects. Unfortunately the beautiful chats and predictions never affected us developers, and other than reporting (read: lying about) project hours it didn’t bother us much.

It was chaos incarnated – no one knew what was going on. Some of us were overworked while others would drink coffee all day. After finishing each task I had to ask my manager what to do next and from time to time we’ve shipped a product.

And so we’ve worked hard on fixing bugs and implementing new features without real understanding of the overall picture.

Ceremonies without intent (Hadass)

After a few years I got to work for Uber company Ltd. (if you know me you might know which company I‘m referring to). We’ve created a new shiny project that just had to succeed (at least until it got cancelled), and as such we needed to use the latest and greatest of everything - including a new methodology called SCRUM.

Consultants have been hired, courses have been taught, developers and managers were trained and a lot of money has been spent to make sure that the project would be a great success.

I was hired a few months after that and when I got there all that was left was the bills and a daily meeting that took between 30min to 1 hour – which for no particular reason we had to do while standing.

My educated guess is that the company refused to change its ways and so all that was left were the ceremonies: the daily meeting, planning that was done first by the team, then by managers and finally not at all and retrospective that happened three times during the year I worked there.

Intent without ceremonies (Lulav)

In one of the last companies I worked for before becoming a consultant was a team that knew about agile – the manager had experienced SCRUM before and wanted to us it to build software. He had a clear understanding of what he needed and wanted and how to achieve it. He had SCRUM custom made to fit his vision and while some of the benefits were lost on the way the underline values were always there.

Since the team was willing we were able to add daily meetings, retrospective and backlog and while the company never really wanted our iterations we were able to build a methodology very similar to ScrumBan that made sense for us.

We had TDD, task boards (plural) and clear priorities and we managed to create value for our customers – fast while reducing technical debt.

It was not always simple or easy but we all had the same goal and so were able to find tools and methodologies that worked for us.

Ceremonies and intent (Etrog)

This is where I became an agile addict – this utopian company decided to go with SCRUM and managed to stick to that decision.

When we noticed that SCRUM didn’t make sense for customer support – we’ve used Kanban for opened tickets.

After doing SCRUM by the book for more than a year we knew where we need to adjust our methodology and what we needed to keep on doing (retrospective) we’ve experimented with different iteration lengths, we had XP practices (pair programming, CI, TDD) and continuous deployment.

We managed to be productive and effective, we had management who was willing to provide us time to learn and much needed feedback.

Etrog_at_the_Market_of_the_4_Species_at_Bnei_BrakHadassim2

Summary

There you have it – four types of companies based on my (limited) experience – some were successful and some failed miserably.

If there is one thing I learnt is that you have to have intent and understanding in order to succeed with agile – I got to use agile in waterfall companies and I also so bad agile (and “no agile) practiced even when someone up the corporate chain decided that the company is an agile company – the decision rarely left the board meeting if the developers (read: those who write the code) were not on educated or in some cases even part of the process.

Take care when using comma in C++

No comments

Sunday, December 21, 2014

A friend had a weird bug while working in C++ last week. As sometimes it’s required he had to convert a string to an integer and instead of writing:
auto result = (SomeEnum) (stoi(s, nullptr, 10));
He wrote this:
auto result = (SomeEnum) (stoi(s, nullptr), 10);
Such a simple case of misplaced parenthesis caused the result to equal 10 instead of whatever s was.
In order to understand what the hell happened here you have to understand how the comma operator works in C++.
In C++ a comma is more than just a separator – it has its own rules and can cause grief if used incorrectly.
For example consider the following code:
auto whoami = ("111", nullptr, SomeFunc(), 42);
Can you tell what would the value be?
Strangely enough (or not) the result will be an integer “42”.
The reason for this strange behavior is that the comma operator works by evaluating each statement from right to left discarding the result other than the last one.
So keep in mind that SomeFunc was executed even if we didn’t get back its return value.
The same goes for the following (simpler) version:
int someInt = (1, 2, 3);
In this case someInt would equal 3.
And you can go complete crazy in a way only suitable for job interviews (from hell):
int someInt = (i = 100, i+= 20, --i);
In conclusion – be careful when using commas because you might not like what you’ll get.

Happy coding…

New Speaking engagement - DevWeek 2015

No comments

Monday, December 15, 2014

Now that I’m back from NDC London I have a chance to plan my upcoming speaking engagements – and it’s going to be a few busy months.
I’ve already blogged about my plans  for the next few months but since then I found out that I’ll be coming back to London (always a pleasure) in March for DevWeek.
image
The agenda looks amazing, good speakers and good talks and I’m happy to have three sessions – one for each day:

Navigating the TDD alphabet soup

TDD, BDD, ATDD are all methodologies that enable incremental design that is suitable for Agile environments. It seems that every day a new xDD methodology is born with the promise to be better than what came before. Should you use behavior-driven tests or plain old unit tests? Which methodology is better? And how exactly would it benefit the development life cycle?
In this session, we’ll sort out the various methodologies – explaining where they came from, the tools they use, and discussing how and when to use each one. Here we will once and for all answer the question as to whether or not there’s one “DD” to rule them all.

Battle of the .NET mocking frameworks

Writing unit tests is hard, isn’t it? You need an entire set of tools just to start. One of the crucial decisions when building this set is picking up a mocking framework. But BEWARE! What you choose has the ability to make you or break you! In this session, This talk will cover the capabilities and functionality of the leading frameworks, showing the good and the bad of the different options (both free and commercial), and making them battle to the death!

Unit testing patterns for concurrent code

Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a return value that is easy to verify. Writing unit tests for multi-threaded code is harder still. In this session, I will demonstrate useful patterns that he has discovered over the years, and that have helped him to test multi-threaded and asynchronous code and enabled the creation of deterministic, simple and robust unit tests. He will also point out the pitfalls to avoid.

Hope to see you there!
Related Posts Plugin for WordPress, Blogger...