Archive | Software philosophy RSS for this section

Zombag, facing a Zombie (software) apocalypse

I think there are many things to solve still in Agile. I am developing a framework (most of it for fun, I have to admit it) that is intended to help in the future with teamwork and other things. You can help me by providing feedback or joining the initiative. It is still in his first stage but I try to gather many ideas of what I have been learning in my life, experience working on software development and PhD.

Many aspects are about to come! Especially the ones of my PhD that are not included.

Hope you enjoy it at least! It is kind of a funny idea.

It is about zoooombiieees. Hohoho.

Zombag – Alpha Version

Help me out with constructive solutions, if possible!

I will update it with the time. I had a lot of fun with it!


Is adaptation a double-edged weapon?

We hear many people saying that adaptation is the key. In agile, adaptation is mandatory, and it seems everyone is comfortable with that. Recently, I wonder if this adaptation premise is harmless or not. I heard many people saying “well… we didn’t do this of Scrum (or other), because it was a necessary adaptation. Our business, A,B, C…”. Even they invented something called ScrumBut, that helps to realize and recall that you are doing some things out of the recommended way of Scrum. Adaptation is necessary, don’t get me wrong, since in this world everything is about that. Of course you need time to implement agile too. Nevertheless, the adaptation premise is an escape for many people who is not willing to fully implement an agile methodology. Many people just don’t have the experience or the, let’s call it vision, for modifying properly an agile methodology at certain point in the development (or even making prior-decisions). They may feel they are implementing agile, but they are implementing a partial agile. Partial agile, usually mixed with other approaches, seems to have way worse results than agile itself. De facto, not de jure. And it would be interesting to compare it with more traditional approaches.

People needs to be well-prepared, no matter how. To have experience in the field and theoretically in a balanced way. They don’t need experience so much as some companies sell or so much university formation as some universities sell too. They need good leaders or teachers wherever they go. I have seen 45 years old people, highly experienced and short headed (nothing against 45 years-old people of course, just an example. Also, the most intereting people are around 45 too hehehe). Same for university.

Whenever you make a change, this change should come as mandatory I would say. Imagine a team decides to avoid to have a customer integrated, since they have difficulties “A,B,C” (I have seen that!). Maybe everything seems easier and results come faster, or other “good” things may arise, but I am sure that it is not possible to measure other more difficult tricky things. What about the abstract-and-difficult-to-measure concept of quality, or implementing the correct thing, or delays due to useless implementations.

I think I read about a guru (I don’t recall who was, damn!) that asked to people -who were working as Scrum Masters or agile “managers” or whatever- “who is implementing agile in their company now?”. They rised their hands, and the guru was asking basic questions related with agile, quite important. He realized almost everyone was not using a real agile approach. I recently realized there is this double-edged effect with the premise of adaptation. If you teach and you explain what adaptation is, make always sure you explain the “psychological” drawbacks of the concept itself. Adaptation is not a blank check. Be careful.

The “political” client

Not many people is familiar with this kind of clients. It is one of the most dangerous clients and feared by everyone. Let’s start from the beginning.

There are situations where the client is what we call in Spain “political client” (I don’t know in other countries). A political client is a client that it can completely change just because a democratic election (or inner fights). The new clients elected don’t know and don’t have access to the previous clients. Things are barely documented and they have different goals and perspectives (usually arriving with a magnificence feeling, cutting, replacing, etc.). They probably hate the previous client, so whatever they did, it was wrong.

And how this thing goes for the hired company that has a project with the previous client? Well, the new client cannot stop the project because it is a lot of money, but you can guess that whatever it was done, it wasn’t good because the previous client was “evil”. And the previous client was “inefficient” so they probably will push the company to finish everything earlier, making threats, etc.

Be careful with these situations. Don’t think that just calculating the time when the democratic elections happen will remove the problem. There are inner fights and things can change the same way with people from the same political party. If you go into a government project, be sure the people you have is the right one. People is the key.

How do you fight this?

* You have to stay firm with the new client. Same rules (agile) should apply. He can change everything if he wants, but following the proper way and warning about the consequences of moving into different ways (All of this in a very polite way and indirect, of course). You gotta sell that the process doesn’t impact the output, so you can have as many “outputs” as you wish. Hard to say, and not true, I know, though you have to do it in that critical situation for not really crashing everything. Later on, you can step-by-step moving into other ways if necessary.

* He basically needs to feel happy and feel that things are going to change. Well, agile is about that, change. Just make sure you can save “agile” with the political change.

* There are other ways. If you have this problem, contact me to discuss it.

Why Scrum is alive and it wasn’t replaced by XP?

The answer is very easy, as easy as understanding Scrum. That is it. Scrum is very easy to understand to everyone and there is no coding in there that can confuse the bosses. XP, if you check the official webpage and their diagrams, well, you gotta spend some time to get used to that huge graph (and to apply it, quite a bit more). Nevertheless, it is basically detailing how to carry out the agile principles, when it comes to technical stuffs. I read papers saying that XP doesn’t have planning. Well, that is not true. Of course you have planning in XP, such as week iteration, or which of the functionalities should be implemented. Basically XP tried to give an step and clarify a bit the until-that-time dark part of what to do with the technical stuffs. The reason why XP didn’t replace Scrum, is just based on the incredibly good terminology and clarity of Scrum itself. Made for business people and not programmers. That is why, the combination of Scrum (for management) and XP (for programmers) creates a really good combo, and it is widely used. I recommend you to forget about FDD. It is just a trial to import traditional to agile, and it is not agile in my opinion because it leads to a traditional approach with the time.

Frameworks such as Scrum or XP are good because they can sustain an agile philosophy through the problems. FDD with the time (and I lived this in my own flesh) deteriorates easily.

When the client figure is not defined

The client. The guy who hires and pays. Or the guy you respond to inside your company. Is he always defined? Not always. Imagine a start-up where a bunch of friends have an idea. Somehow they did some marketing, identifying a need from the users. Nevertheless, when it comes to practice, they want to use agile. Who is the Product Owner? There are some options here. Ask yourself, is there anyone in your team especially capable to understand the users? Basically, a marketing guy profile, who studies the needs of the users and try to determine the best functionality for them. Done!

Is that so? Is that possible? Sometimes we don’t count with such profile. Then why you just don’t pick a user you know? Your father, your friend, your girlfriend, etc.

Still not possible?, because of time, because lack of vision, or other reasons? Then you may want to put the source of the idea. The visionary.

Another option may be to avoid the PO figure. Not really recommended, because the no-direction problem could happen among others. Basically if you remove it, you are just spreading the role on everyone in the team. If everyone has the same vision it could be ok, but, when that doesn’t happen you need to bring the Panzers. Select your leader PO1 and a sub-leader PO2. PO1 has the last word in the importance, but everything is decided by everyone, except when there are conflicts. The PO2 is just a helper for PO1. PO2 is also elected.

When you have one guy deciding the importance, you go into a straight line. Where that line brings you is a mystery! But when you have many people, you usually don’t know where you go. Everything will depend on how good is your team.

Hours vs User story points

I watched one of the one thousand videos of agile software development. The person who made it, says that the use of hours is better when planifying because it lets you know exactly when a task is going to be finished and therefore, when we can deliver some package of functionality.

I understand the things other way around. When I worked as a developer, you could feel what I call “the hours pressure”. We were estimating our own tasks hours and try to do them within the time. Later on the project manager used the hours to work on his own estimations. Looks nice. Looks fair. Looks flexible. The problem is that the hours pressure come out. Me and my team mates were worried in some sense when we made a mistake in terms of hours. There were always mistakes, of course, and nobody really used the exact hours. That is what made me think, hours are useless. I could say to you, Big task, small task, medium task, enourmous task, but hours?. Better the approach of tasks points or story points or whatever.

Developers have their own proud and people who like to do the things right, try to do it as much as they can when neccessary. It was those kind of non-written rules that even if you are told not to worry, at the end you worry. It’s normal. You cannot avoid it. You don’t like to slow down the team either.

With flexible measures at the end you may make less mistakes, people feel they have some margin, they don’t feel so much pressure and it is easier to assign values. Example, XL t-shirt size for this User Story. It could be 20 hours or maybe 30 hours but usually will oscilate because we always we have in mind a similar amount of WORK per evaluation.

You could say, how do you know when something is going to finish? Well, how do you know with User Story points in Scrum?

Measure is a double edged weapon

Measuring is a double-edge weapon if you don’t know when to stop. It is like knowing ourselves. Knowing myself helped me when I was studying my career. It helped me to avoid common mistakes I usually made. For example, I knew I always tried to solve everything by myself, without asking. That made me think twice whenever I was dealing with something I didn’t know, so I asked other people about it. That improved my scores and knowing myself helped me out. Same with software. Knowing yourself is necessary but think about this, would you pass the exams if you don’t study the subject itself and you focus on knowing yourself? The answer is no. Same analogy happens with software. That is why you should measure the things that may bring you more trouble and save the game through fully working delivered software. Yes, and you will feel relax after saving!

Don’t let many data or certain obsessions to overwhelm you! The client don’t care about measures. They care about results.

Ying yang software

I went today to Tokyo University to attend SamurAI Coding, a coding competition event that started last year (2011) in Japan. There were many young students (max. 25 years old) hungry to do something good. I was thinking if these coders are really aware of the differences between programmers and developers (let’s say like this). Everything started with an algorithm and perfection but nowadays there is so much more that we ended up into client satisfaction. We move from a scientist field to arrive into an engineering field and even marketing field. Let`s put an example. A “performance” coder could feel horrible with the idea of simple design and not improving the performance as much as he can. How could he feel, when he is taught to have this kind of mentality, when a boss tell him to pursue simple approaches even if the performance is not the best one. We are training these people still in one single conception and view, but we have to teach them in both sides (let’s say scientist? and engineering? point of view). They need to know when performance, when maintainable. There are other variables. You could say readibility or reuse or whatever, but the thing is, there are two point of views fighting each other everyday in software, and we need to learn how to balance. These people could feel frustrated if they don’t understand the difference.