I was in El Corte Inglés today. This company came out of nowhere in Spain to become the leader in selling goods. Everything started as an small tailor’s shop. They were the best, they gave the best service in terms of handling, results and manners. That was in the 90’s. Recently, I heard from a worker that they outsourced their tailoring services, what made El corte ingles what they are. Before, their clients did not need to pay any tailoring as extra charges but nowadays you have to pay it since it was oursourced. Until that point, everything could be OK. The thing I was surprised is that reducing costs by oursourcing the tailoring service also impacted in the result. I went to buy a suit and wanted some adjustments. I had to come back THREE times to El Corte Ingles to finally get the proper adjustment, but not because the seller failed, no, he was very good. The tailor’s did not make the changes properly TWO times. You can imagine why. The pursue of reducing costs became bread for today, hungry for tomorrow.
The same thing happens in software. For outsourcing services, you have to be prepared for that. You reduce cost, yeah, and you create sneaky problems that if you are not aware of them, it will impact your company in the future. Outsourcing is a double edge weapon.
Losing the identity is the worst thing that can happen to a company.
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.
Help me out with constructive solutions, if possible!
I will update it with the time. I had a lot of fun with it!
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.
Recently, I talked to a friend who is an analyst in a renamed company. I was curious about the way the company works and the view my friend has about the company, the situation, etc. Two things especially captured my attention:
– My friend said that they have a manager figure, planning and so on, but apparently useless for my friend, doing nothing, or nothing significative. A few times he came and ask, “everything alright?”.
– They had to fulfill some sheets to control the productivity of the workers. If they don’t achieve some goals or minimum they are fired. Apparently that thing happened quite often.
I didn’t have much time to talk since we were with other friends that didn’t like much our topics. Nevertheless, with these two bullets you can guess there is still a lot of work to do in the way companies still work.
I am using this blog for writing my thoughts since a PhD is most of the time reading, summarizing, analyzing, etc. but it is really hard to work on what you really want to work, the things why you started your PhD. To check one idea, it takes you years within a PhD. The reason is the complexity of the “science” process (that already Rene Descartes wrote down very well). But I am not a scientist. I am an engineer. We don’t seek for the perfect answer, we seek for the optimum answer. Scientist don’t pay “attention to money”*, just true or false. Ironically, software engineers are constrained by money, society or human nature in general, technicalities, etc. We work with the hands cuffed, in terms of the solution we have to provide.
It is hard to know when we are being too theoretic and when we are being too practical. With agile frameworks, it happens the same I guess. There out there dozens of agile methods but recently I am wondering why Scrum, being so old wasn’t beaten already by the newer ones? My answer is iPhone. Everyone is familiar with iPhone nowadays (also important to be successful). Why iPhone is such a success? The same why Scrum is a success. Usability, which means user satisfaction, simplicity, less user-error prone, etc. Made for the mass. I was discussing not long time ago with one of my colleagues. He was telling to me that Android can do much more things, like A,B,C, and it is really easy, just swiping three times and touching one corner while you are standing up with one leg (just kidding, it is just for you to get the idea of what happened, I love Android too). I just said to him, give that to your mother, teach her how to use it in two ways (the fast-weird and the stupid-long) and wait to see which way she will use. We both knew the answer.
With Agile frameworks, IT IS THE SAME. Scrum is an “optimum” success because the gap between theory and practice is almost zero in comparison with other frameworks. Everyone understands it. Moreover, Scrum puts over the table just a few things, which is basically the skeleton and an easy common language. I don’t need to know a damn thing of computers and their boring problems, that I can understand Scrum. So, I can sell it to the business layer. And we use the same terminology. Later on, for the technical things, whoever-business-guy could say: “deal with that engineers! that is already your job!”. And it is true. Scrum allows you to define a link between business and IT, that is all.
Other thing is the deterioration rate (El deterioro) that agile frameworks have. I have never seen anyone considering that some agile methodologies deteriorates more than other ones. People in software are talking about “ideal materials” but building’s architects can tell you that any material, no matter which one, deteriorates with the time. With methods I think it is the same. They deteriorate, and at different rates, due to the duality theory-practice, depending on many factors. And most of the time they never get to their súmmun. And the problem of some methods is not really the things you have to do. It is the way it goes if you try to do that.
Of course, the real world is not perfect, and you will face zombies sooner or later. Moreover, there are many problems with Scrum that need to be addressed, especially in a globally distributed project. I wish one day I could arrive to the point I can apply my ideas!
Note: Good marketing is also part of the key. But there are only a few companies that can survive with bad products and good marketing. Usually huge ones.
Note 2: I would like to check how square heads we are, software engineers. In a changing environment like the one we have, we gotta be flexible and we have to break with the old concept of engineer (and I was one of the lasts old engineers produced in my university… thankfully-sadly).
* I mean, they need money, but they don’t look for solutions to daily problems, they want to reach the “truth of the nature”. Though most of the scientist have to find nowadays practical uses to their researches, but that is other thing. Scientist nowadays are engineers in general, because in our days, invested money have to lead to benefits. But let’s stick to the traditional concept.
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.
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.
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.
Japanese companies are different.
I was talking with one of my lab mates and he explained to me some details of how japanese people find a job in Japan. I was surprised. And I actually knew many details about it before. I suppose I still cannot accept my country is so retarded in this kind of things (Or too clever and evil…). But it is.
First, japaneses find the company they want to join and not one position that they want to perform, about 1 year to 2 years before graduating (only during April, because there is no need to hire any other moment). If you have a Master or preparation in general, you are well considered (I know it’s crazy, but believe me…). There are different philosophies but I think usually they have to perform some tests if they don’t have experience. Well, another one right?. Also, they ask you about your future. What do you want to do here? Your plans?. Hehehe, crazy. Once they surprinsingly answer sincerely (my lab mates at least did), they may get the job. If not that one, another one (4% of unemployment of people don’t want to work on some positions). If they get it, the company will offer him/her several options. “Do you want to work in an office or as an engineer?”. You have to be kidding me. I suppose they don’t have problems to fill vacants with this attitude. And then, everyone finish their master or bachelor meanwhile the company wait. Spanish companies, learn!. They trust their people. They trust they will perform 100% and they trust they will stay almost forever in the company. I will, if they get such a nice contracts and future perspectives. After several years, if you perform correctly (polite and socially talented in general), you get better positions (if they want, because not always they want). And that’s it, you die later, without turnover or being fired (in general).
I met many people. We cannot even imagine how much talent have our country. All wasted due to many factors. Young people, move out from Spain at least for 5 years. It is true that in Japan they spend many hours working. But they consider working going to drink with your boss too. It is part of the job too! They consider their company their clan, their guild, their future, because they can.
NOTICE: This is completely biased. My information comes from Keio students in general. FYI, Keio is a priviledged private university, top in Japan, founded by the person who appears in the 10.000 yen bill. And no…, I am not rich at all.
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?