About time I got this blog going again. Its been a while but now I am helping others with Social Media, better make sure I practice what I preach and also update my own website
Social Media is a great way to have a conversation with your customers and for them to talk to each other. But remember to do plenty of listening or you will appear way too pushy!
Thursday, 23 June 2011
Monday, 10 May 2010
Code Inspections, Peer Review and Pair Coding
Most of us probably think we are great no matter how polite we are. However we all make mistakes, maybe not really big ones but some small ones that can add up to considerable delays and over spends.
Code Inspections (give your work to someone to check) are good at finding many mistakes but often a good enough solution has been implemented and its really hard to now change that to a much better solution so we accept mediocre work which will lead to many small costs to fix and change is time goes on.
Much better is to do Peer Reviews. Get you work checked before you check it in. Fix the problems together to have an improved solution.
But ultimately Pair Coding is the way to go. Every problem and solution is discussed the 'best' solution implemented in the most cost effective way and no need to involve the politics needed to determine if fixes are worth it once the code is committed.
Code Inspections (give your work to someone to check) are good at finding many mistakes but often a good enough solution has been implemented and its really hard to now change that to a much better solution so we accept mediocre work which will lead to many small costs to fix and change is time goes on.
Much better is to do Peer Reviews. Get you work checked before you check it in. Fix the problems together to have an improved solution.
But ultimately Pair Coding is the way to go. Every problem and solution is discussed the 'best' solution implemented in the most cost effective way and no need to involve the politics needed to determine if fixes are worth it once the code is committed.
Saturday, 13 February 2010
Why Does it Always Take Longer Than I Thought
How much work can we fit into an iteration. Well that's an easy question to answer. You know how many people you have, can size the work, a bit of math and you have your answer... simple!
Well unfortunately its not anywhere near that easy and if you think it is, probably explains why you have to rush, get surprised why things are taking so long and if a manager, wondering if you have the right team for the job.
The truth is that everything takes longer than it should. Well actually it takes as long as its supposed to.
Well unfortunately its not anywhere near that easy and if you think it is, probably explains why you have to rush, get surprised why things are taking so long and if a manager, wondering if you have the right team for the job.
The truth is that everything takes longer than it should. Well actually it takes as long as its supposed to.
I remember a top manager saying "Our quality is good but the work ALWAYS takes twice as long compared to the estimate and that is not good enough". Well I'm sorry to say that if it ALWAYS takes twice as long its the estimation that is the problem as it should be twice as big (to half the time taken you need to improve processes not use un-realistic time scales).NO ONE ever works on a task all the time:
- There will always be problems that no one thought of
- If you are a team you will be helping each other
- People will interrupt you for information or you may need to go see them
- We all need to get away from the computer from time to time
Wednesday, 10 February 2010
Creating Focus At Time Box Planning Meetings
Focus is all important for meeting long term goals. When using a waterfall approach to software development the ultimate goal is usually huge and too far away to comprehend.
Using agile approaches help as we are focussing on the next release and some delivery 18 months away. Use your Time Box Planning meeting to identify the goals for the iteration. Make them achievable and pack a few extras into the iteration.
Make sure they are something functional, something where you can see the results, demonstrate to any stakeholders so they can give feedback on what they like and don't like.
Don't try to push the team by having too many goals in the Time Box (push then at the stand ups). We want to get to a position that people can trust that goals are going to be achieved so they can feel confident that progress is being made. The extras will be seen as tasty bonus treats.
Using agile approaches help as we are focussing on the next release and some delivery 18 months away. Use your Time Box Planning meeting to identify the goals for the iteration. Make them achievable and pack a few extras into the iteration.
Make sure they are something functional, something where you can see the results, demonstrate to any stakeholders so they can give feedback on what they like and don't like.
Don't try to push the team by having too many goals in the Time Box (push then at the stand ups). We want to get to a position that people can trust that goals are going to be achieved so they can feel confident that progress is being made. The extras will be seen as tasty bonus treats.
Thursday, 4 February 2010
Reduce Constant Interruptions With Time Box Planning Meetings
One of the problems with software development can be the constant interruptions and moving requirements from the customer. This problem can arise because the customer, internal or external, can feel they only have one chance to get things right. But with agile development we can always change and improve the software.
Make sure the stakeholders understand that for each iteration they will be invited to a planning meeting where we can all assess the development so far and identify the next most important issues that need to be addressed. Make it blatant that no decision is final, all things can be changes and nothing is wrong.
Once you can get this understood then stakeholders and developers are more likely to look at the bigger picture rather than get fixated on some trivial issue that may only be important to themselves.
The part of the planning meeting attended by the important stakeholders should be short, half an hour is ideal. You will find the most important things are discussed in that half hour and any longer is generally used to discuss trivial issues and unknowns (let the unknowns mature for a while you will know what to do in a later iteration).
Make sure the stakeholders understand that for each iteration they will be invited to a planning meeting where we can all assess the development so far and identify the next most important issues that need to be addressed. Make it blatant that no decision is final, all things can be changes and nothing is wrong.
Once you can get this understood then stakeholders and developers are more likely to look at the bigger picture rather than get fixated on some trivial issue that may only be important to themselves.
The part of the planning meeting attended by the important stakeholders should be short, half an hour is ideal. You will find the most important things are discussed in that half hour and any longer is generally used to discuss trivial issues and unknowns (let the unknowns mature for a while you will know what to do in a later iteration).
Monday, 25 May 2009
Easy Tracking Using Velocity Estimation
The easiest way I have found to plan and track progress is to calculate a "Team Velocity". By collecting data we can establish the velocity of the team. Based on the initial estimates we gave the work and calculating the difference.
For the original estimates I like to get the team as a whole to estimate the amount of perfect days it would take to complete the job. Perfect days being no problems, no interruptions, just concentrated work, which we know is not going to happen.
It is important to stress to the team that these are not figures they are going to be held to but 'points' to input into the estimation process.
If you are completely new to this process you will have to come up with an initial velocity. Now if you have a team of 6 working for 4 weeks that would give us 120 man days of work! Right so now we have our perfect days estimated earlier so every manager in the world will be tempted to have a velocity of near to 120.
Now the engineers will realy start to panic. OK so a hundred is a good idea... actually if you put it any higher than sixty on your first iteration you will probably fail.
A velocity of 1/3 to 1/2 of the overall man hours is more realistic. If you are not using agile ideas so don't expect your efficiency to be too high. The good news is that now you have started measuring, you will start to see problems, can focus future improvements and push the velocity up.
But whether you initially have a velocity way too high or way too low it is not something to worry about for too long as once you have completed as iteration you now know the velocity for that iteration. So if you guessed 20 and it turns out to be 40, excellent next iteration you can include more work.
As more iterations pass you team velocity value will become better. In that its closer to reality, sometimes higher, sometimes lower but in general about right.
For the original estimates I like to get the team as a whole to estimate the amount of perfect days it would take to complete the job. Perfect days being no problems, no interruptions, just concentrated work, which we know is not going to happen.
It is important to stress to the team that these are not figures they are going to be held to but 'points' to input into the estimation process.
If you are completely new to this process you will have to come up with an initial velocity. Now if you have a team of 6 working for 4 weeks that would give us 120 man days of work! Right so now we have our perfect days estimated earlier so every manager in the world will be tempted to have a velocity of near to 120.
Now the engineers will realy start to panic. OK so a hundred is a good idea... actually if you put it any higher than sixty on your first iteration you will probably fail.
A velocity of 1/3 to 1/2 of the overall man hours is more realistic. If you are not using agile ideas so don't expect your efficiency to be too high. The good news is that now you have started measuring, you will start to see problems, can focus future improvements and push the velocity up.
But whether you initially have a velocity way too high or way too low it is not something to worry about for too long as once you have completed as iteration you now know the velocity for that iteration. So if you guessed 20 and it turns out to be 40, excellent next iteration you can include more work.
As more iterations pass you team velocity value will become better. In that its closer to reality, sometimes higher, sometimes lower but in general about right.
A way I like to adjust the velocity estimation is to something like the "new team velocity = current iterations velocity + 9 * the previous team velocity / 10" which I think much clever people than myself call a one-dimensional filter!Using team velocity is an amazingly simple way to improve your estimation process. It gives the team the power, easy to implement and give management the information they need to know to plan the rest of the project.
Wednesday, 6 May 2009
VirtualBox by Sun
I'm loving Virtual Box at the moment. Not only is it allowing me to remove one PC from my home network but looks like it could be an incredible way of helping with Pair Coding and development in general.
How about having a machine with virtual machines on it. That way as we move around and swap pairs we can log onto our virtual machines and take our development environment with us.
Also has the added benefits that these servers with the virtual machines could be backed up more regular (well at all) compared to the average developers PC also possible opening up the way for thin clients and all the energy saving that they entail.
How about having a machine with virtual machines on it. That way as we move around and swap pairs we can log onto our virtual machines and take our development environment with us.
Also has the added benefits that these servers with the virtual machines could be backed up more regular (well at all) compared to the average developers PC also possible opening up the way for thin clients and all the energy saving that they entail.
Subscribe to:
Posts (Atom)
