Best way to ensure processes are followed
We’re constantly tweaking and improving our processes at work when we see an opportunity to grow. We leverage Sharepoint a lot because its readily available and easy to setup. We have policies around how we work on projects as far as how we document projects, source control, issue management, etc. with most of these policies involving Sharepoint at some level.
Our process works well – when we follow through on it. Its sometimes difficult to find the discipline to always follow the letter of the law. For instance, I may see something wrong in a project, so I’ll go and fix it, check the change in, and its done. What I should do is open a new issue, document it, and link my code checkin to the issue so we know what was done to fix the problem.
For processes to be most effective, they need to be followed by everyone on the team consistently, which can be a struggle. Its especially hard if the processes you want to implement are a pain in the ass for the developers. Consider a hypothetical scenario where in order to fix a bug you were required to walk around to every developer in your company and tell them verbally that you were fixing a bug, what you were going to do, etc. It would never happen, its such a waste of time that people would just fix the bug and get on with life.
The best process is one that can’t be circumvented. In the above scenario, I can choose to not go to every developer, I can just fix the bug. Since that policy has ways of getting around it, you run the risk of some people following it, some people who “kind of” follow it, and some people who flat out ignore the policy. Instead, if there was some way to guarantee that everyone follows the same procedures, you’ll get the most consistent results and accurate data. The way you guarantee that everyone is doing the same thing, is to latch on to something that eveyone is already doing. If there was some action that you know everyone already does and you can somehow associate your process with that action, you can ensure that everyone does it. I think the pressure point that can fulfill this requirement is your source control.
Every developer needs to checkout code from the repository, and they need to check it back in after they’ve made their changes. Its unavoidable, and everyone is already doing it. If you can inject policies into the code checkin, people have no choice but to complete the necessary actions. If you require that they’ve entered the bug or feature into your bug/feature tracking application by forcing them to put the issue number in the checkin comments, then you have a good start on getting everyone on the same page. You can even extend it past that. You could have them enter the number of hours spent, the estimated hours, etc. and by doing all this as part of a checkin, its going to get done, because it will have to, it can’t be circumvented.
I haven’t research many source control tools to see what kind of existing functionality they have in this space. I’d be willing to bet that Vault has some sort of policies that can be applied. Not sure about SVN, CVS, or Source Safe. I do know that SVN has the concept of hooks so that you can write custom apps that intercept the checkin and do whatever you want. This is something that really interests me, so I’m going to be doing some more research to see whats currently out there. I think you could have a really streamlined, lightweight process that still generates plenty of useful project data by collecting the data on checkins.
(This entire post assumes that you embrace a process-driven environment, which I believe is not advocated by some of the agile/scrum community, I think they focus more on the people rather than the process, correct me if I’m wrong here.)
Anonymous said,
Wrote on April 23, 2006 @ 7:52 am
Anonymous said,
Wrote on April 23, 2006 @ 11:24 am
Funny, this is exactly the sales pitch that Visual Studio Team System offers… so thats what I assumed you were leading up to. But then you never mentioned it. There is a “checkin policy” which is fully customizable. Mercifully, you can always check a box to “violate” the policy when necessary. The process violation is recorded (so it can be reported on) - but allows you to get stuff done without the tool getting in your way, under exceptional circumstances.
Of course, the more data you ask for (you suggested time spent, etc) the less likely it will be completed accurately. Just because people have to jump through hoops to get their work done, doesn’t mean they are going to automatically feel that those hoops are important and should be taken seriously. You will likely end up with a big “garbage in, garbage out” scenario. (Which leads to the “people over process” philosophy…)
Anonymous said,
Wrote on April 23, 2006 @ 11:31 am
For CVS, there’s a utility called CVSCop on sourceforge that verifies that your check-in comments meet certain criteria. We use this along with a program called CVSTrac which is a bug tracking system with a wiki that ties into CVS and uses the comments to tie tickets to checkins. Works great! All check ins must be associated with one or more bug tickets or the check in fails.
For SVN there’s a similar utility called Trac for the bug tracking system/wiki tied to source control. I assume there’s something similar to CVSCop for SVN but I don’t use SVN yet so I’m not sure.
breichelt said,
Wrote on April 23, 2006 @ 11:33 am
Joshua, I had heard about the feature in VSTS, which is what spurred my thoughts. You make a great point about requiring too much info from people checking code in, if they need to fill out a form with 15 fields, its still not gonna happen. I am looking for something that needs to ask for the minimum amount of data, while still providing value.
As an aside, I’m not sure what I think of VSTS just yet. All the features seem really cool, but what if theres one aspect of it that you don’t like? I bet you can’t really swap out their source control for subversion. By relying on a single tool to do EVERYTHING, you’re locked in, even if part of it sucks.
Anonymous said,
Wrote on April 23, 2006 @ 11:49 am
Manually entering issue numbers in check-in comments? Ugh. Buy or build an integrated issue tracking and source code control solution. Maybe because I work for a public company that has to pass Sarbanes/Oxley audits, and has over 20 developers, I just can’t see ever going back to the manual world.
I love having a system where a developer goes to check out a file and a window pops up asking what task he’s working on. He selects it from his assigned list or clicks New and enters a description for a new task. When he checks in the file it’s automatically associated to that task. I can look at an issue in the issue tracking app and see all the changes made for it. I can look at a file in the source control app and see all changes, who did them, when, and for what task. No manual linking of code to tasks, no manual linking of tasks to code. And when the auditors visit the R&D group, we have the answers that make them go away quickly and let us get on with creating our products.
Rational ClearCase/ClearQuest is the gold standard in this area. Telelogic also has it, but it’s more cumbersome for developers. I haven’t played with MS Team System yet, but I assume it’s got similar capabilities since they want to compete with Rational. All these solutions are expensive, but the bigger your organization gets, the more productivity gain they give you.
breichelt said,
Wrote on April 23, 2006 @ 1:08 pm
C, I didn’t mean that you should be looking up ID numbers in the db just to put the issue number in your comments
The interface for selecting the issue that you want to associate the checkin with should be advanced, so that you can pick from available issues, like your situation. I like that you make the selection on checkOUT, rather than checkin, and it remembers your selection, thats pretty cool. The expense involved with getting Rational ClearCase is pretty daunting however.
Anonymous said,
Wrote on April 24, 2006 @ 7:16 pm
Not that I speak for the Agile movement, but going Agile does usually entail processes. Those processes aren’t necessarily dictated by any agile process.
You are totally correct to assume that Agile values people over processes however. So, to answer the question “What is the best way to ensure processes are followed?” an Agile advocate might question whether your processes are really valuable and efficient if people don’t follow them.
Good processes should have obvious value, and if you’re team understands them they will not just follow, but depend on them day in and day out. You shouldn’t mandate that your team’s code needs to pass a fitness check before check-in, they should tell you that the fitness check should be automated by source control to save them time.
Personally, I really like that approach, but it isn’t cheap. It takes a lot of work to find processes that work in your organization.
Anonymous said,
Wrote on April 25, 2006 @ 4:37 pm
There are definitely processes within Agile and Scrum. The idea is to get the client a high-quality working product as soon as possible and by using people-centric processes, you accomplish that goal. A few books to look at:
Slack by Tom DeMarco
http://www.amazon.com/gp/product/0767907698/sr=8-1/qid=1145997311/ref=pd_bbs_1/103-4258705-7138236?%5Fencoding=UTF8
Ken Schwaber’s book
http://www.amazon.com/gp/product/073561993X/qid=1145997339/sr=1-1/ref=sr_1_1/103-4258705-7138236?s=books&v=glance&n=283155
Other Agile/Scrum Sites:
www.danube.com
www.agilethinking.com
www.controlchaos.com
Good luck!