In February 2001, 17 software developers published the Manifesto for Agile Software Development. There, they defined a new approach to software development project management. The adaptation of this methodology is gaining followers each day, and each year the number of development companies using agile strategies is increasing.
In this post I will review the Agile Manifesto and make some comments about it’s relationship to Remedy’s project Management.
The Agile Manifesto
The Manifesto says:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
So the manifesto is composed of four items that summarize the spirit or philosophy of the new approach. Let’s review these four sentences under a Remedy point of view.
Individuals and interactions over processes and tools
The most important part of a development team are the members and how they relate. They best proof to demonstrate this fact is that I prefer good people with bad processes than bad people with good processes. Your developers are the key to a successful project. Also, the interaction in this sentence refers that the combined power of your developers is more than the sum of each individual. As they work together they trend to increase the productivity.
How can we apply this concept to a Remedy development?:
- First, don’t rotate your people between projects. Project knowledge is not only about technical knowledge.
- Try to have general programmers instead of specialists. My advise is not to fall on the error of having one “web service specialist”, another “form designer”, the admin, and so on. Your people must be as polivalent as possible. You will always have someone that knows more about “Change Management” than others. But don’t restrict “Change Management” developments to only one person.
- Don’t break the work into pieces and isolate the work to each developer. Force the communication between developers giving them grouped tasks. Let them to redistribute the work. I love to listen “Finished, what are you doing? Need help?”. Means that they are redistributing the work.
- Place all your developers on the same room or as near as possible. They must interact every day. A development room is a noisy place where people are continuously talking about what they are doing.
But my recommendation is not to forget about processes and tools. And when talking about Remedy developments this sentence becomes even more important. A Remedy development is dirty by nature, so be careful to control how your team is working to maintain them on the best practices side.
Working software over comprehensive documentation
The objective is the software to work correctly. We must never forget it. We can do a perfect requisites elicitation, but this not guarantees a good product. That means that you can “forget” some part of the documentation is this will increase the work speed and doesn’t compromise the result.
In a Remedy development this applies to the max:
- The best analysis document is a form. The client has told you the requisites. The next normal step is to make the analysis and document it. But, instead of it, you can start developing directly with the conversation with the customer. Draw the forms directly at the developer studio. And then show them to the customer. Maybe you don’t have a requisites document… Who cares? Probably the customer will understand much better the created forms and provide some more useful feedback than a document.
- You don’t need to follow documented procedures about the testing of the product. It normally has a better result that when some programmer has finished his work to let a companion to check it. It’s quicker and it’s more reliable. Yes, you don’t have a test document, but… Who cares? You can even increase the efficiency of this action by implementing some competition like: share the works between two programmers so each one test the others. The one with a worst result pays the coffee of the other.
But, forgetting about documenting something doesn’t mean forgetting to check the requirements with the customer or not doing test. As I said before, procedures are a must.
Customer collaboration over contract negotiation
This is under my point of view the most important point. If not achieved, the rest of points will deliver more problems than advantages. You need customer commitment to the agile methodology. Will your customer change the scope taking profit of a not detailed an exhaustive requisitions document? Will you customer blame you of not having a documented test when something goes wrong after going to production? If you need to cover yourself in front of a customer, then you need a contract, a lot of documentation and to follow the initial plan, whatever it takes.
Customer collaboration means that the customer is an active part of the project. Means that he/she is completely aware of what is being doing and participates as much as he/she can.
For instance:
- It can be a very good idea to form a pair between a customer and developer during the “draw” of the form. While the form is shaped, the customer can interact directly and understand better the result.
- Project Planning is completely driven by the customer. While the project is advancing, the priorities can change.
- Don’t create contractual documents with a high degree of detail. While the project is running, the less accurate these contractual documents are, since they become obsolete quickly
The best scenario is where your customer is present on all daily meeting. Have you though about moving your development team to the customer facilities?
Responding to change over following a plan
Be careful! this sentence is poisoned!
You need to adapt to the new needs of the customer. The idea is to provide the best result. But you must maintain the budget of the project. The best way to achieve it is to make the customer a participant of the budget control. But this is not always possible. So you must be careful. As I said on a previous post, scope creep is the worst enemy of agile methodologies (specially in Remedy developments).
Although there are many articles that talk about this topic, I always like to see that this way of managing projects is increasingly more popular.
There is no doubt that this methodology or manifest, shows one of the best ways to manage projects, there are many other ways but I think this is the most appropriate.
Thanks Jose, I would like to tell how to use the actual work in this manifesto.
A greeting.
Thanks Joseba.
You’re always welcomed!
I meant, instead of: “I would like to tell how to use the current work In This manifesto”.
this: I would like to know how you are using the techniques shown in your work
I am not so arrogant jejejejejje
Good thought on implementing Agile in Remedy projects.
It would be nice to extend your thoughts on it and publish it in parts.
That’s a good idea. I was wondering about writing about the twelve directives of the agile manifesto.
I’ll think about it, and write it down!