Last time I discussed the key characteristics of software process improvement exercise. This time I will be focusing on what steps we can take to develop or refine our methodology.
Again you are working as a consultant, assigned to refine or develop the development methodology for your client.
1. Understand the environment: Identify typical projects, team structure, existing skills, past history of project delivery, nature of business/clients, create a picture of existing environment.
2. Identify the needs and objectives: Find what your client expects from you to deliver but be careful it is quite possible they themselves do not exactly know what the need and may ask you to deliver something irrelevant. At higher level, with the help of your understanding of their existing environment and prcoesses, identify their main pain points and areas where improvement can be achieved.
3. Build a Team: You may be required to work alone and on your own but always try to have some team on board for software process improvement exercise. Though you might be working on the assignment primarily but a team should be there to review and verify your work on regular basis, say weekly or fortnightly. Such a team should include people from Technical Management, Project Management, Development and Support. If you can't build such a team then you would have to do your assignment in multiple iterations i.e. developing the process, putting it in front of development team & management for review, getting feedback, making changes, feedback, changes, feedback........ though this may result in lot of rework and deadline slips.
4. Develop a roadmap: Develop a plan, identify major deliverables and milestones. Do not attempt to come up with a schedule with fixed dates, talk in terms of weeks or month. Keep enough room in the schedule to accommodate any additional work.
5. Explore the existing practices: Start going into details of the existing process, find why do they fail, attempt to identify repetitive problems and their causes, find how the processes were developed, how religiously existing processes are followed, if not followed then why not, what developers like and hate most, where are the conflicts of interest among different Teams. Draw detailed process flows.
6. Research Agile Methodologies: Having problems, challenges and needs known, attempt to find where agile techniques could help you. Do not attempt to adopt some agile methodology completely, only look for the solutions that would be able to help you. You may get benefits from techniques like capturing requirements through user stories, iterative development, continuous integration and automated deployment, automated unit testing, unit test first, pair programming, stand-up meetings each day, having client representative on board to assist development team during development etc. Be mindful that some techniques may be dependent on other techniques to be adopted as well.
7. Apply the techniques and refine the process: Attempt to see (in real world) how the new techniques, activities or artifacts would help you in overcoming the existing problems. Dry run the process, think about all possible scenarios (small/big projects/team etc), refine the process flow, add/delete activates, artifacts, again & again challenge yourself by asking why (& why & why). Be mindful of jargon and terminologies, do not unnecessarily attempt to replace the existing ones with some new ones when there would be no clear benefit.
8. Documenting: Once your newly defined processes look stabilising (after reviews and reviews), start documenting it. Document the entire process, phases and activities. You target audience will be a new person/developer joining the team without any prior experience in processes based development. For each activity, describe the objective, input/output, guidelines to perform that activity, success criteria and any support documents to be used to perform that activity. Create the templates and more importantly samples of the artefacts. Samples are the quicker way of communicating a process or standard and provide some reusability.
9. Present it to the entire development team and review with them. Don't be afraid of making it flexible and giving some room to the developer to manoeuvre, but of course not at the cost of quality and violating the process. For example, you can let them choose use cases over user stories for some time, or allowing developing unit test cases after coding (but before checking in the code).
10. Quick reference docs: Develop quick reference or activity specific documents, ideally one page only for each doc so that developer could stick them on their desks. It may include development principles (security, performance etc), Unit Testing Guide, Source control guide, coding standards, company specific application frameworks and architectures.
11. Publish it: Publish it and make it accessible to the entire development and technical teams. Here one tip, try 'Save as html' feature of Microsoft Visio. You can very quickly convert your Visio diagrams into web pages and link up all process documents to the html pages, making it a single point of entry for the developers.
12. Run a Pilot: Job is not finished yet. Before asking the teams and developers to start following the new process, identify some less risky pilot project and use the new methodology. Keep on tuning the documented process with any improvements identified. Share the results with the developers.
13. Hand-it-over to development team: Perform training sessions; while planning the project work consider any extra overheads due to new process., have someone takes the ownership of the process and monitoring closely in the initial months to identify any issues and help the development teams.
See you next time.
