In the last few years, I have constructed or helped to construct mutiple development teams; all working in an agile development environment. My colleagues and I have hired and coached business analysts, developers, testers, artists, and designers, and we have seen first hand the growth and astounding productivity that these teams have produced. In short, my teams have outperformed the organization in every job I have ever had. EVER. Now clearly this article probably sounds like it is starting out a bit boastful, and perhaps even arrogant. Please don't get me wrong. Frankly, I get just as much wrong as I do right. But in the last few years I have learned some key lessons that have enabled me to continue to building happy, cohesive teams that outperform and beat expectations repeatedly. My intent is simply to share some of these lessons, and hopefully garner feedback from my (admittedly limited) audience so that I might continue to improve further in my craft.
Management Adoption
More often than not, and particularly in larger organizations, this is the largest hurdle to jump (or so it seems at first). Management, particularly those who love traditional project management styles and status reports, often think of Agile as a dirty word, as they simply do not understand the benefits it brings. Similarly and unfortunately, too many developers simply do not really understand agile either. Too many have the tendency to use Agile as a simple excuse to avoid documentation and status altogether, which ultimately leads not to a true Agile methodology, but glorified cowboy coding. Make no mistake, if you think Agile is easier than waterfall, then YOURE DOING IT WRONG. Good Agile management is simply the hardest way to manage a project. Constant change, continuous delivery, and adaptation to market and business needs are not simply or easy things to handle. It would be much easier to stick to a strict deadline and set of deliverables... but in most cases, those waterfall projects lead to unused or underused software deliverables that simply dont meet the changing needs of the business. Agile is not an excuse for doing work. Its a methodology for doing work CORRECTLY, and as such it will force transparency and accountability into the development stream at every step, and allow for higher level of controls to management, which is ultimately, the selling point. Still, its hard to get everyone to buy off on this, particularly if some pesky cowboy coders have already misrepresented the meaning and burned the business once before. In these cases, its typically easier to create allies amongt the business analysts or product managers directly or start with smaller projects and let the methodology speak for itself. In my experience, it doesn't take long to convince people when there are quantifiable results to point towards.
Building the Team
Building and organizing the team is an ongoing effort in continous improvement. Its not just about BUILDING the team... Sometimes it is about removing bad apples, sure. Other times, its about filling gaps in expertise or in simply reorganizing folks and adjusting team dynamics to reduce bottlenecks and improve throughput. But a common mistake is to select too many people of similar backgrounds and mentalities. Teams that are chock-full of 'rockstars' have often led to failure, as sprints turn into constant architecture and refactory rather than actual value delivery. Similarly, a team full of junior level resources will probably under-deliver from lack of experience and expertise. A balance is required in which people of various levels of seniority and experience are required in order to balance out the team. Architect level folks may get bored with input validation requirements for example, and recent graduates probably have no business designing the basis for your business rules engine or your complex event processing implementation. Make sure as well to staff developers and testers of various different areas of expertise (not just levels of expertise). It may be important to have a jQuery specialist, CSS guru, UX designer, or Automation Tester. Sure, other team members could do many of these things... But if you want optimum throughput in your team, then you should follow the notion of generalized specialists, and staff members that CAN serve multiple roles, but that can be optimally used in particular ways in order to speed and ease delivery. Regarding non-technical skills... HUNGER and ATTITUDE are always key. If there is no personal goal in growth, then growth you will not see; and a team that is not growing is floundering.
Sprint Zero
Every project team deserves (and requires) a sprint zero. This should be a technical sprint, but its goals are not limited to technical things alone. This time serves as an opportunity to generate spike solutions, proof of concepts, and to generate base system architectures, to be sure. But this is also the time when you can find out the aptitudes and tendencies of your team members. Find out who pairs well together (hint - its not usually the folks that agree on everything!), who likes to work on what, and most importantly, who is best or fastest at which aspects of the development process. Which testers like to test? Which like to automate their testing? Are their developers on the team that tend to lean into the database optimization side of things? Who are the thinkers and the architects? Who enjoys execution and implementation. Who doesn't? I prefer to sprinkle a variety of tasks into sprint zero so that everyone has items to gravitate towards (and its important to let developers choose their own tasks at this stage, even if encouraging them to stretch themselves or commit to various things here and there). Beyond the normal application architecture stuff, I like to include a variety of additional tasks (security, email/notifications, data access frameworks, automated build setup and configuration, etc). Typically you will begin to find out very quickly where people are comfortable and what they are best at, and you can save this information for use going forward in order to help the team arrange themselves optimally.
Velocity
Finding a good velocity is key to driving a successful project. Without some stretch goals and reason for motivation (positive motivation works better than negative), then velocities tend to stagnate and lay flat across multiple sprints. The goal (but not indefinitely) is obviously to GROW your teams' velocity, thereby increasing your throughput and taking you closer to your goal (a finished product). But remember, points can only be awarded for COMPLETED work. That doesn't mean development complete. That means development, UX, BI, DBA, QA, and whatever else might apply to your particular product. Points can NEVER be awarded when stories have not completed every stage of the process that takes them to 'DONE', and it is infinitely important to push your team to agree on a common 'definition of done.' Things like unit tests, proper testing, automation tests, styling and UX attention, validation, etc should all be included. Lastly, this works a lot better if your stories are divided into smaller rather than larger chunks of work. Assigning stories that require 7 days of developer attention in a two week sprint results in downstream team members sitting stagnate for the first half of the effort, only to be swamped at the last few days prior to delivery and demo. This almost inevitably leads to missed or defect-riddled demos, and rejected rather than accepted (and thereby UNAWARDABLE) stories. It also works best to divide larger stories up into smaller chunks vertically rather than horizontally, so that they stay testable. Instead of following the common mistake of making the db work one story and the business logic another, consider instead diving the form entry from validation. You may achieve the same goal while still providing a constant workstream for other team members. Further, if a story is dropped, it is much less likely to render related stories 'undemoable', resulting in a further loss of productivity. Finally, make no mistake; incomplete stories are not a loss in perceived productivity; they are an actual loss in productivity. In software, as in football, percentage complete doesn't count. 99% is no better than 0%. They are incomplete all the same. (If you still don't believe me then you may have a story that is actually two).
Failure
Unforunately, it is vital for a team to learn to fail together. Knowing what failure feels like is just as important as knowing success, as the experience will give them the tools they need to know when to set off the alarms in the future. A team that has never failed is NOT good. They are either lucky or sandbagging. No two ways about it. Besides, a single failure will not mark or marr the team permanently as long as it is handled correctly, and it is not 'bad for morale' as many profess. Repeated failure, or the perceived (or real) setup for failure is certainly bad for morale; but a single incident (or sometimes two) of failure is sometimes exactly what the doctor ordered in order to force a team to analyze their patterns and habits, and regroup into a better team.
Success
Equally important to failure is success. Every team has to know what real success feels like. Otherwise, it becomes a grind. Employers who think that software is only about money (yes it IS about money, just not ONLY money) have it wrong, and will never fully grasp the motivational factors that drive the success of the agile team. Recognition, reward, assurance, and praise all serve incredibly well to help push a team to further successes. Raises often work, and of course are often deserved and warranted (and SHOULD be done!), but I have found that simple team lunches, happy hours, release parties, and the like can be incredible effective in rallying the troops after a hard sprint. Nurture and coach the team with each failure, and with each success, and the growth will carry onward, paying back dividends on the investment put into each preceding effort.
Quality
Back again to the definition of done. Successes are not real without quality, and quality should be defined by the standards of the team as a whole, in the form of agreed upon definitions of done. Without quality, your velocity may increase over and over again with each sprint, but the cost of the gains will crumble with maintenance and refactory cost in later sprints, creating a chain reaction that will lead to the destruction of the team. Investment in unit testing, code quality, good architecture, and peer programming may slow the velocity at first, but rest assured that with a proper DoD in place, your velocity is TRUE, and is not hiding potential defects or brittle code that will slow the team later. As the team grows and as their capacity for work grows, a constant insistence on quality is the only way to protect the team from self-implosion at the introduction of the first heavy handed business change to the project. Without good quality throughout the process (not just in QA), the project is typically over long before it began.
Sustainable Pace
The obsession with constantly increasing velocity is one that drives most developers crazy, as they interpret the rhetoric to mean 'more hours'. On the contrary, increasing velocity should coexist with a sustainable work pace set for the team. After all, you may be able to get away with burning out the team once, but you will not get away with it for long, and it will become increasingly difficult to staff your team with quality people who meet the criteria for playing on a great team. Instead of utilizing brute force via long hours as the only way to increase velocity over time, look to other tools like resource optimization (let the UX guy do UX stuff, and don't ask him to fix the database), story sizing (smaller is typically better), investment in code quality and good architecture (velocity will increase later, despite the initial costs), and peer programming (Quality will increase with multiple minds on the case, and the occasional departure will ultimately cost less if responsiblity for code is spread across various team members). Drive your team to success. Don't drive them into the ground. The team is your biggest investment, not the software.
Continuous Delivery
The best tool in the belt for feature and functionality compromising. Waterfall projects have no room for compromise because future releases require too much governance and overhead to size, spec, kick off, execute, test, and deliver. Continous delivery is the key to great agile management. Medium and Low priority feature sets can be offset to future releases that are weeks and not months away, and the continuous delivery model ultimately provides a wonderful level of control to management and business owners, as it provides a great way to keep ahead of market change. Further, if done correctly, continuous delivery models can keep your codebase alive, in a constant state of maintenance and growth, and keep it from becoming that legacy codebase that everyone is scared to touch. The moment your codebase leaves the continuous delivery model, it is at risk of becoming legacy code, which makes it infinitely harder to keep maintained and updated by development staff, without having to allow for a costly rewrite in order to reduce the risk of change in the unknown application source.
Refactoring the Team
Team members deserve to grow, and grow they will. At the end of each project is a great opportunity for identifying key resources and up-and-comers for reallocation into other roles on future projects (or for other roles on the same project going forward). If you are keeping a good mix of talent levels on your team, then many members will be learning and growing at a fast rate, and will require to be shifted in order to allow for their personal growth to continue going forward. Allow for the room to flex to the professional needs of these people, and they will outlive the common lifespan of the IT professional at your organization. Ignore them and you will go through countless waves of hiring and quitting, and your ultimate goal of maintaining a great team will continue to fall short as your investments walk out the door.