A few ideas on how to implement improvements in your software development
It is not uncommon to hear that up to 70% of the work done in software development projects does not result in an end product that is used. From the stories I hear this number does not suprise me. Let us take a look at a few ways in which we can improve the process of software development so that all the work we do results in a product that is used for the purpose it was originally intended to be used for.
As with any improvement process you should identify where you focus your efforts. Software development often spans organisation boundaries. Initialy you may only be able to make small improvements within your sphere of control or influence. Hopefully as others see you or your teams improvements they will open up and start to contribute.
1: Improve the quality
Poor quality is a major constraint on software development. Poor quality requirements will result in features that do not meet the end users needs. If you have good quality requirements but poor development practices, the result is similar, features that do not meet the end users needs. Improving the quality is likly to result in visible improvements and build confidence.
2: Reduce work in progress (WIP)
See Multitasking and Work In Progress in the artical Optimise work flow in a complex environment
3: Understand the need and the value for your software
Before you even start a project you must have identified a business or organisational need that must be satisfied in order for the busness to improve or take care of some legislative requirement.
It is very easy to have an idea that when considered in isolation seems to be an excellent idea, but when considered in the context of the organisations strategic direction, it is actually counter productive.
Guide line: Be clear about the strategic direction of your organisation
Guide line: Understand the business case
4: Get the right people involved at the right time
The most common mistake is not getting the right people involved at the right time. This results in time being wasted and the wrong decisions being made which results in waste and higher costs.
To be involved a person needs to have the required time set aside to do the work. Make sure that the users that will be working in the project have some of their operational (business as usual) duties re-allocated to other staff. See this as a good opportunity to train up other staff.
Guide line: Create a project organisation tailored to the project needs
5: Develop the requirements and the functionality in stages, and with the end users
I have never been on a software development project where at the beginning of the project, everyone has a clear understanding as to what will be most suitable. Allow the requiremnts to evolve in detail over the period of the project. For this to work there must be a well formulated governance framework to control all the project variables.
Get the end users involved in writing up their requirements as well as involving them in the production team so that they can see and test what they are asking for early on.
Guide line: Every requirement must must be linked to a necessary benefit.
Guide line: Plan at the right time and the right level of detail
Guide line: Use product based planning
Guide line: Use a product breakdown structure to make it easier to focus on specific areas of functionality
Guide line: Use the product flow diagram to visualise how you will build your software product
6: Automated testing and continuous builds
The investment in automated testing and continuous builds will increase productivity and reduce downtime. You will also increase confidence, trust and respect for the production team.
Many software products grow wnd evolve over time this adds to the complexity of maintaing the product. Idealy you will start implementing the automated testing when starting to build a new product. Software products that are more than a few months old and have not had automted tests included will start to build a technical debt, which is likly to evolve into a larger problem over time.
If you are faced with a project that is building on an existing product/system then start your automated tests on new functionality and whenever a “bug” surfaces. This way you can progressivly improve the quality and reliability of the product.
By running continuous builds you will ensure that the whole system works with the new functionality that has been added. When a problem does arise it is relativly easy to fix as the team knows what has just been added, and therefore can work quickly to identify the root cause, which may well be an incompatability with some of the legacy code.
7: Have regular retrospectives
On a regular basis and time get the project team together and discuss how you can fine tune the work processes. There is a large amount of information on the internet on how to run a retrospective such as Agile Retrospective Resource Wiki
8: Develop a culture of disciplin, trust, respect, honesty and collaboration
This can be very difficult to achieve for many reasons, but it is not impossible. It requires that people take responsibility for their decisions. We put this as the first step, all the following steps will contribute to achieving this culture.