One of the issues I've been faced with is applying a hard and fast set of standards to a team of developers, whilst maintaining a balance of getting work out the door.
I can't just wade into the team with new process and Quality Assurance routines and not expect there to be a few bumps in the road.
I have already documented the standards that I'm applying, so this is more a discussion on how to actually apply them, rather than the standards themselves.
SoftwareMy first point of action for applying standards to the team was to buy the software they require to ensure that when they release projects for QA they have actually tested them themselves.
This performs two roles, firstly it helps establish the benchmarks of what the standards are, as the software set chosen helps you meet those standards.
Secondly it allows the team members plenty of opportunity to actually ensure that they have the tools that enable them to do the job correctly. This is even more important when dealing with multiple people in a team as there really needs to be a level playing field.
TrainingAfter the team has the software there will be a certain learning curve in being able to use it effectively. I see this as quite a short curve as they are all software development types of one for or another, being developers or designers etc.
The next form of training is really around applying the standards into the existing working practices. I think it is unreasonable to expect people to immediately change how they work, there will be a certain period of adjustment before you can really see the change.
ProcessI'm working on the process change happening over a fixed period. I prefer the idea that I can set a landmark date where everyone will have adopted the software and become proficient in it.
The next step from there is to set a second date where everyone has been trained in the new standards, they can recognise them and apply them. At this point they can be enforced as everyone has the tools and the knowledge to implement them.
Only now can the QA process fully step in at the end and perform any process checks against the projects leaving the team.
Thoughts?This is how I see a process improvement system being applied to an existing team of designers / developers. I think it gives people the opportunity to adapt to new ways of working by using new tools and knowledge. Once you have given people these tools they really have no excuse to not produce work that meets defined standards.
But how would you approach the same scenario? Is there something you'd do differently?