Many people keep using agile as a noun (me myself, I do sometimes) to referring to Scrum/XP. Probably because of the boom of agile methodologies, people usually accompany the agile principles and manifesto with a real thing to implement, such as Scrum or XP. Also, this is probably due to the fact that Scrum and XP are the specific agile methodologies most used around the world and better known. Sometimes I forget FDD is considered, for example, agile. I am pretty sure in my brain FDD and ScrumXP do NOT fall in the same category, so I do not like the idea of these being in the same bag.
The use of the term can lead to confusion if you use it with people who treat it differently. Nevertheless, most of the people is talking about “agile ScrumXP” so in general people is understanding each other somehow.
On the other hand, there is the term “methodology”. In an unfortunate event someone called it methodology. People started to realize that Agile is not a methodology but a mind-set. Method is something way far from the idea of Agile.
I personally would distinguish for the sake of clarity in this way:
– Use Agile/agile as a name (it is easy), preferable the first one, though I know most of the people will not capitalize the first letter. To distinguish both most common ways of using agile I would use Agile Origin(AO) for the principles and manifesto and Specific Agile(SA) to talk about ScrumXP or similar tool. If someone ask you what kind of Specific, you should answer Scrum, FDD or whatever you are thinking in, but by default, if you do not mention it before, it should be Scrum and XP.
– I would also talk about Extended Agile(ExA) as the combination of Scrum-XP-Lean-Kanban. The reason is that usually we include Lean and Kanban with ScrumXP since they actually seem to combine naturally.
Whatever you use, people should understand each other. At the end the main thing is communicating properly.
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.
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.
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?
I finished yesterday the agile course I taught. It was a very funny and interesting experience for me. I present here the details of this course and the evaluations the student did:
Total number of hours: 4.5 h.
Number of days: 3 days.
Nationalities: French, Greek, Thailand, Saudi Arabia, Malaysia, Chinese and Japanese students.
- 3 french
- 1 saudi arabia, 1 chinese, 2 japanese, 1 malaysian
- 1 greek, 1 thailand, 1 chinese, 1 japanese
Results of the questionnaire
Unfortunately I just had 3 classes to teach the course so some people couldn’t get all the details. A practical example is a good idea, but still, the time limit we had make that impossible. I hope in further courses I can solve this issues.
If you want me to teach the course, just let me know! I want to improve this course as much as possible!
I teach a course on agile and most of the people has many troubles with user stories in general. It is normal! Many authors are talking about technical stories or other kind of stories and that means they also don’t really feel comfortable with user stories. Well, I usually think in user stories as something that the stakeholders can check on a demo. Something the user/stakeholder can consider an improvement, they can feel satisfied or happy about it. If you cannot show it, or you need to enter in weird technical details they don’t care/understand, it is not an user story, it is an expected task or task or whatever. So for defining an user story remember you need to think first how that should be demonstrated. It is at that moment when you can guess in an easier way if it is an user story or not.
Also, there are some problems when gathering user stories in a bigger one.
But that will be another day since I have to present now!
Someone asked me if agile fit game project development. I am not very familiar with game industry and I think it has some specialities found in other areas. Of course we could say that at the end there is a higher level boss there to tell IT guys what to do. For example, Hideo Kojima is producer, has the ideas and other guys implement it. That may be the common model and agile may fit without problems. Nevertheless there is another way to see things and it is to use normal users. They could develop a game for them with the ideas of some producer. Is it like this now? What are the differences?