You all need to work closely together on a day to day basis.
You need to have feedback, ideas and constantly change your decisions.
When people have to communicate via telephone or email you will have introduced another layer of weakness into the project that may contribute to the project failing.
Tuesday, 21 July 2009
Sunday, 19 July 2009
Relying on Business Analysts
To all BAs, I am sorry about this observation. It’s not personal, but you have been given an almost impossible job.
As an IT Director or Manager, you may think that your Business Analysts are one of the most important links in the whole software development phase.
You allocate a large proportion of the budget to them to produce highly detailed documents. But these details can only be as accurate as the customer has been able to describe their needs at the time the requirements were gathered.
What you may not be aware of is that it is quite often left to the Developer to finalise and correct those business requirements and business specification documents.
Let me just repeat that you spend a large proportion of your budget on Business Analysts, yet the Developers frequently have to correct the documents.
When a Developer has read one of these highly expensive documents, he will quite often find mistakes and anomalies in them.
“Do you really mean this”, the Developer will say, “oh no I don’t” says the BA.
The Developer will point out that certain scenarios have not been considered.
The Developer will point out that there are better ways of doing things at a far lower cost.
The Customer will say, “That’s not what I wanted”.
As an IT Director or Manager, you may think that your Business Analysts are one of the most important links in the whole software development phase.
You allocate a large proportion of the budget to them to produce highly detailed documents. But these details can only be as accurate as the customer has been able to describe their needs at the time the requirements were gathered.
What you may not be aware of is that it is quite often left to the Developer to finalise and correct those business requirements and business specification documents.
Let me just repeat that you spend a large proportion of your budget on Business Analysts, yet the Developers frequently have to correct the documents.
When a Developer has read one of these highly expensive documents, he will quite often find mistakes and anomalies in them.
“Do you really mean this”, the Developer will say, “oh no I don’t” says the BA.
The Developer will point out that certain scenarios have not been considered.
The Developer will point out that there are better ways of doing things at a far lower cost.
The Customer will say, “That’s not what I wanted”.
Thursday, 16 July 2009
Manually testing everything
You have got to have some sort of automated testing. I find it totally unacceptable that a bug is fixed, but unknowingly another part of the application has been broken.
Your Developers must have some sort of mechanism where they can fix a bug, change existing functionality or add new functionality and be 100% confident that some other part of the system has not been broken.
Your Developers must have some sort of mechanism where they can fix a bug, change existing functionality or add new functionality and be 100% confident that some other part of the system has not been broken.
Sunday, 12 July 2009
Suffocating your users
Stop being obsessed with users not being allowed to request or suggest changes.
OK, you’ve got to have an overall goal, an overall plan. But let the users and Developers deal with the actual detail of how your goals are achieved. For example, it is sufficient to state “that you want the public to be able to securely log into the system and view past orders.” Don’t start created long winded documents.
Don’t put a change control mechanism in place that stops users thinking of ways of improving your products.
OK, you’ve got to have an overall goal, an overall plan. But let the users and Developers deal with the actual detail of how your goals are achieved. For example, it is sufficient to state “that you want the public to be able to securely log into the system and view past orders.” Don’t start created long winded documents.
Don’t put a change control mechanism in place that stops users thinking of ways of improving your products.
Saturday, 11 July 2009
Insistence on implementing 100% of the features before doing a release.
Work on the top 20% features. Quite often these features will give 80 % of what the end users want. They can get using the system far quicker and start adding to the profitability of your company.
What’s amazing is that these top 20% of features are often well known, easy to describe and test. Concentrating on these features can kick start your project. Keep the users closely involved as each feature is developed. When a useful set of features is fully ready do a release. Yes that’s right a release as soon as possible, let the system be used in a live environment. Design problems can then be caught at an early stage in the life of the application.
Develop some more features then do another release in a month or two. Doing this means that the users and business community do not get big surprises. More importantly they are not left with an unusable and unwanted system that cost you millions to produce.
When you have completed the first set of 20% of features, move on to the next set. In all probability, feedback from the users will cause the features to be altered in priority or not required at all. You’ll have saved a great deal of time by not have written a detailed set of requirements.
You also avoid the situation where so much time has been spent on gathering requirements, documenting and reviewing them, that they must be implemented no matter what. So even though the user has discovered that a feature is no longer needed, the momentum of the project means that it must get implemented. That really is stupid.
What’s amazing is that these top 20% of features are often well known, easy to describe and test. Concentrating on these features can kick start your project. Keep the users closely involved as each feature is developed. When a useful set of features is fully ready do a release. Yes that’s right a release as soon as possible, let the system be used in a live environment. Design problems can then be caught at an early stage in the life of the application.
Develop some more features then do another release in a month or two. Doing this means that the users and business community do not get big surprises. More importantly they are not left with an unusable and unwanted system that cost you millions to produce.
When you have completed the first set of 20% of features, move on to the next set. In all probability, feedback from the users will cause the features to be altered in priority or not required at all. You’ll have saved a great deal of time by not have written a detailed set of requirements.
You also avoid the situation where so much time has been spent on gathering requirements, documenting and reviewing them, that they must be implemented no matter what. So even though the user has discovered that a feature is no longer needed, the momentum of the project means that it must get implemented. That really is stupid.
Friday, 10 July 2009
Trying to fit a square peg in a round hole
You can do it, but something will get damaged in the process.
Price, Features, Quality, Time. Something has to give. You decide which. But please do not add more features and then expect Price, Quality and Time to remain the same. You need to give and take
If you add more features, extra time will be required, unless somehow you can reduce the quality. (Don’t even think of that!)
If time, price and quality are fixed, then the number of feature you have in the product will be reduced.
Price, Features, Quality, Time. Something has to give. You decide which. But please do not add more features and then expect Price, Quality and Time to remain the same. You need to give and take
If you add more features, extra time will be required, unless somehow you can reduce the quality. (Don’t even think of that!)
If time, price and quality are fixed, then the number of feature you have in the product will be reduced.
Thursday, 9 July 2009
Failing to let the application evolve
The end users of the software do not have a perfect idea of what they want. They have a high level idea about the main feature that they need. Stop trying to get the users to specify every little bit of detail. It is very hard to do that and for very little benefit.
Just gather the top level requirements. Let the Developers build something that the users can experiment with. Quite often the users will then think of new features of greater benefit to the business, and also they will discard other ideas that in the beginning they had though were of high importance.
Just gather the top level requirements. Let the Developers build something that the users can experiment with. Quite often the users will then think of new features of greater benefit to the business, and also they will discard other ideas that in the beginning they had though were of high importance.
Wednesday, 8 July 2009
Big teams mean communication is more difficult
Big teams mean communication is more difficult.
Associated with smaller projects are smaller teams. Small teams make communication far easier. Decisions are easier to make. Let the small teams work in a fashion that suits them. Do not impose a 'one size fits all'. Success does not come from being constrained to walking down the same path as everyone else. Let teams wander off the path and take responsibility.
Don’t read that as a recipe for chaos. The team can still work to company standards and procedures.
The team can still work within CMMI if that is your company policy.
Associated with smaller projects are smaller teams. Small teams make communication far easier. Decisions are easier to make. Let the small teams work in a fashion that suits them. Do not impose a 'one size fits all'. Success does not come from being constrained to walking down the same path as everyone else. Let teams wander off the path and take responsibility.
Don’t read that as a recipe for chaos. The team can still work to company standards and procedures.
The team can still work within CMMI if that is your company policy.
Tuesday, 7 July 2009
Having a process that does not allow people to make mistakes
Mistakes are a way of learning
There are software development techniques that are focused on getting it right first time. This is really difficult to do. Very expensive in terms of time and the people in your teams are always triple checking everything so that they do not get the blame some something.
Why not aim for nearly right first time? It will be quicker to get to that point. You’ll make a few mistakes. But these so called mistakes are a great discovery process and will lead onto a superior solution. If you start blaming people, they will clam up, they will suppress their creativity, they will be clock watchers, and they will be looking for work elsewhere.
There are software development techniques that are focused on getting it right first time. This is really difficult to do. Very expensive in terms of time and the people in your teams are always triple checking everything so that they do not get the blame some something.
Why not aim for nearly right first time? It will be quicker to get to that point. You’ll make a few mistakes. But these so called mistakes are a great discovery process and will lead onto a superior solution. If you start blaming people, they will clam up, they will suppress their creativity, they will be clock watchers, and they will be looking for work elsewhere.
Monday, 6 July 2009
Big projects lead to failure
Big projects turn into NASA type projects; you just do not have the size of team and infrastructure to support that sort of project.
Make your projects smaller. Instead of the big bang £10,000,000 projects that usually go wrong, concentrate on smaller projects. Obviously these smaller projects are done with the bigger picture in mind. These small projects can then be completed in two to six months. From concept to completion.
You’ll need to allocate a business and technical roles to manage the big picture, particularly technical interfaces.
Delivering real useful benefits to your customers. You could do projects that deliver the top 5 business features that are needed right now. These features will have an immediate effect on your profitability and move you ahead of your competitors.
A small project means that you will probably complete it satisfactory. This gives a great deal of team satisfaction and this enthusiasm feed into the next project.
Big projects are difficult for people to associate with.
Make your projects smaller. Instead of the big bang £10,000,000 projects that usually go wrong, concentrate on smaller projects. Obviously these smaller projects are done with the bigger picture in mind. These small projects can then be completed in two to six months. From concept to completion.
You’ll need to allocate a business and technical roles to manage the big picture, particularly technical interfaces.
Delivering real useful benefits to your customers. You could do projects that deliver the top 5 business features that are needed right now. These features will have an immediate effect on your profitability and move you ahead of your competitors.
A small project means that you will probably complete it satisfactory. This gives a great deal of team satisfaction and this enthusiasm feed into the next project.
Big projects are difficult for people to associate with.
Sunday, 5 July 2009
Not involving users in the development process
These may be external users of the application, or end users within your business.
Keep the end users constantly in the picture. Do this by involving them on a day to day basis. Do not do the insane development technique of working for 8 months and then finally introducing the application to the users. They will not like it, whatever it is.
Show them early versions of the software. Let them use it. Let them give you feedback, and above all, let them change their minds without being punished. Look this is about making your company profitable. Trust your end users; they know what works and what does not. Keep them involved and allow them to contribute to the design.
Keep the end users constantly in the picture. Do this by involving them on a day to day basis. Do not do the insane development technique of working for 8 months and then finally introducing the application to the users. They will not like it, whatever it is.
Show them early versions of the software. Let them use it. Let them give you feedback, and above all, let them change their minds without being punished. Look this is about making your company profitable. Trust your end users; they know what works and what does not. Keep them involved and allow them to contribute to the design.
Saturday, 4 July 2009
Requiring everything documented to smallest of detail.
Stop trying to document every miniscule detail in an effort to prevent failure. You are guaranteed failure if you try and create documents that describe everything, quite simply you run out of time to do any high quality development work. You discuss the project, you document it, put in controls, discuss it, document it more, prioritise and re-prioritise, then at the end you want your Developers to finish the whole project in just an impossible 2 months.
In a lot of cases, a high level description in just a few paragraphs is sufficient and gives you the flexibility to change your requirements. When a task is allocated to a developer, the developer can discuss the detail with the users and business owners.
Here’s an analogy. Many large software projects often have more parts than a car. And certainly the parts in a software project will have more complex interaction than the parts in a car.
Suppose you were asked to document all the features that you needed in your ideal car. You also have to describe how all the parts fit together, describe the material and metal to be used. Specified the size and type of every bolt. You would probably take a very long time, then end document world probably be wrong and lack many of the feature that you want.
And because of your complex and rigid change control mechanism you cannot accommodate changes along the way.
A car is fairly simple to understand compared to a complex business application. Yet you regularly try and produce highly detailed requirement and specification documents. That’s crazy.
How about specifying some top level requirements?
So going back to the analogy of the car.
Needs it to run on green fuel.
Needs to be four wheel drive.
Be good if backseats folded forward.
Those brief descriptions are enough for everyone to understand where the project is headed. It means that actual work of creating the application can begin far earlier. Just imagine if you had to produce all the detail of how a seat folding mechanism should work. It would take weeks. Weeks that could be used in getting the project started.
The actual detail can be thrashed out at the time that it is needed. Perhaps you can call it “Just in Time Design”
This Just in Time design technique allows for something that always happens on Software Projects. Users changing their minds and thinking of new requirements. It always happens, it’s good, so why not cater for change? In the case of the car, the user may decide that he know longer needs the rear seats. Thus you have not wasted any time in doing a detailed design.
In a lot of cases, a high level description in just a few paragraphs is sufficient and gives you the flexibility to change your requirements. When a task is allocated to a developer, the developer can discuss the detail with the users and business owners.
Here’s an analogy. Many large software projects often have more parts than a car. And certainly the parts in a software project will have more complex interaction than the parts in a car.
Suppose you were asked to document all the features that you needed in your ideal car. You also have to describe how all the parts fit together, describe the material and metal to be used. Specified the size and type of every bolt. You would probably take a very long time, then end document world probably be wrong and lack many of the feature that you want.
And because of your complex and rigid change control mechanism you cannot accommodate changes along the way.
A car is fairly simple to understand compared to a complex business application. Yet you regularly try and produce highly detailed requirement and specification documents. That’s crazy.
How about specifying some top level requirements?
So going back to the analogy of the car.
Needs it to run on green fuel.
Needs to be four wheel drive.
Be good if backseats folded forward.
Those brief descriptions are enough for everyone to understand where the project is headed. It means that actual work of creating the application can begin far earlier. Just imagine if you had to produce all the detail of how a seat folding mechanism should work. It would take weeks. Weeks that could be used in getting the project started.
The actual detail can be thrashed out at the time that it is needed. Perhaps you can call it “Just in Time Design”
This Just in Time design technique allows for something that always happens on Software Projects. Users changing their minds and thinking of new requirements. It always happens, it’s good, so why not cater for change? In the case of the car, the user may decide that he know longer needs the rear seats. Thus you have not wasted any time in doing a detailed design.
Thursday, 2 July 2009
To many people in meetings
You have meetings where quite often eight or more people are invited to attend and discuss and make decisions on a wide range of issues. That is a complete waste of time. Usually nothing gets decided and the meeting ends with even more problems being raised and confusion from people who are not directly connected with certain issues.
There are a lot of issues that can be quickly discussed and resolved just by 2 or 3 people. If it’s a technical issue, then have that meeting at a Developers desk.
If it’s a usability issue then get to the desk of the user for a demonstration of the problem.
There are a lot of issues that can be quickly discussed and resolved just by 2 or 3 people. If it’s a technical issue, then have that meeting at a Developers desk.
If it’s a usability issue then get to the desk of the user for a demonstration of the problem.
Wednesday, 1 July 2009
Introduction
In this blog I will be describing practices in Software Development Processes that appear to be damaging to the project.
I'll also be describing any solutions that I know for those mistakes.
Please contribute your own thoughts. I am not a Guru, just a normal Developer who observes that lots of money is being wasted in many software projects.
I'll also be describing any solutions that I know for those mistakes.
Please contribute your own thoughts. I am not a Guru, just a normal Developer who observes that lots of money is being wasted in many software projects.
Subscribe to:
Posts (Atom)