About Myths

To every Myth there is always an equal destructive (Stupid) and opposite counter Myth:

Here are some Examples

Myth

You do not need to design up front

Counter Myth

Design is a one time effort which is best done before you start

Reality
You need to design some of your system up front and some of your system as you go. How much you need atg each stage depends upon your understanding of the problem, you technical skills & your system.


Myth

All user stories may be implemented independently from each other

Counter Myth

We must analyze all the dependencies between all features in order to lay out our critical path

Reality
There will always be some dependencies between different user stories, however a lot of those can be eliminated with some effort invested during story slicing. Those which are left are usually obvious enough for a reasonable team to deal with.


Myth

you don't need architects.

Counter Myth

A strong enough architect can design the system in such a way that anyone could implement it.

or

The architect doesn’t need to code

Reality
Every team needs to have strong design skills, when the projects becomes big enough a dedicated person (aka the architect) to help with the communication of the overall design and helping making sure everyone stays on the same picture is really important. However, the architect in order to be effective, needs to be involved in the day to day programming issues and challenges the team encounters. And at the end it will be the programmers that will do the implementation and they will adapt it according to their understanding so you better have a strong team as well.

Read more »

Posted in: Agile practices. Random Thoughts,Design,Engineering Practices

Creating a Mini-Waterfall

Some people refer to sprints as mini-waterfalls. Well that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
well its not very hard like anything else when you create a mini-X you start by taking the X for example:


and then you make the same thing just smaller. like this:

see where this is going?

I encountered several contexts in which a companies, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit inside short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well actually by itself no. Doing a mini-waterfall isn’t necessarily a bad idea.
on the Pros side we can say the following:

1. Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
3. To support working in small batches you will need to get used to cut and slice the work into small things.
4. and when you work in smaller batches, all kind of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side we should probably say that:

1. Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
2. Working in short iterations is just different than working in long cycles.
3. If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
4. And if it gets hard enough , most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations things that were comfortably hidden become  visible and painful.  and the natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile processes. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussion with people that experienced exactly that. (BTW trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well I don’t know. However, I’m not sure that’s even an interesting question. Personally I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First realize that by understanding the problem your are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and its really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn rom them.  Each and every pain is a place in which something new can be learnt, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they effect you team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes even a mini waterfall) require a new way of thinking to make it work. Most likely old solutions wont solve these new problems.

Read more »

Posted in: Agile Management

Can your team agree to this?

Read more »

Posted in: Agile practices,Engineering Practices

Do you think this guy is Agile?

A few days ago I read a very interesting article in one of the the local news site. the site was covering a speech given by a key figure. I’ve taken out some parts which I found extremely familiar. And yes I deliberately have taken it out of context as well,
Try to see if you can guess who said this, what is his role, and in what context it was said:
The following was said at the start of his speech:

When we ask ourselves what is the one thing that distinguishes successful human societies from failing ones. Answer is: the ability to change.

Later on I found this part:

When this is in your core, when you know how change, the difficulties you are experiencing are only minor glitches. The world is becoming increasingly competitive, more and more flat and global, we know about ourselves what others do not know about us: no matter what happens, no matter what will be the circumstances, we will know to take out the best. Whatever problem we will face, we will  know - almost instinctively - how to turn it into an opportunity.

Well to me this sound that the guy completely grok what Agile is all about.


And for those who doesn't  like to keep guessing.
This was said as part of a speech given By Yair Lapid, Israel current Minister of Finance. It was part of the speech given to him in a conference titled “Will tomorrow be better?” and in this talk he discussed changes our local economy will be facing in the upcoming years and about changes he is trying to make.

Read more »

Posted in: Agile Principles,Agile Values

“Introduction to Agile Process Management” Slides

Had great fun last week at the ALM user group meeting. Great audience with great questions and feedback, as well as meeting old and new faces.
For those who missed my presentation, and those who want to refresh their memory, here are the slides:

Read more »

Posted in: Agile Management,Events

Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

Must Testers know how to Program?

One of the most common question that rises when talking to testers in an Agile context is
“Does testers have to posses programming skills in an agile team?”
For a long time my answer to that was no, since testing includes vast number of activities which doesn’t require programming skill there will always be room for testers who cant program.
However I think that I was mistaken. these days I would expect anyone who claims the title of a professional tester to posses some level of programming skills. 

Testers who cant program are obsolete.

This fact can not longer be ignored.  As automation gains a firm hold in our industry a tester must be able to significantly contribute to all automation effort. And while certainly one can contribute to this effort without knowing how to program, the room for these is relatively limited.
Yes, even 10 or twenty years from now our industry will still have a large number of testers who cant program. The same way that even today there are still professional Cobol programmer or programmers who cant do object oriented programming.  But I would expect that this will be the minority

Testers who cant program – CATCH UP

If you want to stay valuable in the market, start learning the basic skills of programming today. no, I don’t think you will need to become an expert top notch developer (not that there’s nothing wrong with that). The actual skill level required in order to become a productive test automation engineer (i.e. significantly contribute to automation effort) is lower than that. But Unless you will start to aquire these skills soon you will find very hard to find new open positions.
Here’s an interesting post that backup these claims with some concrete data. And while I don’t consider this in any way as scientific proof or even big enough to indicate anything with significant statistical confidence, it still suggest that   ~80% of testing job posting indicated a programming skill as necessary. Also notice, this post was published as early as 2010.  My personal observation of recent job ads, which is certainly skewed towards Agile culture, suggest that the percentage is even higher.

Bottom line

As a tester you should want to know how to program in at least one major programming language ,in order to decrease the time you will be looking for a new job.

Read more »

Posted in: Agile practices,Agile Testing,Random Thoughts