- Augustine, Sanjiv and Cuellar, Roland. "The Lean-Agile PMO", Cutter Consortium Executive Report, Vol. 7, No. 10, 2006.
- Cockburn, Alistair. Agile Software Development: The Cooperative Game, Addison-Wesley Professional, 2006.
- Cohn, Mike. Agile Estimating and Planning, Prentice Hall, 2005.
- Highsmith, Jim. Agile Project Management: Creating Innovative Products, Addison-Wesley Professional, 2009.
- Martin, Angela, Noble, James and Biddle, Robert. "Programmers are from Mars, Customers are from Venus: A practical guide for customers on XP Projects", 2006.
- Poppendieck, Mary and Poppendieck, Tom. Lean Software Development: An Agile Toolkit, Addison-Wesley Professional, 2003
- Rooney, Dave. "An Organizational Structure for Agile Projects", Cutter Consortium Executive Report, Vol. 8, No. 5, 2007.
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Thursday, January 12, 2012
Agile Reading List
Tonight I will be giving a talk to our local PMI chapter about what it takes to succeed in Agile. This gave me an opportunity to gather and hone some of my thoughts regarding what I've been referring to as "Whole Agile". Below is a list of reading materials that I think together reflect all of the aspects (and not just practices) of what it takes to succeed at Agile. This is by no means an exhaustive list of books on Agile Methodology that I recommend but rather it is mean to cover all aspects of Whole Agile.
Labels:
agile,
development,
reference,
software
Thursday, July 28, 2011
Agile Software Development - Why?
I recently guest-published an article on the blog hosted by Big Blue Bubble, the award developer of handheld video games. If you're interested in learning about why Agile software development is valuable and what benefits you might derive from it, head over to Big Blue Bubble's Out of the Blue.
Labels:
agile,
development,
leadership,
sdlc,
software,
waterfall
Monday, August 30, 2010
What's on your Mac?
Within the span of a week, two good friends of mine decided that it was time to switch from PC to Mac. I promised both of them a list of the Mac utilities and applications that I have found useful or interesting or fun on my Macs over the years. Before I start I need to give props to my buddy Scott Corscadden who took the time to school me in the Way of Mac when I made my switch some years ago.
1Password ($39.95) - This great utility keeps track of your passwords, log in ids, and form settings. It can also generate strong passwords which you access with your 1Password password. Integrates with all browsers. You can even store your encrypted 1Password file on a file sharing service like Dropbox so that all your Macs, iPhones, iPads can access the same passwords.
Adium (Free) - Are you an iChat or an MSN? An AOL or a GTalk? What about all your contacts? Do they all use the same instant message service that you do? With a product like Adium, it doesn't matter. Use Adium to log into multiple IM services at the same time in the same interface.
AppTrap (Free) - Uninstalling an application on a Mac is as simple as dragging it from Finder to your Trash bin. While this does uninstall the application it has a side-effect of leaving behind application support files such as configuration files, caches, databases. AppTrap will automatically detect an uninstall and, after prompting you for permission, delete all the support files for a clean uninstall. CAUTION: Some application upgrade processes consist of uninstalling the old version and reinstalling the new version. When doing an upgrade, select "Leave files" rather than "Move files".
Dropbox (Free) - There are a few cloud storage services out there (including iDisk from Apple). None are as seamless as Dropbox. Configure a directory to be your Dropbox and any file you put in there will automatically be synchronized on the server and with any other client you have pointing to your account. Share files seamlessly between your Macs, PCs, iPhones, iPads, Android phones, etc. The first 2 gig is free. 50 gig costs $9.99/month.
Evernote (Free) - One of my all time favorites. At first glance, Evernote seems like a regular text note taking tool. But you can also take photo notes (with OCR) and audio notes. Oh, and they're all seamlessly synchronized to the cloud. And searchable. Oh, and you can get clients for Mac, PC, iPhone, iPad, Android, Blackberry, Palm Pre, and Windows Mobile. Awesome.
Firefox (Free) - Safari is a damn fine browser. In many respects it is superior to Firefox. The killer Firefox feature for me is its plugins which I make heavy use of (perhaps a topic for another post). True, Safari and Chrome both now support plugins but so far neither of them have as rich a set as Firefox. The moment I can get all or even most of my plugins for Safari I will likely drop Firefox from my list.
gfxCardStatus (Free) - Macbook Pros enjoy not one but two graphics processors. An integrated processor which is light on features and easy on the battery and a discreet graphics processor stacked with features but can run your tank to empty in no time. Apple's method of switching graphics processors is to change the setting in System Preferences and then reboot (Holy Microsoft Usability Batman!). This utility will install a menu icon that not only tells you which card you're currently using but lets you switch back and forth between the two without rebooting. Sweet.
Growl (Free) - Growl is a simple notification platform. Many other applications integrate with growl to inform you of updates, alerts and other information. One interface for notifications.
HandBrake (Free) - HandBrake converts to and from a multitude of audio and video formats. Perfect for converting the format of the video your brother-in-law sent you to a format your television actually recognizes.
Hula Girl (Free) - I don't know why I like this dashboard widget but I do.
iStat Nano (Free) - This Dashboard widget gives you at-a-glance status information about various hardware and software components running on your Mac.
iWork ($79.00) -This is Apple's office productivity suite consisting of Numbers spreadsheet, Pages word processor, and Keynote presentation software. If you must work in a Microsoft Office environment then go get Office for Mac 2008 (2011 coming soon!). If you don't, then get iWork. It's much cheaper, has all the features that you're likely to need and Keynote kicks Powerpoint's ass simply by lifting its right eyebrow only.
jitouch ($6.99) - Once you use the multitouch features of the Mac trackpad you will very rapidly learn to depend on it. Using non-Mac trackpads becomes very frustrating when you find that all it does is move the mouse pointer and nothing else. jitouch extends the multitouch capabilities with literally dozens of other gestures. Easily worth the $6.99 price tag.
MacVim (Free) - At the risk of starting a text editor flame war I'll go on record stating that I'm a VI fan and always have been. MacVim is a terrific port of VIM (VI Improved).
MenuMeters (Free) - MenuMeters puts a couple of handy indicators in your menu bar (at the top of the screen) for monitoring things like CPU, network, disk, etc.
NTFS-3G (Free) - Mac OS/X does not natively recognize NTFS partitions. If you have carved out some of your diskspace to run Windows (via Bootcamp, VirtualBox, or some other mechanism) you might want to install this NTFS read/write driver so that you can read the Windows file system from the Mac side. There is also a commercial version of NTFS-3G called Tuxera if you prefer to spend money.
OmniDiskSweeper (Free) - The Omni Group makes some really great products for Macs. DiskSweeper is a free utility for managing your drive space. With it you can find what's eating all the space.
OmniFocus ($79.95) - The price is a little steep but without OmniFocus I would be a completely disorganized mess at work. If you have read David Allen's Getting Things Done you will love the care that the Omni Group has taken in developing a product that so closely embodies the GTD principles. Purchase the iPhone version as well and access your
OmniGraffle ($99.95) -Another pricey-but-worth-it package, OmniGraffle is a sophisticated diagramming tool. Similar to Microsoft Visio but with a more intuitive interface and richer presentation features, OmniGraffle makes the process of creating complex diagrams easy. It even will output in Visio format for compatibility.
Quicksilver (Free) - "Act without doing" is the tagline from Blacktree. Their product, Quicksilver, is difficult to classify. It leverages Spotlight, Apple's advanced search engine built into Mac OS/X, to easily find and access applications, contacts, music, files, and other data. Without moving your fingers from the keyboard you can access just about anything on your Mac. Quicksilver is indispensable.
Perian (Free) - "The swiss-army knife for QuickTime". QuickTime is Apple's video viewer. It's a great app with a simple, clean interface. Just what you need if you have QuickTime video files to play. For the other 99% of videos it is useless. Enter Perian. Perian adds QuickTime plugins to QuickTime to handle a multitude of other video formats.
The Weather Network (Free) - This Dashboard widget from The Weather Network (Canadian) does a great job forecasting weather. Get the iPhone version as well.
TweetDeck (Free) - There are a handful of Twitter clients on the market but I prefer TweekDeck over them all. In one interface you can not only get your Twitter stream, mentions, and directs but also add in Facebook, LinkedIn, Foursquare, and Buzz feeds. Tweet and/or update your stats in any of these social media tools all from the TweetDeck interface. Be sure to download the iPhone and iPad versions as well.
VirtualBox (Free) - VirtualBox is yet another great free product from the once might Sun Microsystems (I'm really going to miss them). Hopefully Oracle will continue to develop VirtualBox and keep it free. VirtualBox is a Virtual Machine that allows you to run Windows, Linux, or other operating systems while running Mac OS/X at the same time. For those of you that must cling to your favorite Windows programs, use VirtualBox until you kick the habit. If you want a VM but would rather pay for it then try Parallels ($79.99) or VMWare Fusion ($79.99).
VLC (Free) - "It plays everything!" If you need to play the few video formats that Perian doesn't handle then get VLC. This little video player does indeed play just about any format.
Monday, June 28, 2010
The Evils of Management
This post continues on the theme I started in the "Agile - An Elite Game Only?" post. This installment covers the claim that Agile "fails to address the evils of management".
Hear ye, hear ye. Let it now be known that I am one of those pointy-haired bastards. The Man. High Priced Overhead. The Management. My current position is CTO at the Richard Ivey School of Business. I've previously held positions at other companies in VP Engineering, Director Engineering, Manager, Team Leader roles. In ancient times (more than a decade ago) I was a software developer. I've led and managed teams over those years using both traditional planned methods and agile methods. In my past I have been known to quote IEEE and ISO as well as, more recently, Sutherland and Beck.
I hate to deflate your balloon right off the bat but the expectation that any software development methodology will "address the evils of management" is flawed. If we assume for the sake of argument that the use of "evil" here is a colourful metaphor meaning "incompetence" rather than actual malice it is difficult to see how any methodology would solve the problem. Methodologies might somehow stunt the impact of incompetent management but that doesn't really address the problem.
I'll steal a page from my buddy AgileMan and define "incompetence" in a very broad sense to mean "unable, for whatever reason, to perform the necessary duties of the position." This could be due to laziness or bad attitude or fear but it could also be due to lack of job knowledge, insufficient data, overwork, competing goals, or other factors.
Companies need to realize that leading agile teams requires different time and attention from them. It requires more direct interaction, more trust and empowerment, more vision and leadership. So where do leaders find time for these new responsibilities? Thankfully if you have a good teams and healthy culture, Agile requires less Management, less reporting, less approving.
What Have I Learned?
As a manager and leader coming who has worked in both preplanned and agile environments I have learned a few things. While the following lessons might not apply to every situation they are more or less all true for all the situations I've been involved with so far.
Software Development Team Leaders Need To Be Technical
I'll start off with a controversial one. I don't care what you call them... scrum masters, coaches, team leaders, development managers, etc. but the leader of a development team needs to be technical. I'm not saying the leader needs to code every day but she should be capable of and have experience in doing so. The leader needs to know that their primary responsibility is leadership and empowerment and her goals and objectives need to reflect that emphasis. Part of those goals should include ways of staying current on both the leadership and technology sides of the role.
Agile Can Make You A Better Leader -- If You Let It
Leaders and managers who see the opportunity for personal growth and for team growth can leap ahead in their careers by leveraging agile principles. Every modern business leadership book talks about empowering employees to make decisions, getting "out of the way", growing your team to achieve greatness. Agile did not not define this game, agile is just one of the newer contestants. A good leader will leverage the expectations around team performance that come with agile and do everything they can to empower their team. Empower the team with knowledge, with responsibility, and with trust. Frightened, insecure, or incompetent (in the broad sense) leaders will feel compelled to control, define, over-measure. These actions end up stifling the real behaviours that will make the team (and the leader) successful.
Teams Must Understand That Managers Have Responsibilities Too
Too often I hear team members complaining that their manager just needs to trust them. If only the manager wasn't meddling so much we could get more done. If only the manager wasn't asking for us to work on "useless" things we could get more valuable work completed. I'm here to say that Trust needs to go both ways. Teams need to trust that a manager is asking for certain things for a good reason and not just on a whim or because that's what the process tells them to ask for. Sometimes development teams are part of a much larger organization that, for reasons outside the control of the development group, finds value in artifacts that in the team's limited view seem worthless. Trust that a good leader will ask teams for non-product deliverables only if there is a good reason. Naturally teams have the right to ask questions about the deliverable including its perceived value. In the end, the leader should be trusted to make good decisions. That's her job after all.
Bad Management Repels Good People
Finally, it should be obvious that consistent bad management will cause good people to leave. If you feel that your talents are going unrecognized or that "the management" continually screws things up and cannot provide good explanations for the decisions they make then vote with your feet. Even in smaller communities like where I live there are opportunities out there for those who are motivated, energetic, and talented. Life is too short to be miserable in your job.
Coming Up "Soon" - Software Professionals
Hear ye, hear ye. Let it now be known that I am one of those pointy-haired bastards. The Man. High Priced Overhead. The Management. My current position is CTO at the Richard Ivey School of Business. I've previously held positions at other companies in VP Engineering, Director Engineering, Manager, Team Leader roles. In ancient times (more than a decade ago) I was a software developer. I've led and managed teams over those years using both traditional planned methods and agile methods. In my past I have been known to quote IEEE and ISO as well as, more recently, Sutherland and Beck.
I hate to deflate your balloon right off the bat but the expectation that any software development methodology will "address the evils of management" is flawed. If we assume for the sake of argument that the use of "evil" here is a colourful metaphor meaning "incompetence" rather than actual malice it is difficult to see how any methodology would solve the problem. Methodologies might somehow stunt the impact of incompetent management but that doesn't really address the problem.
I'll steal a page from my buddy AgileMan and define "incompetence" in a very broad sense to mean "unable, for whatever reason, to perform the necessary duties of the position." This could be due to laziness or bad attitude or fear but it could also be due to lack of job knowledge, insufficient data, overwork, competing goals, or other factors.
Companies need to realize that leading agile teams requires different time and attention from them. It requires more direct interaction, more trust and empowerment, more vision and leadership. So where do leaders find time for these new responsibilities? Thankfully if you have a good teams and healthy culture, Agile requires less Management, less reporting, less approving.
What Have I Learned?
As a manager and leader coming who has worked in both preplanned and agile environments I have learned a few things. While the following lessons might not apply to every situation they are more or less all true for all the situations I've been involved with so far.
Software Development Team Leaders Need To Be Technical
I'll start off with a controversial one. I don't care what you call them... scrum masters, coaches, team leaders, development managers, etc. but the leader of a development team needs to be technical. I'm not saying the leader needs to code every day but she should be capable of and have experience in doing so. The leader needs to know that their primary responsibility is leadership and empowerment and her goals and objectives need to reflect that emphasis. Part of those goals should include ways of staying current on both the leadership and technology sides of the role.
Agile Can Make You A Better Leader -- If You Let It
Leaders and managers who see the opportunity for personal growth and for team growth can leap ahead in their careers by leveraging agile principles. Every modern business leadership book talks about empowering employees to make decisions, getting "out of the way", growing your team to achieve greatness. Agile did not not define this game, agile is just one of the newer contestants. A good leader will leverage the expectations around team performance that come with agile and do everything they can to empower their team. Empower the team with knowledge, with responsibility, and with trust. Frightened, insecure, or incompetent (in the broad sense) leaders will feel compelled to control, define, over-measure. These actions end up stifling the real behaviours that will make the team (and the leader) successful.
Teams Must Understand That Managers Have Responsibilities Too
Too often I hear team members complaining that their manager just needs to trust them. If only the manager wasn't meddling so much we could get more done. If only the manager wasn't asking for us to work on "useless" things we could get more valuable work completed. I'm here to say that Trust needs to go both ways. Teams need to trust that a manager is asking for certain things for a good reason and not just on a whim or because that's what the process tells them to ask for. Sometimes development teams are part of a much larger organization that, for reasons outside the control of the development group, finds value in artifacts that in the team's limited view seem worthless. Trust that a good leader will ask teams for non-product deliverables only if there is a good reason. Naturally teams have the right to ask questions about the deliverable including its perceived value. In the end, the leader should be trusted to make good decisions. That's her job after all.
Bad Management Repels Good People
Finally, it should be obvious that consistent bad management will cause good people to leave. If you feel that your talents are going unrecognized or that "the management" continually screws things up and cannot provide good explanations for the decisions they make then vote with your feet. Even in smaller communities like where I live there are opportunities out there for those who are motivated, energetic, and talented. Life is too short to be miserable in your job.
Coming Up "Soon" - Software Professionals
Labels:
agile,
leadership,
software
Agile: Average Developers Need Not Apply?
This post continues on the theme I started in the "Agile - An Elite Game Only?" post. This installment discusses the notion (or myth, in my opinion) that agile methods are meant only for the elite or superstars of software development and that the gains promised by Agile are not attainable by the merely average.
Agile teams are expected to learn and experiment and teach and grow. All the time. The argument goes that developers of average skill just can't keep up with that and therefore agile is not for them. Further goes the argument that Agile should only be applied to small teams of superstars and more structured processes should be used to keep the developers of average skill "on track" (or, less kindly, "in line"). I've also had some developers express to me concern about "fading into the background" of a team if they are not allowed to continue as single contributors (although it's almost never a superstar who expresses this concern to me).
Over the past 8 months I've been working with a small team of 6 software developers. I don't think there is a single person on the team who would describe themselves as a superstar. Rather each of them are "just" solid performers who want to do a good job and make a living. I'm also working with a team 4 of business analysts who possess varying depths of knowledge in the various products that are needed. This team of developers and BAs has done some amazing work over the past 8 months while transitioning to agile methods. By just applying the following core principles they have enjoyed higher productivity and, from the feedback I get, much higher job satisfaction all while working on much the same software they had been working on 8 months prior.
So What About Those Superstars?
Still, there's no question in my mind that superstars are fantastic assets. They develop at 10x (or more!) the speed of other developers, produce top quality, and generate new ideas all the time. They live and breathe their profession. They are also, unfortunately, rather rare. I've worked with maybe a half dozen directly (i.e. in my organization) and maybe a dozen indirectly (in partner organizations) over my entire career.
Whenever anyone suggests that we keep the superstars separated from the rest of the team so that they can "do their thing" I just shake my head. Why would any company want to keep all that goodness locked up away from everyone else? My experience has been that superstars bring up the game of the team they are on. They become teachers, role-models, inspirational leaders. The effect is multiplicative! Good developers become great developers when they are on teams that have a superstar. Only once have I found a superstar (in the productivity sense) that truly needed to remain an island. All other cases have resulted in higher performing teams without eroding the output or visibility or "aura" of the superstar.
In summary, teams, whether they have a coding wunderkind on the team or not, have always benefited from agile methods in my experience. What's important is that the team developers their own passion for quality and growth. Leaders can influence and inspire this attitude but it cannot be mandated. So choose your leaders carefully!
Coming Up - The Evils of Management
Agile teams are expected to learn and experiment and teach and grow. All the time. The argument goes that developers of average skill just can't keep up with that and therefore agile is not for them. Further goes the argument that Agile should only be applied to small teams of superstars and more structured processes should be used to keep the developers of average skill "on track" (or, less kindly, "in line"). I've also had some developers express to me concern about "fading into the background" of a team if they are not allowed to continue as single contributors (although it's almost never a superstar who expresses this concern to me).
Over the past 8 months I've been working with a small team of 6 software developers. I don't think there is a single person on the team who would describe themselves as a superstar. Rather each of them are "just" solid performers who want to do a good job and make a living. I'm also working with a team 4 of business analysts who possess varying depths of knowledge in the various products that are needed. This team of developers and BAs has done some amazing work over the past 8 months while transitioning to agile methods. By just applying the following core principles they have enjoyed higher productivity and, from the feedback I get, much higher job satisfaction all while working on much the same software they had been working on 8 months prior.
- Direct and active developer contribution to planning including requirements breakdown, estimation, risk identification
- Competent business analysts who value the skills and knowledge of the development team
- Daily and continuous collaboration between and among developers and business analysts
- A development manager who trusts the team and inspires a culture of learning
- Automated unit tests (although this has only been added in the past 4 months)
So What About Those Superstars?
Still, there's no question in my mind that superstars are fantastic assets. They develop at 10x (or more!) the speed of other developers, produce top quality, and generate new ideas all the time. They live and breathe their profession. They are also, unfortunately, rather rare. I've worked with maybe a half dozen directly (i.e. in my organization) and maybe a dozen indirectly (in partner organizations) over my entire career.
Whenever anyone suggests that we keep the superstars separated from the rest of the team so that they can "do their thing" I just shake my head. Why would any company want to keep all that goodness locked up away from everyone else? My experience has been that superstars bring up the game of the team they are on. They become teachers, role-models, inspirational leaders. The effect is multiplicative! Good developers become great developers when they are on teams that have a superstar. Only once have I found a superstar (in the productivity sense) that truly needed to remain an island. All other cases have resulted in higher performing teams without eroding the output or visibility or "aura" of the superstar.
In summary, teams, whether they have a coding wunderkind on the team or not, have always benefited from agile methods in my experience. What's important is that the team developers their own passion for quality and growth. Leaders can influence and inspire this attitude but it cannot be mandated. So choose your leaders carefully!
Coming Up - The Evils of Management
Sunday, June 27, 2010
Agile - An Elite Game Only?
I thought the following comment to my last post (Manifesto of Second Best Alternatives) was important enough to inspire a new post rather than a comment. Anonymous writes:
First some background, over the past dozen years I've held a number of software management positions from team lead to CTO. Prior to those years I was writing software primarily in C++ and Java for client and server solutions. I've directly led small teams and also led organizations up to 100 software professionals. I've managed using both traditional, planned methods as well as agile methods.
Here are the important themes that this terrific comment touches on.
Agile teams work very closely with each other on a daily basis. Team members collaborate on problems and solutions all the time. They communicate with each other at least once daily but typically much more. Team members are expected to pick up tasks even when not directly in their field of expertise
So does agile necessarily rob us from the benefits of specialization? I think this is less of an agile issue than it is a team issue. Do you value the speed that comes from deep specialization (at the risk of damaging your company should a specialist leave) or the flexibility of generalization (at the risk of team members being jacks-of-all-trades-and-masters-of-none)? In my experience, the benefits of specialization, even on agile teams, are too great to move to total generalization. That said, agile teams do not necessarily mean a push to generalization. Software developers are not automatons. If an agile team is truly doing their own planning (and not under the thumb of a heavy-handed manager) they will naturally leverage the skills and experience that are on the team. The following quotes are representative of the meme I'm expressing here and all commonplace on the teams I've been involved with.
Coming up tomorrow - Agile: Average Developers Need Not Apply?
"Sure, Agile approaches an answer to many of the noted problems all too common in the software development world, and maybe in another decade we might improve upon it some more. But amongst the positives, it occurs to me that Agile robs us of specialization, making all developers fit a ridiculous mold that only a handful can actually aspire to fit, hence the consensus that there is some need for "less than agile" methods. It's great to be able to learn new things and do so at light speed, but that is not every developer trying to make a living. So all you do is reflect back your own smugness when you talk about these so-called "incompetent individuals." Beware that label: One day you, too, will reach age 50 and the youth getting by on 1/3 of your pay will undercut you because they are 80% as good as you.This is a great comment because it raises some very important themes. I was going to touch on them all in this post but I'm afraid that would result in a huge post that few would have time to read. So what I'll do today is list the themes and start a discussion on one. Over the course of the next few days I'll post some thoughts on the remaining themes.
Another observation I have about Agile gets right to the heart of why nothing attempted by the Agile community matters, and that is: Agile fails to address the evils of management. It doesn't matter how well you estimate something, management will always demand twice as much no matter how much realistic evidence you present to them. Management sees Agile only through the lens of "how can I make these assholes produce more and whip themselves in the process?" And so we have reopened the doors to the sweatshop. Information Sharecropper has a real nice ring to it, though, right?
You want a fix? How about making software development a profession equal in status to doctors and lawyers. That will solve 99% of the problems. Doctors don't let non-doctors manage them, it simply is unacceptable.
What I'm looking for is that holistic manifesto--the one that gets the job done, gets me paid, and doesn't leave me feeling completely played the way I have been for over decade now. Anything else is just blather. Smart people in America are just easy marks."
First some background, over the past dozen years I've held a number of software management positions from team lead to CTO. Prior to those years I was writing software primarily in C++ and Java for client and server solutions. I've directly led small teams and also led organizations up to 100 software professionals. I've managed using both traditional, planned methods as well as agile methods.
Here are the important themes that this terrific comment touches on.
- Specialization vs generalization
- Agile for the elite superstars
- Evils of Management
- Respect for the software profession
Agile teams work very closely with each other on a daily basis. Team members collaborate on problems and solutions all the time. They communicate with each other at least once daily but typically much more. Team members are expected to pick up tasks even when not directly in their field of expertise
So does agile necessarily rob us from the benefits of specialization? I think this is less of an agile issue than it is a team issue. Do you value the speed that comes from deep specialization (at the risk of damaging your company should a specialist leave) or the flexibility of generalization (at the risk of team members being jacks-of-all-trades-and-masters-of-none)? In my experience, the benefits of specialization, even on agile teams, are too great to move to total generalization. That said, agile teams do not necessarily mean a push to generalization. Software developers are not automatons. If an agile team is truly doing their own planning (and not under the thumb of a heavy-handed manager) they will naturally leverage the skills and experience that are on the team. The following quotes are representative of the meme I'm expressing here and all commonplace on the teams I've been involved with.
"Jim, you know databases better than any of us, can you take on this schema deliverable?"
"I'll do the UAT for this requirement. I'll fit right in to the framework Janet and I wrote a couple iterations back."
"I'll take on the server task. Nathan, can I get some of your time this iteration since you know the server so well?"An additional benefit of an agile team arrangement is that the daily interactions developers have result in some specialized knowledge getting absorbed into more team members. This reduces the company risk of maintaining specialization pillars. Teams naturally drive towards becoming (and by now you've probably been wondering when I would bring up this term) generalizing specialists. There's enough written about generalizing specialists that I'll just leave you a Google link.
Coming up tomorrow - Agile: Average Developers Need Not Apply?
Subscribe to:
Posts (Atom)