|
Feb 02
2010
|
We work in silos and it hurts the very organizations that pay us.Posted by: Julian Simpson in MyBlog Tagged in: Untagged
  |
 |
Siloes are for farmers to store grain in. But we've adapted siloes in our organizations. Check this workflow (from a medium size UK company) out:
- Developer writes a feature.
- Developer raises a change request.
- The Change Control board meets, discusses the change, and approves it.
- Developer "hands over' the code by checking into a well-known place in Perforce.
- Release manager gets the change, verifies that all the change information is complete, and attempts to deploy the change to an integration test environment. [let's assume that it works, otherwise your eyes will glaze over]
- A tester (paid by the day) will verify that the functionality works.
- Steps 5 and 6 are repeated in a formal test environment, and then UAT.
- Release manager hands over the code in a well-known place in a filesystem for the systems administrator to deploy.
- Systems administrator deploys the code (assuming that the test environments are realistic and the instructions are up to day).
And the change? Revoking the rights of temporary staff to order lunch on the company intranet. Each handover introduces waste in the form of waiting, miscommunication, errors and plain old overhead. Is this appropriate? I think not. But for millions of us, it's just the way we work. I'd rather the tester and the developer collaborate to write the code and it's automated tests, allow an automated deploy to test environments, and use the same process to get the code into production.
Sadly, most of us are a long way off. So we inhabit the silos.
Set as favorite
Bookmark
Email this
Hits: 1122
Trackback(0)
TrackBack URI for this entryComments (3)
Subscribe to this comment's feed
Julian Simpson
said:
|
... Thanks for commenting, Salle. I think I most agree with your last comment: "The processes in place should at the very least force the silos to interface and integrate." Every project needs to have some appropriate level of governance, including configuration management. You may not need a team or department to provide this, but you need to have processes in place and some system to highlight when things stray from that path. In an ideal world I'd like to think that the team would be mature enough to do what needs to be done to comply with all requirements - business, operational, and risk-related (which to me is what CM is all about - managing risk around the release process). I'm still waiting to work with that team though   |
Salle
said:
 |
... I agree in this isolated example it appears as wasteful overkill... and there are many other such examples that could be cited. But if you do not follow the process for one change/deployment, then where do you draw the line? The Change Control board could approve such menial changes to follow a lighter process - but all changes should come through the release management area for tracking, auditing, and scheduling purposes. An automated deploy should still require approval prior to being executed in most cases, especially once it is being deployed to an environment other than development. One problem I have seen with the developer working directly with the tester, and promoting to production of their own accord, is a lack of standardization, communication, and documentation... which results in yet one more one-off app that is not very supportable and creates more work over its lifecycle. They end up working in their own silo. The processes in place should at the very least force the silos to interface and integrate. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
