I participated in a meeting recently that was designed to create a document that would help govern the actions of the organization. I quickly felt that the goal of making a document was lost when we started debating the order of words. I wondered how we were going to get to talking about behavior when we were getting hung up on sentence structure. As I sat there thinking about the situation, I was reminded that the same kind of thing happens in Agile all too often.
People try to implement the details of Agile without thinking about the goal at hand. With Agile, or any software business methodology, the goal should be to deliver value to the customers. The customers define what is valuable, so all you have to do is behave in a way that gets the value from an idea to tangible.
I was reminded today that my writings about some of the details can sound absolute - a "My way, or the highway" sort of ring to them. Sometimes this is one hundred percent true, because the goal of a specific piece may be to evoke a response, to challenge one's current thinking. Other times my writing is about a specific situation in my work that I felt went particularly well or particularly poorly.
At the end of the day, I really have no preference for how a company operates, so long as it does operate in a way that the good employees are happy. My thinking here is that the "good employees" I mention and I can work any number of places, for any range of salaries, and any range of responsibility levels. Yet, they are going to pick to work for one company over another based on their job satisfaction.
My argument, and central theme for my writings in this blog, is that happy employees are good for customers and delivering value. I also submit for your review that Agile has a lot of practices which have a high success rate of leading to happy employees. Thank you for your readership, I look forward to using this new feedback to increase the clarity of what is important when I write in the future.
Monday, February 9, 2009
Tuesday, January 13, 2009
Generalist Myth
I consider myself a generalist. I like to think I have a layered understanding of a lot of technology and how those pieces connect to each other. I am the kind of guy when an interviewer says "So I see you know ASP.Net, how's your HTML?", I kinda cock my head to the side like a dog and say "Well, it's really good.", because to me, one lends itself to the other. I'm a better C# web app developer because I'm also skilled at HTML. Similarly, I also write better HTML because of my experience working with OOP.
Now the question "How does that play into a team?" comes into play. David Christiansen says that he wants a team of Will Reads (a scary thought, especially if you're Matt) when starting out, then progress to specialists. And this completely makes sense. Up until 2004 all of my work was essentially solitary. To compensate for not having a DB guy, a UI guy, and a Java expert gal at my ready, I did my best to become all of those things. I naturally created a team of sub-specialists within me. It's the same way with a small company that's finding new legs. Do you want the guys that really know about the details of Oracle's implementation of the currency type, or do you want the guy who can flip from pretty good architecture design, to dealing with a customer bug, to filling the coffee pot when it's empty? Me? I don't like coffee very much.
No problem, it's half a year in the future of the dot com boom and you now have more developers than you can shake a stick at. Along the way you needed some specialists because you needed to know how to scale well, and you wanted some great design on the next product line, and you really needed someone who could make UI that blew the pants off your users (which is a really nice feature if you happen to be making a porn site). Now you're wondering if you can make a team of specialists, or do you need a healthy dose of generalists to mellow out the silo of knowledge? This is where Scott Ambler talks about generalizing specialists. These are people who have a specialty, but are also inclined to learn about the domains that neighbor their own.
In the case of a highly functional Agile team, you really can't prevent specialists from learning about other areas, not that you would want to. There's just too much communication for that knowledge to not spread amongst team members. You can facilitate it, encourage it, though various mechanisms like pair programming, but you can't stop it if the team works to its fullest potential.
What really should be going through your head is this: Why am I even interested in this topic? The answer is undoubtedly the #1 concern of Agile: FEAR. Project managers are afraid that somehow their company will hire 600 people who love to work with databases, only four guys who know how to write the application layer, and they'll contract a guy to do the UI "as needed". Their fear is warranted because a team of database experts is going to have a hard time making the jump to the application layer on their own. However, a team of five database experts and one application layer lady stands a much better chance of becoming a cross-functional team that can deliver on features; and at the end of the day, that's really what matters most. If Susan decides that in order for her team to deliver on time, she has to crank out some Java instead of SQL, then it really shouldn't matter to anyone but the team. It also shouldn't matter to anyone outside of the team that the other five developers aren't "well rounded" if they are meeting expectations. If the team is not meeting expectations, then the team needs to be made aware, but beyond that, it is up to them to fix the problem. That's the beauty of a self-organizing team.
Agile is built for generalists like me. It is also built for specialists. Fear is what Agile eliminates. Agile relies on the team to react to changing job requirements, and empowers the team to make the changes needed. This gets the team to invest themselves in what they produce. I believe for these reasons that it does not matter if you hire generalists or specialists, only that you hire people who are willing to adapt, people who are willing to be Agile.
Now the question "How does that play into a team?" comes into play. David Christiansen says that he wants a team of Will Reads (a scary thought, especially if you're Matt) when starting out, then progress to specialists. And this completely makes sense. Up until 2004 all of my work was essentially solitary. To compensate for not having a DB guy, a UI guy, and a Java expert gal at my ready, I did my best to become all of those things. I naturally created a team of sub-specialists within me. It's the same way with a small company that's finding new legs. Do you want the guys that really know about the details of Oracle's implementation of the currency type, or do you want the guy who can flip from pretty good architecture design, to dealing with a customer bug, to filling the coffee pot when it's empty? Me? I don't like coffee very much.
No problem, it's half a year in the future of the dot com boom and you now have more developers than you can shake a stick at. Along the way you needed some specialists because you needed to know how to scale well, and you wanted some great design on the next product line, and you really needed someone who could make UI that blew the pants off your users (which is a really nice feature if you happen to be making a porn site). Now you're wondering if you can make a team of specialists, or do you need a healthy dose of generalists to mellow out the silo of knowledge? This is where Scott Ambler talks about generalizing specialists. These are people who have a specialty, but are also inclined to learn about the domains that neighbor their own.
In the case of a highly functional Agile team, you really can't prevent specialists from learning about other areas, not that you would want to. There's just too much communication for that knowledge to not spread amongst team members. You can facilitate it, encourage it, though various mechanisms like pair programming, but you can't stop it if the team works to its fullest potential.
What really should be going through your head is this: Why am I even interested in this topic? The answer is undoubtedly the #1 concern of Agile: FEAR. Project managers are afraid that somehow their company will hire 600 people who love to work with databases, only four guys who know how to write the application layer, and they'll contract a guy to do the UI "as needed". Their fear is warranted because a team of database experts is going to have a hard time making the jump to the application layer on their own. However, a team of five database experts and one application layer lady stands a much better chance of becoming a cross-functional team that can deliver on features; and at the end of the day, that's really what matters most. If Susan decides that in order for her team to deliver on time, she has to crank out some Java instead of SQL, then it really shouldn't matter to anyone but the team. It also shouldn't matter to anyone outside of the team that the other five developers aren't "well rounded" if they are meeting expectations. If the team is not meeting expectations, then the team needs to be made aware, but beyond that, it is up to them to fix the problem. That's the beauty of a self-organizing team.
Agile is built for generalists like me. It is also built for specialists. Fear is what Agile eliminates. Agile relies on the team to react to changing job requirements, and empowers the team to make the changes needed. This gets the team to invest themselves in what they produce. I believe for these reasons that it does not matter if you hire generalists or specialists, only that you hire people who are willing to adapt, people who are willing to be Agile.
Subscribe to:
Posts (Atom)
