Many of the principles of agile development sounds really good to me.
The one I like the most is the frequent delivery to enable continious feedback.
At the moment I am in a project on a pharma company that is regulated by validation rules.That means that with every delivery with new requirements implemented there comes loads of formal testing and validation work.
Dont know the rules of validating systems very well but there seems to be an administrative barrier that is doing frequent delivery impossible.Right now, in the worst cases we have around one year from construction to delivery of new functionality.So even if we did the right thing one year ago, is that what the customer wants today? Not for sure...
My question is: Is there anyone with experience on how to come around this problem and speed the delivery frequency in a validated project?
Tuesday, April 17, 2007
Tuesday, March 20, 2007
Effective developing...
In a recent project I worked in we often had problems getting the development process effective. So why? Where we as developers lazy and bad? Maybe, but it recently hit me that there could have been other reasons as well.
When we had meetings to summaries the upcoming work everybody were interested and looked forward to do a good job to quit the job as quick as possible. But after a while it hadn't happened very much. Why?
I found out that there can have been a couple of different reasons other than the developers being lousy and lazy that made the team ineffective...
- Writing documents where prioritized higher than writing code. So instead of starting to develop a couple of developers started to write documents they had to write first. Why not complete the developing tasks first and then write the required documents? What is most important, completing the development or the documents?
- The development is the only activity that is time estimated. So when you eg write documents or do analysis you can work without time pressure. So it gets more comfortable to do other stuff than developing because you can do it in your own pace.
- We had a lot of short task´s instead of grouping them together and making some tasks bigger. Every time you finished a task you lost some time before starting a new one because you felt happy and pleased finishing a task. Wrote an email and started to read interesting blogs for a while. You also had to get into a new task and understand the issue. So every time you finished a task you lost focus and pace. Better would be to get into a bigger issue and work focused on that one for a while.
- In many projects the developers are the "lowest" rank of the team members. So what should you do if you want to do "career"? Well, the first step is probably to quit writing code and do other stuff instead. Feels like writing documents are a good way to take a step closer to management...
When we had meetings to summaries the upcoming work everybody were interested and looked forward to do a good job to quit the job as quick as possible. But after a while it hadn't happened very much. Why?
I found out that there can have been a couple of different reasons other than the developers being lousy and lazy that made the team ineffective...
- Writing documents where prioritized higher than writing code. So instead of starting to develop a couple of developers started to write documents they had to write first. Why not complete the developing tasks first and then write the required documents? What is most important, completing the development or the documents?
- The development is the only activity that is time estimated. So when you eg write documents or do analysis you can work without time pressure. So it gets more comfortable to do other stuff than developing because you can do it in your own pace.
- We had a lot of short task´s instead of grouping them together and making some tasks bigger. Every time you finished a task you lost some time before starting a new one because you felt happy and pleased finishing a task. Wrote an email and started to read interesting blogs for a while. You also had to get into a new task and understand the issue. So every time you finished a task you lost focus and pace. Better would be to get into a bigger issue and work focused on that one for a while.
- In many projects the developers are the "lowest" rank of the team members. So what should you do if you want to do "career"? Well, the first step is probably to quit writing code and do other stuff instead. Feels like writing documents are a good way to take a step closer to management...
Saturday, March 17, 2007
Is agile people starting to get it?
Since I read Cedric Beusts blogpost "Agile people still dont get it" I have had a printed copy under my pillow because it was right on target.
Well, the TDD examples are still on a toy level and negative questions about TDD are answered with "Listen to me, I have done it and know that it works"...
But an interesting thing during QCon is that some things are getting better. Are the agile people starting the get it? It sounds like even the agile people think that it is a bad idea to run 100 miles without a map and a goal. I even heard agile people talking about "Inception". How un-agile isnt that word ;) Jim Coplien and Kevlin Henney had an interesting talk were they mentioned RUFD (Rough UpFront Design) as a good start in an agile project. To me it sounds like a very good idea. It cant be bad to think a little bit before you start developing in a project. But then of course automated tests are a great way to keep quality in the things you are doing, but is it really a good idea to let it create your design.
Design should grow during the project, it should not be done (written) before the project starts and then never questioned again, but still I dont think that tests are the best way to form your design.
Now I am really looking forward to start learnig more about the agile methods when they are starting to get it ;)
Well, the TDD examples are still on a toy level and negative questions about TDD are answered with "Listen to me, I have done it and know that it works"...
But an interesting thing during QCon is that some things are getting better. Are the agile people starting the get it? It sounds like even the agile people think that it is a bad idea to run 100 miles without a map and a goal. I even heard agile people talking about "Inception". How un-agile isnt that word ;) Jim Coplien and Kevlin Henney had an interesting talk were they mentioned RUFD (Rough UpFront Design) as a good start in an agile project. To me it sounds like a very good idea. It cant be bad to think a little bit before you start developing in a project. But then of course automated tests are a great way to keep quality in the things you are doing, but is it really a good idea to let it create your design.
Design should grow during the project, it should not be done (written) before the project starts and then never questioned again, but still I dont think that tests are the best way to form your design.
Now I am really looking forward to start learnig more about the agile methods when they are starting to get it ;)
This paper was seen on the open space during QCon, and it wasnt me writing it...
The worst possible start?
During QCon Dave Thomas had a great talk about the Dreyfus model describing different skills of a person. From novice to an expert, a novice is a beginner and the best thing for that kind of person is to apply things and fulfill simple goals with guidance. The expert wants to work on intuition and don't need that much guidance.
So what happens when a new resource comes to a project? Since the ordered computer probably is a week late, the new person gets enough documents concerning the project and the architecture to keep you busy for the first week. Instead of having some simple and short tasks ready for the new person you create the worst possible start in the project. When the person have worked for a while in the project, then will he/she probably start asking for documents that can give more understanding and at that time will he also be a lot more open for the information.
So, dont I think it is a good idea that a beginner should know some of the traffic rules before he starts sharing the road with me? True but still, do you need to drive your first miles in a car on a public road? That is probaly not what the beginner wants to do either. He wants to test driving a car, probably not on a road but maybe on a gigantic carpark where the risk to meet another car is small. Maybe he also need some guideance from the teacher, lets call it pair programming. But still he wants to drive the car! When you come to your first driving lesson youre probably not very interested in how the car is built and how many cylinders the engine have.
The perfect start for a new developer is the same, not reading documents on how the architecture is built but doing simple tasks that will give a good start and interest in the project.
So what happens when a new resource comes to a project? Since the ordered computer probably is a week late, the new person gets enough documents concerning the project and the architecture to keep you busy for the first week. Instead of having some simple and short tasks ready for the new person you create the worst possible start in the project. When the person have worked for a while in the project, then will he/she probably start asking for documents that can give more understanding and at that time will he also be a lot more open for the information.
So, dont I think it is a good idea that a beginner should know some of the traffic rules before he starts sharing the road with me? True but still, do you need to drive your first miles in a car on a public road? That is probaly not what the beginner wants to do either. He wants to test driving a car, probably not on a road but maybe on a gigantic carpark where the risk to meet another car is small. Maybe he also need some guideance from the teacher, lets call it pair programming. But still he wants to drive the car! When you come to your first driving lesson youre probably not very interested in how the car is built and how many cylinders the engine have.
The perfect start for a new developer is the same, not reading documents on how the architecture is built but doing simple tasks that will give a good start and interest in the project.
Just home from QCon
First QCon came to an end yesterday and it was a pleasure to be a part of it. Main learnings at the conference:
- Scrum seems to be the leading agile method at the moment.
- To be successfull make decisions as late as possible.
- The sun always shine on an agile person. Because if it rains, he isnt agile...
At the flight home reading a paper we found a very amusing ad that we didnt really understand ;) During three days we learned that Scrum is a good thing, so how can Scrum be used as a threat?
Subscribe to:
Posts (Atom)
