This is the mark of a good project according to some friends I was out with the other evening. They are not slackers in the bad sense, though they are slackers as is evident from their credo that is the title of this entry. I would consider it a coup in the extreme to get any of these guys on a project with me; they have all been part of many very successful projects.
As I left them that evening I did not think much about the credo, other than the fact that I liked it and followed it when I could. I vaguely thought that these were people who were really good at what they do so can afford to adopt a credo like that. For the rest of us, software delivery is something of a grind. But I have also been thinking recently about how to introduce change to teams that have been working in a given configuration for awhile and don’t really see any problems with what they do. After having both these things in my head for awhile it came to me that my slacker friends aren’t SO good that they could adopt a slacker credo, instead by ASPIRING to a slacker credo they were able to hone their delivery skills to an excellent level and thereby take up some slacker activity. More precisely, I have no idea why these slackers are so good, but the rest of us could hone our delivery skills by aspiring to the slacker credo
Maybe it is worth exploring if you in fact can have a good project while arriving late, leaving early and taking a big break in between. Well in order to this, in my experience, you need a few qualities on the team.
1. There has to be trust amongst all team members. No way you can have all this time away from the keyboard if half the team don’t believe delivery is possible. They may not believe delivery is possible if they aren’t part of the decision making process and if there are not clear and constant lines of communication between all team members.
2. Team size must be small. You can’t have a whole team involved in decision making, or constant and clear lines of communication between all team members if the size grows too big.
3. The team must be open to change and aggressively looking for ways to improve their processes. I don’t care how good you are, you can’t turn a 3 month 40 hour a week project into a 3 month 20 hour a week project unless you find ways to improve and optimize your processes on a regular basis.
Maybe there are more elements to it than that, but the three elements listed above are a start. If you don’t have those elements in your team then get them. If that still doesn’t work, I can put you in touch with my friends and maybe they can reveal the secret ingredient.
So if you can tell me that you could follow the slacker delivery credo if you chose to without putting your project at risk I would say you have a successful project and great prospects for more success in the future. If you say you could not do that, then what are you doing to get there?
Wednesday, 11 April 2007
Thursday, 22 March 2007
What's in a (role) name
I am functioning as an Iteration Manager in my current project. This is a role that is rather undefined as far as I am aware. Certainly me and my IM colleagues are still trying to figure out how best to help the team in our current role. I approach it as something between Agile Coach and Team Lead. Anyway over drinks the other evening I was cautioned not to get in the developers way by trying to help deliver stories through pairing with developers since I now have other duties. This is not the first time I received this advice and I understand the position. Curiously I have always received it from excellent technical people who operate squarely on the technical side of the team. At the same time I find suggestions in the air that I should be learning what a Project Manager does now, or I am on the track to Project Manager, or that I am now Post-Technical.
But, of course, I have a problem with this thinking. The incongruency between the ideas above and how I see things is that I am not an IM. I do an IM’s job or I operate in an IM role, or (if I can totally geek out for a sec) I can be accessed through an IM interface. But the important thing is that I can also be accessed through a Developer Interface. I could write automated tests, run a test script and help a team develop a testing strategy, and could therefore be accessed through a QA interface. I even flatter myself to think that I can write a story, create a rapport with the business and function as a BA. So sitting with a Developer for a couple of hours to work on a Story card is not a risky concept as I see it, so long as I am responsible and don’t let my IM responsibilities keep me and my pair from concentrating on the dev task at hand.
So that was the bit about me and my problems.
I don’t think I am special in some way that allows me to function in multiple roles. But I do think plenty of people and HR departments are happy to confuse person and role. Imagine for a second how much better a developer could provide business value or operate as part of a cross discipline team if he had spent six months working as a BA at some time in the past. I think the gains could be significant to team productivity. I also think the cost of this training need not be too high. On the teams I usually operate in at ThoughtWorks a developer and BA are already expected to work quite closely during the course of an iteration, therefore there is an appreciation of the specifics of their job already. To walk a few miles in their shoes could be a great way to further forge teams into business value machines. Of course BA and Developer switching is standing in for role switching in general. There are deep areas of a discipline that won’t be picked up by a six month stint, but the suggestion is not that we can all be an expert at everything only that we can operate in a given role when necessary and better understand the perspective of other roles.
So what would be so bad about switching roles for awhile?
But, of course, I have a problem with this thinking. The incongruency between the ideas above and how I see things is that I am not an IM. I do an IM’s job or I operate in an IM role, or (if I can totally geek out for a sec) I can be accessed through an IM interface. But the important thing is that I can also be accessed through a Developer Interface. I could write automated tests, run a test script and help a team develop a testing strategy, and could therefore be accessed through a QA interface. I even flatter myself to think that I can write a story, create a rapport with the business and function as a BA. So sitting with a Developer for a couple of hours to work on a Story card is not a risky concept as I see it, so long as I am responsible and don’t let my IM responsibilities keep me and my pair from concentrating on the dev task at hand.
So that was the bit about me and my problems.
I don’t think I am special in some way that allows me to function in multiple roles. But I do think plenty of people and HR departments are happy to confuse person and role. Imagine for a second how much better a developer could provide business value or operate as part of a cross discipline team if he had spent six months working as a BA at some time in the past. I think the gains could be significant to team productivity. I also think the cost of this training need not be too high. On the teams I usually operate in at ThoughtWorks a developer and BA are already expected to work quite closely during the course of an iteration, therefore there is an appreciation of the specifics of their job already. To walk a few miles in their shoes could be a great way to further forge teams into business value machines. Of course BA and Developer switching is standing in for role switching in general. There are deep areas of a discipline that won’t be picked up by a six month stint, but the suggestion is not that we can all be an expert at everything only that we can operate in a given role when necessary and better understand the perspective of other roles.
So what would be so bad about switching roles for awhile?
Monday, 19 March 2007
Are you doing DDD? or Do you think or hope you are doing DDD? or What is DDD?
Though it has died down a bit now there has recently been a fair amount of talk about dogmatism and Agile. Though I did not see anyone mention the irony of dogmatic agilists, it is an amusing concept. Anyway the only way I can envision considering yourself agile but being dogmatic is to not really understand what Agile is about. Well I have seen a similar phenomena with DDD(Domain Driven Design). It used to be most people who understood the words Domain Driven Design would respond to the topic with “yeah, I need to read that book”. Now, in my small world, many people say “yeah, we do that here”, or “we strive for ubiquitous language”. However, I have actually never spoken with anyone on a project with me who has read the book when the topic first comes up, and I am only aware of one colleague who has read it after we began discussing it (good on ya mate).
I have heard it said that the book is long and difficult (i.e. boring). Personally, I find Eric’s DDD book(http://domaindrivendesign.org/books/) kind of like the Lord of the Rings of software books, in terms of readability. I have read it 2 ½ times since it came out 4 years ago, versus 10-15 times for LotR since I was 12. I find it compelling and full of examples that I can translate into real world situations I have come across, that part is not similar to LotR.
In many projects I have been involved with, I have seen some level of recognition of the benefits to be had from DDD, and a desire to do DDD. But these same projects happily trod over the fundamental idea of ubiquitous language. In speech we try to use the same words, but in code divergence from the language is immediate and continues. The nouns may remain but the verbs and constraints get removed from the domain. In addition new nouns and verbs crop up in the domain code that are not translatable to the business domain or in violation of the business domain. Examples would include code with setters for Database Ids on domain objects or account objects that have setters on the account owner, when the business would not allow an account to change owners. These are examples of letting your domain do things that the business does not do, or extra things that have nothing to do with the business. On the other hand many other “domain” objects have no behavior, maybe the occasional validation method, or an equals override, but absolutely lacking in many fundamental domain concepts. If you have to give your domain object to a ValidationHelper to tell you if a “domain” object is in an appropriate state, yet the business rules of validation are dependent on the state of the domain object then your code does not use ubiquitous language. If you need to give an account to a PerformanceCalculator to tell you its performance over time, yet performance is a property of an account in the business domain, then your code does not use a ubiquitous language. If a “domain” object exposes information about a Database Id, or allows you to change (business) immutable properties because your persistence framework requires setters then your code does not use a ubiquitous language. Of course it may not be bad that your code deviates from ubiquitous language, but you should be aware of the fact and be able to justify it.
If you can’t justify it then you can fix it. My recommended way is to make sure you have read the book and start wrapping your behaviour in interfaces that are business readable(prerequisite is favoring a rich domain over an anaemic one). I would suggest that a good way to judge how ubiquitous your language is is to see how much sense your code makes to a business person. On that note, JBehave has recently been released, which looks to be an excellent tool to get the language of the business into your code. JBehave is about writing tests(behaviours, for BDDists) in the language of the business, but I believe it will lead the whole team to think more in the language of the business domain and that must lead to more domain code being readable in the business language. Of course you may decide that DDD is not for you and your team. But if you don’t read the book then you can’t really know. So my advice is read the book. Even if you don’t like the ideas it will give you a perspective on how developers can make the code easier to understand in the terms of the business.
I have heard it said that the book is long and difficult (i.e. boring). Personally, I find Eric’s DDD book(http://domaindrivendesign.org/books/) kind of like the Lord of the Rings of software books, in terms of readability. I have read it 2 ½ times since it came out 4 years ago, versus 10-15 times for LotR since I was 12. I find it compelling and full of examples that I can translate into real world situations I have come across, that part is not similar to LotR.
In many projects I have been involved with, I have seen some level of recognition of the benefits to be had from DDD, and a desire to do DDD. But these same projects happily trod over the fundamental idea of ubiquitous language. In speech we try to use the same words, but in code divergence from the language is immediate and continues. The nouns may remain but the verbs and constraints get removed from the domain. In addition new nouns and verbs crop up in the domain code that are not translatable to the business domain or in violation of the business domain. Examples would include code with setters for Database Ids on domain objects or account objects that have setters on the account owner, when the business would not allow an account to change owners. These are examples of letting your domain do things that the business does not do, or extra things that have nothing to do with the business. On the other hand many other “domain” objects have no behavior, maybe the occasional validation method, or an equals override, but absolutely lacking in many fundamental domain concepts. If you have to give your domain object to a ValidationHelper to tell you if a “domain” object is in an appropriate state, yet the business rules of validation are dependent on the state of the domain object then your code does not use ubiquitous language. If you need to give an account to a PerformanceCalculator to tell you its performance over time, yet performance is a property of an account in the business domain, then your code does not use a ubiquitous language. If a “domain” object exposes information about a Database Id, or allows you to change (business) immutable properties because your persistence framework requires setters then your code does not use a ubiquitous language. Of course it may not be bad that your code deviates from ubiquitous language, but you should be aware of the fact and be able to justify it.
If you can’t justify it then you can fix it. My recommended way is to make sure you have read the book and start wrapping your behaviour in interfaces that are business readable(prerequisite is favoring a rich domain over an anaemic one). I would suggest that a good way to judge how ubiquitous your language is is to see how much sense your code makes to a business person. On that note, JBehave has recently been released, which looks to be an excellent tool to get the language of the business into your code. JBehave is about writing tests(behaviours, for BDDists) in the language of the business, but I believe it will lead the whole team to think more in the language of the business domain and that must lead to more domain code being readable in the business language. Of course you may decide that DDD is not for you and your team. But if you don’t read the book then you can’t really know. So my advice is read the book. Even if you don’t like the ideas it will give you a perspective on how developers can make the code easier to understand in the terms of the business.
Wednesday, 28 February 2007
Why track against estimates from the iteration planning game?
I was challenged over lunch today with the statement “Release level estimates are the only ones that matter” by a couple of guys on my team. In our context release level estimates are estimates that are made at the inception of a project. Unfortunately for me I had my Release level sunglasses on and could not see a very good argument against this idea at the time. The basic premise was that the business wants the project delivered so delivery estimates made after project inception are meaningless to the business. We have a project plan and our goal is to follow the plan.
I offered that estimates made at iteration planning games are more accurate and could highlight problems with estimates, or assumptions made at the project inception meetings. While I believe that is true, it did not look like a very powerful argument to me and I don’t think it convinced them of much either. Then, later I found my Business Value glasses and started to reconnect the dots that construct a better argument for focusing on the iteration and related estimates. These glasses come free with a viewing of http://video.google.com/videoplay?docid=-5105910452864283694&q=google+engEDU (offer not valid if you don’t drink the kool-aid).
The basic problem with the project plan that I can’t believe I forgot is that it, like the rest of us, is only born to die. Faith in a project plan assumes that there is solid ground from which you can measure things. Unfortunately, as Einstein tells us, you can only ever measure something in relation to something else and even then only at a certain point in time. There is no solid ground from which to make measurements that remain constant over time. The only constant is business satisfaction. So the perfect business plan on March 1, will be something less than perfect by April 1 if not before, at some level of detail.
The moment two key business people get together and come up with a better way to do something, and that results in a card change, you have deviance from the project plan. From that moment on estimates as to how long it will take to get to the, now deprecated, plan objectives are measures towards sub optimal business value. If you have a bunch of smart people doing your software delivery like I have on my team, and strong connections with smart business people (they sit in the same room with us and attend the stand-up), then innovation starts happening almost immediately. The more it happens the more deviation develops between delivering the project plan and delivering optimal business value. When deviation happens that looks bad to a static plan and to people managing to a static plan, but if it is the result of innovation it will look good to the relevant parts of the business and it should then feel good to an empowered delivery team. Iterations can acknowledge these events as new stories that the business deems worthy (added value) or increased velocity (decreased cost), but a static project plan only sees them as deviation.
What do you do with tech debt cards (if you have them), or bugs, or any other sneaky time consuming task that has no place in a project plan? If you are monitoring team progress via iteration work you will recognize and estimate these tasks. Any problems they are causing will then show up on your radar. A well-run team will look for ways to make this work visible to the business or find ways to remove the need for this work. Hopefully time on tech debt and bugs can be reduced to the point they will become non-issues. By checking velocity by project level stories you don’t see the bugs and tech debt. You see slow velocity but no reason why. By tracking at the iteration level these tasks can be estimated, tracked and recognized as sources of scope creep or the result of bad processes that need to be changed.
So tracking velocity against iteration estimates tells you your team’s potential to deliver business value based on the needs of today, velocity tracked against release level estimates only tells you how well you are progressing along a track that is a sub optimal path to business value, though it may have been perfect back in January, six months ago, or whenever your project began.
I am sure I am forgetting some vital benefit of the old Project plan , so feel free to speak up and defend it.
I offered that estimates made at iteration planning games are more accurate and could highlight problems with estimates, or assumptions made at the project inception meetings. While I believe that is true, it did not look like a very powerful argument to me and I don’t think it convinced them of much either. Then, later I found my Business Value glasses and started to reconnect the dots that construct a better argument for focusing on the iteration and related estimates. These glasses come free with a viewing of http://video.google.com/videoplay?docid=-5105910452864283694&q=google+engEDU (offer not valid if you don’t drink the kool-aid).
The basic problem with the project plan that I can’t believe I forgot is that it, like the rest of us, is only born to die. Faith in a project plan assumes that there is solid ground from which you can measure things. Unfortunately, as Einstein tells us, you can only ever measure something in relation to something else and even then only at a certain point in time. There is no solid ground from which to make measurements that remain constant over time. The only constant is business satisfaction. So the perfect business plan on March 1, will be something less than perfect by April 1 if not before, at some level of detail.
The moment two key business people get together and come up with a better way to do something, and that results in a card change, you have deviance from the project plan. From that moment on estimates as to how long it will take to get to the, now deprecated, plan objectives are measures towards sub optimal business value. If you have a bunch of smart people doing your software delivery like I have on my team, and strong connections with smart business people (they sit in the same room with us and attend the stand-up), then innovation starts happening almost immediately. The more it happens the more deviation develops between delivering the project plan and delivering optimal business value. When deviation happens that looks bad to a static plan and to people managing to a static plan, but if it is the result of innovation it will look good to the relevant parts of the business and it should then feel good to an empowered delivery team. Iterations can acknowledge these events as new stories that the business deems worthy (added value) or increased velocity (decreased cost), but a static project plan only sees them as deviation.
What do you do with tech debt cards (if you have them), or bugs, or any other sneaky time consuming task that has no place in a project plan? If you are monitoring team progress via iteration work you will recognize and estimate these tasks. Any problems they are causing will then show up on your radar. A well-run team will look for ways to make this work visible to the business or find ways to remove the need for this work. Hopefully time on tech debt and bugs can be reduced to the point they will become non-issues. By checking velocity by project level stories you don’t see the bugs and tech debt. You see slow velocity but no reason why. By tracking at the iteration level these tasks can be estimated, tracked and recognized as sources of scope creep or the result of bad processes that need to be changed.
So tracking velocity against iteration estimates tells you your team’s potential to deliver business value based on the needs of today, velocity tracked against release level estimates only tells you how well you are progressing along a track that is a sub optimal path to business value, though it may have been perfect back in January, six months ago, or whenever your project began.
I am sure I am forgetting some vital benefit of the old Project plan , so feel free to speak up and defend it.
Subscribe to:
Posts (Atom)