I'd like to comment on something Jason Marshall posted elsewhere on this site, because the subject has been bothering me for some time - Agile processes encourage teamwork but how does the manager reconcile this with flexible working.
"I think in a real world, where people get pulled onto multiple projects, don't keep precisely the same hours, and occasionally find employment elsewhere, there's significant danger in assigning code ownership to a lone individual."
The basic problem is that events which require team working such as daily standup meetings, design sessions, reviews and check-ins, builds and integration testing, cannot be completed if all team members are not present.
If you create an environment and process which gets great benefit from teamworking, how is it possible to reconcile this with flexible working which allows developers to keep their own work hours. If a developer is out, because they haven't come in or have gone home already, this can become a bottleneck holding up other team members who are waiting to complete an important piece of work.
I'd be interested in comments from the members of this site...
David
Teams and ownership
Hi David,
Quoting your quote from Jason:
"I think in a real world, where people get pulled onto multiple projects, don't keep precisely the same hours, and occasionally find employment elsewhere, there's significant danger in assigning code ownership to a lone individual."
Obviously there are many factors at play here: different company cultures, employment contracts, etc. But I wonder where the commitment comes in all of this? If someone is in a position of responsability, there needs to be a certain level of commitment made. Putting aside class ownership for the moment, surely when any employee working on a project becomes valuable because of their contributions, knowledge and experience, then if that person leaves for another project or job, it would be disruptive no matter what?
But the second question is the rather loaded word ownership. It is a strong word, and open to misinterpretation. At the risk of trying to channel Jeff for a moment, I think perhaps he means ownership in the sense of stuardship - where you take responsability for a portion of the project, take pride in it being designed and coded properly, and looking after classes that interface to it and vice-versa. The whole 'class ownership' issue should not be construed in the exclusive sense. I can just imagine, the dev team huddled in their cubicles, strike up a conversation that develops into sheer panic:
Harvey: "Quick George, I need a new method added to Customer to retrieve their top 5 favourite restaurants. Where on Earth is Bob? He owns Customer.java doesn't he?"
George: "Why yes, Bob does own Customer.java. But - Oh no! - Bob has gone on a 2-week vacation!! We're doomed! Call the PM; we have to reschedule the whole project!"
A CP can always step in to make a change when the class owner isn't there. Or another member of the feature team; after all, that's why we work in small close-knit teams. The other team members will still know how your class works; they went to all the reviews! And of course, that's why we all use CVS too!
So I really don't see it as a problem, and in my experience it hasn't been in the past.
You mention "daily standup meetings, design sessions, reviews and check-ins, builds and integration testing, cannot be completed if all team members are not present". Well, I don't think this is necessarily the case (ie. the CP and the RM can always conspire to do a release without the other developers being present). But surely this is a universal problem: whenever one person is responsible for something and they are not present, some things may not be able to be completed. But this is nothing new, and nothing specific to softare development. In fact, feature teams, by their very nature, can mitigate some of these issues.
The issue of flexible work hours is a sticky one; flexible time is nice, but many studies have shown how productivity is increased when a team works in close collaboration. It's all about the team dynamic, communication paths, and the mentoring. So if you have a developer that turns up at 3pm and works until midnight, he might be a great coder but not such a good team player. It depends on the nature of the project, but sometimes 9-5 is best.
ciao-
::gavin - who is *not* a morning person
..antonym.org
Management 101
I don't see what any of this really has to do with Agile. The "problem" being described would apply to anything that had roles. Ok - well maybe not a 3 person XP project where the only role is Programmer
I'm not quite sure what to say other than to quote Weinberg who said that software construction is a human activity. If you can't manage a team of people to be available to do work, then I think that problem overwhelms a discussion of the finer details of process X versus process Y.
However, if this about how to deal with one or just a few people that are often late to work, or late for meetings (or don't show up for meetings) then there are some basic management things you can try.
As groundwork, you need to make use of team norms. Explicit norms help team members interact with each other, providing some basic ground rules on what all have agreed will help us be more effective, more productive. On example norm and that I *always* use is Honour Time Limits.
This can be a quite difficult norm to put in practice, especially for developers
, and I frequently get asked about implementing this norm when I'm running project management workshops or doing project management mentoring.
If you have a problem with a few individuals consistently being late for meetings and so on, you want to address this issue with them by putting it in the context of the team rather than directly addressing someone with "don't be late again."
That approach rarely works and quickly sets up the wrong kind of leader-team member relationship. Instead, put it in the context of the team. Say to the person that when you aren't on time for a previously agreed meeting it is insensitive to your fellow team members. Not only is it insensitive to them, it also communicates that you don't consider what the team was scheduled to do at that time as important enough to be there for.
People don't like to let a team down and they don't like to be seen as the only one in a team that is a constraint to its progress (for such a reason).
I've used this aproach many times over the years with good success. It appeals to the right parts of a person's character and avoids silly
schoolboy-like discussions of "don't be late again" that only serve to get you and your team member playing the wrong kind of roles.
Save those roles for when they're really needed and try this approach first.
Jeff
Industrial Relations
Jeff,
There is some great advice in your post and people will learn a lot from it. However, the issue which started the thread is more one of "industrial relations".
Consider a culture where there was no team work, just a group of individuals. The engineers get used to a world where they can come and go as they like whenever they like as long as they are seen to make up at least 40 hours per week and preferably to be in the building for 50 to 60 hours.
Management actually encourages late coming by occasionally providing "spot" rewards of stock options to those they find working evenings in the office.
Then a new line manager takes over who has to actually make these people productive. One way of doing that is to get them to work as a team and show some discipline. Some of the staff rebel against this because they see it as a loss of a perk. This is an industrial relations problem because staff feel their remuneration package has been downgraded.
The bottom line is that team work and inter-personal relations can be challenging for some developers. Agile methods have it as a prerequisite. Hence, it isn't always easy for a manager to solve these issues without taking a hard line. This requires the backing of a strong senior management chain. Sadly, I've found that lacking in parts of corporate America where I've been working. Ultimately, the meek inherit the stock options
David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers
Relevance to FDD
David,
I am not FDD literate but I am wondering how this thread or issue is relevant to FDD.
To me it appears to be a more general change management issue. There are lots of books, web resources and consultants :) that can provide advice on developing and implementing a change program or establishing effective teamwork.
David
No teamwork
What method doesn't require teamwork? I don't see this as Agile specific, let alone FDD specific. The issue that started the thread was to do with class ownership. If the issue is really industrial relations then see the post by davidbye above.
Enterprise Architecture Doesn't Matter?
TrackBack from A Day in the Life of an Enterprise Architect: Thought Leadership: