Despite the fact that I have deliberately taken a couple of months off since the end of my last assignment I’ve been keeping very busy. I’ll be glad when Christmas comes and I can leave the laptop switched off for a few days.
In addition to finishing up a couple of personal projects (the book, various patterns papers and other stuff) and giving some talks and briefings I have been involved in an attempted rescue. OK, nobody was in real danger this was more a corporate rescue.
I drafted a turn-around plan for a .com in trouble. For a while it looked like the plan would be adopted but now it looks doubtful. Seem the management have gone off the idea. Shame but so be it, it was interesting to analyse the company and make suggestions.
I have also been busy working on my own product offerings. I have today revised my website to make it clearer what I do. In addition to regrouping some of my services (training, briefings and workshops) I’ve also created a Software Development Practice Review product - SDPR for short.
I’m particularly proud of this SDPR. It has taken a few weeks to bring together the framework but the basic idea is simple. I want to be able to visit a development organization (a team or department or such) and evaluate their software practices. Notice I say practices, not processes. This is deliberate. Most of the other reviews I’ve looked at consider processes, I think practices are more important because it shows you what people are actually doing, not what they are supposed to be doing.
The framework behind the SDPR starts by considering teams (size, structure, experience, etc.), the management of the teams, how the business communicates its need to the teams and how risk is managed. After this it turns to what the team is doing, technology, routines, practices, release management, testing and a little bit about processes. Finally the framework considers what happens after a software release and how the team learns.
From this review I can create a report designed to seed team improvement and stimulate the various members to try new practices and ideas. The second key difference I see with many other types of review is that this review is intended to help the teams improve, it is not intended to measure them on ‘pass/fail’ or suitability to undertake work. It is there to help improvement.
Overall I get very excited about this review. I hear of so many development teams which could do better, some of which are almost dysfunctional and yet fixing them wouldn’t be very difficult. Hopefully this is a tool to do just this.
I’m now talking to some people about trying the framework out in January. If you think your team could benefit from this review, or you know someone who would find it useful please get in touch.
In addition to finishing up a couple of personal projects (the book, various patterns papers and other stuff) and giving some talks and briefings I have been involved in an attempted rescue. OK, nobody was in real danger this was more a corporate rescue.
I drafted a turn-around plan for a .com in trouble. For a while it looked like the plan would be adopted but now it looks doubtful. Seem the management have gone off the idea. Shame but so be it, it was interesting to analyse the company and make suggestions.
I have also been busy working on my own product offerings. I have today revised my website to make it clearer what I do. In addition to regrouping some of my services (training, briefings and workshops) I’ve also created a Software Development Practice Review product - SDPR for short.
I’m particularly proud of this SDPR. It has taken a few weeks to bring together the framework but the basic idea is simple. I want to be able to visit a development organization (a team or department or such) and evaluate their software practices. Notice I say practices, not processes. This is deliberate. Most of the other reviews I’ve looked at consider processes, I think practices are more important because it shows you what people are actually doing, not what they are supposed to be doing.
The framework behind the SDPR starts by considering teams (size, structure, experience, etc.), the management of the teams, how the business communicates its need to the teams and how risk is managed. After this it turns to what the team is doing, technology, routines, practices, release management, testing and a little bit about processes. Finally the framework considers what happens after a software release and how the team learns.
From this review I can create a report designed to seed team improvement and stimulate the various members to try new practices and ideas. The second key difference I see with many other types of review is that this review is intended to help the teams improve, it is not intended to measure them on ‘pass/fail’ or suitability to undertake work. It is there to help improvement.
Overall I get very excited about this review. I hear of so many development teams which could do better, some of which are almost dysfunctional and yet fixing them wouldn’t be very difficult. Hopefully this is a tool to do just this.
I’m now talking to some people about trying the framework out in January. If you think your team could benefit from this review, or you know someone who would find it useful please get in touch.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.