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

The Mistake Programmers makes with Requirements

One of the more common complained I often hear programmers make is that they don’t not get good enough requirements, and even when they get them its many time too late and more often than not they significantly changes along the way.
(and by change I don’t mean getting new requirements all the time which also happens, but to the same requirement starting as one thing and then ending as something different)
at the end of such a complaint there is always the assumption, which sometimes is said explicitly and sometimes not, that if “they” could write proper requirements all our problem will be solved.

Perfect requirements are a Myth

in order to understand this statement one must think what is the purpose of a requirement. that is why do we use this mechanism. and the goal is actually quite simple. we need to get a need which usually sit at the user/customer head and be able to move it into the programmer head in such a way that the programmer will have full and complete understanding of what’s need to be done.
unfortunately the mean to pass ideas from one head to another without any lose of meaning does not exists in our world (yet), and therefore no matter how hard we try we can only do better and not perfect.

How are we doing?

Apparently not great. programmers still complain that they need to get better requirements. However I feel that we got it wrong. We have been trying for the last decade or so to make things better. Good and smart people have come up with ways to improve requirements writing and invented better way for formalization for example Tom Gilb points out that

“Requirements, the root to failed projects.”

and has some great ideas on how we can improve on that. but at the end this is in my opinion he wrong way to go.

if you can't beat them, join them

We programmers must accept the fact that understanding the business is our responsibility. Expecting others to explain things to us is quite a childish approach. At the end it is us who knows best how to gather the needed knowledge in such a way that we can understand it we fully understand things, therefore it is we that need to go out and follow these ways and reach the needed understanding. Fleshing out the requirements to a point in which we can implement them is our responsibility.
Yes there are people who can help us along the way, and yes some of them belongs to the product side which traditionally is in charge of writing requirements. But no its not their responsibility to explain it to us. They are in charge of picking out the good features, they are in charge of finding the best ways the product can grow and serve the customer. when they do its our job to understand what they want and then implement it to the best of our ability.
It is the programmer job to understand the requirement.

Read more »

Posted in: Agile practices. Random Thoughts

Handling Bottle Necks in Scrum Team

During  yesterday open house I was asked an interesting question. 

Some context first. The organization has chosen to adopt the Scrum methodology (good for them). As a scrum team member she is in charge of writing the automation for system test using a module inside the QC product (can anyone guess what's wrong here?). The issue is that she cant keep up. The team has 5 developers who write code and only her to write test automation (now do you see it?). So she was asking what is the "agile" solution to this.

I don't know if this is The agile answer, but for me, when a team member cant keep up and doesn't manage to finish his tasks, he needs help.

No agile process or in fact any other development process will change that. If a given person has too much work no matter if he works under a Scrum team an XP team or a waterfaoolish team, he has TOO MUCH work. Without help he wont finish on time. If no one on the team has the time to help, its a good indication (to me) that the entire team is overloaded. Face it, no magic answer here. No process I know of will take the time needed to complete a given work and make it shorter. The only thing we can expect a process is the focus the effort invested in the right direction, help eliminate wasted effort and establish an environment in which the team can become better. Until that happens, be realistic. Commit only to the amount of work that you can currently handle.

Another issue I saw, was in the exact role definition. Part of the problem (in my eyes) is that in this specific team they were still thinking in the terms of well defined roles and responsible. Here are the people which writes code, here are the people who writes tests, here is the manager and so on.

In order to become more effective, we strive for versatility. that is we want each person in a team to be able to do every task involved in building the software. Yes we accept the fact that people still have different expertise and that's good. However when a team member gets behind schedule we wish that any team member will be able to come in and help. My guess (and clearly I can be mistaken), was that in this specific team she was the only one trained for that kind of work, therefore no one could actually help her. At least not at this point of time.

What to do?

First gather the team and raise the issue (can be done during retrospect meeting). Accept the fact that at this point of time you can achieve only a given amount of work (which is less than you thought). Face the facts and as a team inform management and commit to less. Its not much help if the coding tasks can be finished faster then can be tested. Development is not done after the coding phase. Try to resist the urge to take that kind of work (which currently is the bottleneck for the entire development cycle) and move it outside (to a different sprint or different team).  Also make sure that programmers wont rush ahead and take on more coding work cause it easier for them to do. make sure that no extra work is picked until committed work is actual done. And I mean done done as in coded, tested, integrated and everything else which falls under you definition of done.

Also, make sure to increase capacity. Either by bringing in help by hire more people (not likely at this point of time in current economy), or maybe from somewhere else inside the organization. Or train other team members. Yes this will be painful and will probably require a serious effort in making the team leave its comfort zone. But if your goal is to establish a self contained team this must be done.

Read more »

Posted in: Agile practices. Random Thoughts,Scrum