• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (7)

1 localhost commented Permalink

Should that be:<div>&nbsp;</div> "Sadly, we've been told for decades now that repeatable PROCESS is critical to our success in IT, yet when you step back and think about that's really a reflection of a bureaucratic approach. On the other hand, a focus on repeatable results is a reflection of a more disciplined approach."<div>&nbsp;</div> Anyway, I have to get back to my detailed documentation of every method in the application, mandated by my companies repeatable process. That will ensure the repeatable result of delivering documentation rather than working software !<div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>

2 localhost commented Permalink

This kind of thinking comes from production-line environments where repeatable process has a good chance of generating repeatable results.<div>&nbsp;</div> One key differentiator for software development is that most development environments have sufficient flux and complexity to introduce constant changes that must be accommodated.<div>&nbsp;</div> Another is that software development is not about repeating the same thing. By definition it is about creating something new and different in the product, often by the introduction of completely new features.<div>&nbsp;</div> Therefore, any robust development process is going to thrive on change and boldly go where no code has gone before.

3 localhost commented Permalink

Pete, thanks for the catch on the error. Good luck with the docs. I'm sure that everyone who follows you will not only read them but also trust the information in them ;-) You might want to share http://www.agilemodeling.com/essays/agileDocumentation.htm#CRUFT with your managers.<div>&nbsp;</div> Also, thanks to a couple of others who also sent me private emails.

4 localhost commented Trackback

I think this pattern exists to some extent in every one of the major Canadian banks. I just finished reviewing a design document for the creation of a configuration management database for a major bank.<div>&nbsp;</div> The document was supposed to outline how the product would be configured to support the various technology assets within the bank.<div>&nbsp;</div> The team was forced by the "SDLC review board" to use a info path-based template that had completely inappropriate sections like detailed use cases, detailed data diagrams, requirements for sequence diagrams, etc.<div>&nbsp;</div> The team explained they had to use this horrible template and fill out all the sections in order for the project in order to pass the "initial design" phase.<div>&nbsp;</div> When they went through the review with the client, the process literally involved "did you fill out section x, okay did you fill out section Y.,..."<div>&nbsp;</div> As you have stated in many of your earlier writings, one of the biggest issues with these massive bureaucracies is that many of them are staffed by people who have the remotest knowledge of the subject matter in question...<div>&nbsp;</div>

5 localhost commented Trackback

Not to be a stickler, but my understanding is that the process is "get to work on time" but that the procedure would be the route you take.<div>&nbsp;</div> At least that's how my PMI buddies explain it to me.

6 AlbertoSampaio commented Permalink

Organizations define processes and try to follow them in order to repeat successes, that is, good results. That is the true origin of process improvement initiatives. Of course there are organizations that do no do that, but in this case they are wrongly following the process perspective.

7 WayneYan commented Permalink

Repeatable Process in the absence of a Process Improvement Framework is more the issuse. This is where the bureaucratic non-value adding activities creep in. In terms of the CMMI model repeatable process is really only the first step. However, most organizations to not get through to maturity level 5 where process improvment is supposed to kick in. I think it is unrealistic to require imperical measures first before any kind of improvment can take place. Perhaps combining a simpler methodology like Scrum or Kaizen quality circles together with process is the answer to not only repeatable results, but improving results.

Add a Comment Add a Comment