Here's an email from one of our consultants, and my response (edited for anonymity and to removing the internal cursing!).
So, our product manager asked me today whether we could (just) let quality slide for a while, in the interests of getting stuff done faster.
I gibbered and muttered for a bit, and then gave an answer which amounted to "I don't know how to do that". Which is true; having personally experienced the benefits of practices like pairing, automated tests, and refactoring, and having done things that way exclusively for a quite a while, I'm not sure I know HOW to do it the old way.
I'm not sure that the his concern has gone away, though. He describes his experience as "mostly startup-like stuff", throwing stuff together quickly, and potentially throwing in away a few short years later. He's certainly never worked in an agile environment before, and is doubtful about the value of some of our practices.
Any advice?
As with most companies with a history of software development, there are people who have been burned by non-agile development, and people who haven't had that experience, and they have very different perceptions.
Here are some principles:
1) The customer is in control of the quality sliders for a project. We (IT, not just Cogent) are a service provider who give advice and recommendations, and then act on the instructions/direction of the business.
2) If the customer asks us to do something we (Cogent) fundamentally disagree with, we tell them that we are not the right group to provide that service and we quietly, respectfully disengage. Think of a surgeon who was told to perform operations without sterilisation, and that someone else would deal with the infection later.
3) There certainly are times when "not doing things the right way" is appropriate. I wrote the first cuts of Cogent Times with no test cases, because I didn't know if it would get any traction (i.e. be useful enough for people to use it). I don't regret it, and I would do it that way again. Now I'm adding test cases incrementally. When Runway was only developed by Simon it didn't have tests either - we demonstrated that this didn't scale. Kent's blog on the Flight of a Startup describes this well.
4) I think it's important to understand timeframes though. I believe that letting (internal) quality slide for a while will get stuff done faster for a few weeks. Other people seem to think that it will let them go faster for months or years. I disagree. Put simply, dropping quality won't get things done faster. We have the courage of our convictions here - we use these practices when we spend our own money on our own applications, when we really, truly, want to go as fast as we can.
5) The impact of lower (internal) quality is exacerbated by:
number of people working on the application
quality of the people working on the application
size of the application
level of understanding of the problem domain
level of change in requirements
flexibility of the technology stack
tolerance for defects in production
If your application is being built in a modern language, by one skilled person who is familiar with the product domain, working with people who know what they want and can describe it in detail without hesitation, false starts or iterations, and no one loses any money (or lives) if there are production defects, then what we do is definitely overkill. I've yet to see an environment that matches this description.
Having said all that, in the bigger picture the product manager isn't necessarily the person who makes the decisions on where the quality sliders are. Those are frequently decisions that need to be made at a higher level as they affect the total life cycle cost of the application, and the product manager is only responsible for the development part. This is the classic breakdown mode of process change - the people who bear the cost of the process change are not the people who reap the benefits of the product change. Producing a stable, defect free application that can be extended isn't necessarily in the product manager's interest, though it may very well be in the company's overall interest, especially when funding is allocated per project rather than per product. I present that argument mostly for completeness, since I think that the payback period of our practices is short enough that they're in the product manager's interest as well.
Things get even worse when the organisation funds work as "projects" rather than investing in "products". In these situations the value of feedback is reduced (since success is judged on the delivery of the promised features) and the focus is on the short term (the delivery phase for those features).
However it's also fair for the customer (and I mean the big-picture customer, not just the product manager) to suggest experiments - a good question in those situations is what will be measured to determine if things are better, and better for who? You need all the stakeholders involved in these discussions, not just the product owners.
Also bear in mind that we are not the only people to say these kinds of things. I believe part of what you're seeing is descent into the "easiest" possible implementation of Scrum. Here's what they're implicitly asking for:
"To be able to change their mind on requirements each iteration, and to obtain the benefits of this flexibility, without either performing enough up-front analysis to understand the fundamentals of the problem domain, or making any investment in the technical robustness of the application to support change"
This is very appealing from a business perspective, but it's an illusion. Jeff Sutherland has said he's never seen a hyper-productive Scrum team that didn't use the XP technical practices. Martin Fowler has written on what he calls Flaccid Scrum. The trend is to no longer consider the practices you mention as "agile", but simply "contemporary" - things you should be doing without a second thought.
So my first response to these kinds of suggestions (actually, my second, after I stop cursing) is that if the proposals would make things go faster then we'd happily implement them. But they won't. If I'm challenged further then I would ask them to find someone else on the technical staff who believe that the proposals will make things go faster, and then I'd step aside for them.
Seriously, hospital administrators don't tell surgeons how to maintain hygiene and where to cut. The customer can do whatever they want - we don't have to do it for them.
Not sure if that helps or not.
Steve
Tuesday, December 8, 2009
Monday, October 19, 2009
Roles in a self-organising team
One of the things that I'm asked to do fairly regularly is define the roles for an agile team, be it for Scrum, XP or some other flavour of agile. I usually end up doing this based on required skills, but my first impulse is to refuse, because I don't believe that a self-organising team actually has roles and I think that defined roles limit both the individual and the team. Let me examine that point before I explain how I do go about defining roles and why.
There is one role on a self-organising team - team member. The responsibility of that role is to bring all their skills to bear on the team's problems and organise their contributions to maximise the team's effectiveness.
When something needs to be done on an agile team everyone on the team should be able to see it, and in many cases it will be obvious which individual or individuals are the best suited to getting it done. The simplest approach is to allocate tasks based on skills, but the team might decide to use other criteria as well - they may need to grow their capacity in some area and decide to give the task to someone with less experience to give that person some practice; they may have limited capacity and be forced to give the task to someone who needs to learn the required skill, usually with mentoring from someone on the team. There will also be team-specific and project-specific reasons for not allocating tasks based simply on skill set. The important thing is that the reasons are well-articulated, and that the team member accepts responsibility for the task rather than having it arbitrarily assigned to them.
Although multi-skilled teams are normal and effective, provided the team is dedicated to achieving a result, has sufficient time and is reasonably self-aware you can imagine any arbitrary skills starting point. We could take a team that consisted entirely of testers and give them some work to do. The first tasks they encountered would require some analysis, so someone from the team would need to do this. They wouldn't complete the analysis as quickly or to the same quality as someone with the relevant experience, and they might not enjoy it as much. They might also need to get outside expertise (training and/or mentoring), but they would get through the work eventually. The team might find someone who wanted to grow into this role and make them the primary analyst, or they might decide that no one enjoys it and the role should be rotated through the team (this is probably less efficient, but it explicitly ranks satisfaction and retention ahead of efficiency). The same pattern can be repeated with development and anything else the team needs to get done.
Don't get me wrong - this is clearly a slow path to success and I wouldn't recommend it, but it is a valid approach. It's a contrast to the behaviour I see more often, which is "I can't do X, because I'm a Y". "Can't" is definitely the wrong word - finding the right word will determine how you respond to this assertion. If the person is really saying "I don't like doing X" then keep the assignment short and try to find some other way to make it attractive. If they're saying "I don't know how to do X", then they need training, guidance and support. If they're saying " I won't do X" then they probably shouldn't be part of the team.
That's why I don't like roles - why do I provide descriptions of roles and responsibilities? It's because I would rather start with a team with diverse skills than spend a lot of time developing the same skills, and most organisations understand that as a request for roles. I also appreciate that most people have gravitated towards a role that suits their preferences and skills, and asking people to move into other areas requires both time and motivation that we usually don't have a the beginning of project.
My hope is that companies that go to the trouble of assembling multi-discipline teams will also recognise the benefits of keeping those teams together for long periods of time. Time is the essential ingredient to building role-independent teams - it helps build trust between the team members, it lets people experiment and learn, and it gives the team opportunities to get feedback on different approaches to task assignment.
There is one role on a self-organising team - team member. The responsibility of that role is to bring all their skills to bear on the team's problems and organise their contributions to maximise the team's effectiveness.
When something needs to be done on an agile team everyone on the team should be able to see it, and in many cases it will be obvious which individual or individuals are the best suited to getting it done. The simplest approach is to allocate tasks based on skills, but the team might decide to use other criteria as well - they may need to grow their capacity in some area and decide to give the task to someone with less experience to give that person some practice; they may have limited capacity and be forced to give the task to someone who needs to learn the required skill, usually with mentoring from someone on the team. There will also be team-specific and project-specific reasons for not allocating tasks based simply on skill set. The important thing is that the reasons are well-articulated, and that the team member accepts responsibility for the task rather than having it arbitrarily assigned to them.
Although multi-skilled teams are normal and effective, provided the team is dedicated to achieving a result, has sufficient time and is reasonably self-aware you can imagine any arbitrary skills starting point. We could take a team that consisted entirely of testers and give them some work to do. The first tasks they encountered would require some analysis, so someone from the team would need to do this. They wouldn't complete the analysis as quickly or to the same quality as someone with the relevant experience, and they might not enjoy it as much. They might also need to get outside expertise (training and/or mentoring), but they would get through the work eventually. The team might find someone who wanted to grow into this role and make them the primary analyst, or they might decide that no one enjoys it and the role should be rotated through the team (this is probably less efficient, but it explicitly ranks satisfaction and retention ahead of efficiency). The same pattern can be repeated with development and anything else the team needs to get done.
Don't get me wrong - this is clearly a slow path to success and I wouldn't recommend it, but it is a valid approach. It's a contrast to the behaviour I see more often, which is "I can't do X, because I'm a Y". "Can't" is definitely the wrong word - finding the right word will determine how you respond to this assertion. If the person is really saying "I don't like doing X" then keep the assignment short and try to find some other way to make it attractive. If they're saying "I don't know how to do X", then they need training, guidance and support. If they're saying " I won't do X" then they probably shouldn't be part of the team.
That's why I don't like roles - why do I provide descriptions of roles and responsibilities? It's because I would rather start with a team with diverse skills than spend a lot of time developing the same skills, and most organisations understand that as a request for roles. I also appreciate that most people have gravitated towards a role that suits their preferences and skills, and asking people to move into other areas requires both time and motivation that we usually don't have a the beginning of project.
My hope is that companies that go to the trouble of assembling multi-discipline teams will also recognise the benefits of keeping those teams together for long periods of time. Time is the essential ingredient to building role-independent teams - it helps build trust between the team members, it lets people experiment and learn, and it gives the team opportunities to get feedback on different approaches to task assignment.
Tuesday, October 13, 2009
An interesting exchange
I wrote this in response to a customer email, but it seemed like something that I could put here:
On 14/10/2009, at 9:15 AM, ... wrote:
From: Steve
On 14/10/2009, at 9:15 AM, ... wrote:
Morning Steve,
Saw this article and thought it was interesting. http://www.javaworld.com/community/node/3530
Regards
...
From: Steve
It is interesting. I think it's hard to get the tone right when you're dismissive of agile zealots (who it's hard to agree with, almost by definition), without being dismissive of agile in general. Having been involved with agile for a long time I have a nice clear centre that tells me that agile should be adaptive, but I've also seen the problems that come from being too adaptive too early.
I totally agree that the process for one or two really talented, motivated people is different from the process you use for larger groups/applications. Alistair Cockburn has been very explicit about this in his writing about the Crystal family of methodologies, and Kent Beck has touched on the same subject from a different perspective when he wrote his blogs about "Flight of the Startup". The hard part for most of us is dispassionately looking our our team and ourselves and changing process over time. It's easy to err on the side of too much, too soon or too little, too late, but very hard to judge it just right.
On the "where's the Access of today", that's a question that we've thrown around within Cogent as well. My personal opinion, shared by some others in the company but not everyone, is that we've gone backwards over the last 10 years in productivity and our ability to deliver things quickly. Our capabilitity has increased - we can deliver bigger, more sophisticated applications - but in the process everything seems to have become harder.
I agree with the poster who mentioned the combination of Ruby on Rails and Heroku - that's the combination that I'm using for my personal projects now. I think it's the combination that's the winner - there are other frameworks that to me look more promising than RoR but with each of them I have to manage my production environment myself (for some of them even setting up a production environment is a challenge). Heroku takes care of that and make deployment as simple as possible.
On the OS X desktop MacRuby looks very promising, leveraging Inteface Builder with the power of Ruby. I don't play in the Windows space, so I don't have any idea what the possibilities are there.
...
Steve
Subscribe to:
Posts (Atom)
Posts
