Janusz Gorycki's blog

Agile is Dead

July 7, 2009 by Janusz Marcin Gorycki

The agile revolution has won. There is no doubt about it. No longer are its evangelists the pioneers who blaze new trails and chart the unknown, like they used to a couple of years ago. Agile principles, methodology, tool sets, even agile lingo, have become mainstream. Frankly, everybody and their dog is “doing agile” these days. Of course, there are pockets of resistance in the more backward (or “conservative” to be more polite) companies, but they are destined to eventually see the error of their ways and switch over. Even the most pointy haired of pointy haired bosses know that if they don't learn, accept and embrace agile methodologies, they are doomed to very soon become everybody's laughing stock, not to mention their careers are going to go down the drain.

And that my friends, is agile movement's doom. The revolution is over. The establishment has struck back, as it usually does, using the strategy it always chooses – assimilation, dilution, extermination.

Chopper Shops

June 22, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I have been watching an episode of American Chopper the other day. I must admit that I am a bit of a fan of this show – not necessarily because of its main plot premise of a clash of personality between the father and the soon (which is rather cheesy and quite clearly badly acted instead of real), but rather because I like watching “how stuff is built” - in this case, how you can build a gorgeously looking motorcycles from the rusty pieces of metal, using not much more than a set of rather primitive tools.

It was an episode where the guys at OCC bought themselves a super modern, computer-controlled metal-cutting machinery of some sort. At the same time, they had to resort to making order with some misbehaving part of the motorcycle being constructed by whacking it hard with a big hammer.

Watching this show got me thinking: this sort of work is very similar to what I am doing every day creating software. I always cringe when I read somebody likens software development to a factory line. Even if it is an “agile” factory line – like the Toyota Production System, which a lot of people in the agile community hold in such a reverence to that they almost pray to it daily. Because, you see, software development, in teams big or small , organizations huge or microscopic, is always a chopper shop rather than a factory.

Our Story Board is Better Than Yours

May 25, 2009 by Janusz Marcin Gorycki

I have decided to take a break from my usual bi-weekly musings about high-level, theoretical subjects and devote this post to something more concrete. I would like to show you how our story board that we use for sprints looks like. This may be of interest to both newbies and advanced users. The former will have a chance to see how this sort of a thing looks in practice, the latter will be able to compare with their own story boards and share their opinions, praise or criticize (in a constructive manner of course).

The subject is also interesting because it gives insight into the evolution of our team, its dynamics, its priorities – I think it is safe to say that our story board is a reflection of who we are and what sort of a project we are working on.

Let me start with a disclaimer: this story board is not “by the book” – it is not exactly the type of board that is described in Scrum handbooks. It started that way. But over time it has evolved, mutated, adjusted itself to fit our needs. “By the book” solutions are good in theory only, day-to-day reality requires you to be more inventive than what “the rules” require.

It's Cool to Break Stuff

May 11, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I am a proud father of two kids – 5-year old girl and 1.5 years old boy. For the most time they are good kids. But with alarming regularity, every couple of months, they turn out into terrifying monsters. For example, the boy would go to sleep at 7:30 pm each day and sleep well till 7am in the morning. Awesome. And then suddenly he would decide to stay awake for the whole nights for extended periods of time, and his poor parents would of course not sleep as well, turning into walking zombies during the day. Curiously, the little guy does not seem to be tired at all, even after his series of sleepless nights. Or my daughter would one day decide that she no longer likes to eat anything – with the exception of ice cream.

My wife and me used to be disoriented and powerless when this happened – until we consulted a child psychology book that described the phenomenon. And what do you know – not only is such a behavior of a child expected and normal – it is essential for the kid's development! Kids have to break the rules regularly, in order to build something new on top of the rubble.

By now, you can probably tell where I am going with this extended tale of my family life: the same rules apply to the software project. Every once in a while – and regularly – break something and re-fix it in a new way. Otherwise, your project, its internal architecture, its priorities, its target audience, its feature set, will petrify and very soon cease to be useful, attractive and desired.

Courage

March 31, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

Extreme Programming postulates, that courage is one of the fundamentally important virtues of an agile developer. I would augment this postulate and claim that it is, together with talent, THE most important one.

Why? Simple. Courage lets you overcome any and all obstacles that may stand in a way of developing a fine piece of software.

For example, I have seen a lot of cases where a programmer would shy away from an interesting project, because thay claim that thay lacked knowledge and expertise in the particular area. Or – the subject matter seemed too hard. They felt not „worthy” to try. Let me be a bit controversial and say: lack of knowledge does not matter. The courage to learn new stuff does.

Livestock

March 17, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

"How many resources do you need for this project?”. "How much headcount” - or even: "how many headcounts” – "do we need to hire?” If you are working or have been working in any sort of corporate environment, chances are that you have heared sentences like that. If you are a project manager, you are maybe even using them in your daily work. This sort of vocabulary became common in the software industry and people use it without giving any thought to what these words really represent. "Human Resources” is typically the name of your people-management departament.

If you use phrases like that, please stop. Now. Not because it is offensive to the ones you call "resources” (though it is), not because you are vulgarizing the english language (you probably are, but I am not a native English speaker, so I don't much care. But similarly ugly HR-type phrases made it to my mother tongue unfortunately).

The valid, business-related reason for stopping this sort of language is that reffering to your people as "resources” skews reality and does measurable harm to your projects.

Low Tech Rituals

March 3, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

"Still working the old fashioned way with whiteboards, spreadsheets and outdated software?” – I have stumbled upon an agile consulting company's web site with this slogan on the main page the other day. Efficiency! Speed! High Tech! Aren't we all supposed to be after these? Well – not at all times. So yes – our team maintains the old fashioned habits, uses low-tech, old school corkboards, does the planning sessions playing planning poker with actual playing cards (Piatnik brand if am not mistaken). We even sometimes plot the burndown charts manually, with pen and pencil. And we do it for a reason.

Don't get me wrong – the modern, efficient tools are useful. Hell, my company is making money producing and selling them! But – they are not everything, and they are not always appropriate. Use them as a tool, not as a gospel. There are things more important for your team's and project's success than the use of fancy software.

The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management ("Good To Great” by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That's not their purpose to be efficient.

Your Unit Tests Lie to You

February 17, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

Achtung: A Bunch of Obvious Statements Below

Continuing the grand tradition of writing "controversial" posts, let's take a look at unit tests - which for some folks seem to be the new gospel, the best thing since sliced bread, the cure to all our ailing.

Well - the truth is that, in the agile community unit tests seem to be a little bit overrated. Or, to be more precise - they are often incorrectly used as a "silver bullet" substitute for the tedious, labor-intensive, time-consuming, boring and un-gratifying, manual integration and system tests. They quite often, and wrongly, become the one and only QA process in the project. Let me tell you - these hope of getting rid of integration and system testing are false and maintaining them is extremely dangerous.

The Purpose of Unit Testing

Unit tests are a good tool for two purposes:

• they are a fast and simple verification vehicle, allowing you to test your unit's responses to variety of external stimuli - either ones that you could think of while developing, or ones simulating conditions that led to a bug in your code (if these conditions can be reduced to a unit test, which may or may not be the case)
• they give you a cerating assurance that the code you have created for the unit will not be so easily broken in the future by somebody who is refactoring it for whatever reason (bug fixes, improvements, rearchitecting, whatever)

And that is pretty much it.

The Art

February 3, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

Donald Knuth's famous book is titled "The Art of Computer Programming". Take it from one of the "gods" of our profession - software development is "The Art"! More precisely though, it is an act of creation. Nothing surprising about it if you take a closer look: suffice it to say that no two computer programs should be the same. If you find yourself coding the some thing twice, you are doing something very wrong. Also, computer programs do not really have any material form to speak of, other than a bunch of electrons stuck in a chip of silicon - they are quite literally - pure manifestation of someone's ideas.

Let me put this in an eye-catching one-liner to focus everyones attention: software is not manufactured in a scientifically controlled way - it is created

This simple (and pretty obvious) observation does not imply that programming is a more "noble" activity then, say, sweeping floors, bookkeeping or assembling cars in the factory - the value of ones work should be judged solely by the results and not by the nature of the task. It does however have quite a few interesting and very often neglected consequences - and any software project manager (agile or otherwise) would be better off rememebering them.

Don't Use Scrum

January 19, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

Models

Once upon a time, people believed that the earth is flat and the sun revolves around it. Then Copernicus came and offered the theory that matched the observed reality better. Then Newton attempted to explain why planets revolve (among other things). Then Einstein pointed out where Newton was wrong and straightened the theory to match the needs of his contemporaries – very soon to be superseded by a bunch of crazy physicists who invented quantum mechanics. These days, we pretty much know for a fact that quantum mechanics is wrong and we are in a search for a better theory. Now, all of the above theories have a couple of things in common:

• they are purely theoretical and idealized models of the real world (yes, even the flat earth theory)
• they were significantly better than their predecessors
• initially, they fit the needs of their creators
• they became the model to use, the latest craze, the offcial religion, the mainstream, displacing the previous models
• over time the number of corner case where the models broke increased to the point where they were unusable
• yet, the evangelists of the existing model fought hard to preserve them and to prove that suggested alternatives were pure lunacy (which, to be honest, 99% of them were)