Development Managers in Agile

To understand the role of a development manager in Agile, we must first understand the difference between management and leadership.

The goal of management is to attain perfection in its processes in an effort to maximize productivity. The goal of leadership is to be an agent for change in an effort to maximize organizational sustainability through innovation and adaptability.

Although they are counteracting forces they are both required to be successful. It is as important to get things done efficiently as it is to innovate and adapt.

So how should leadership and management manifest themselves in an Agile-based organization?

From a management perspective, Agile assigns management roles through clear delineation of authority between the Agile roles, i.e. Product Owner, ScrumMaster, and Team.

Leadership is an implied attribute in Agile. Agile consciously acceptances that much of what we believe to be true will prove to be either fundamentally flawed, or, will become flawed because of real-world change. Since change is inevitable, leadership is a universal trait that is necessary for Agile entities to be successful.

A leader is often characterized as a charismatic and/or visionary manager. As I mentioned in my previous blog post, that is because most organizations are autocratic in nature and thus leaders are part the management tier.

Agile is not autocratic. There is no hierarchy. As part of this structure, it is intended that leaders emerge and assert themselves as part of the process of getting things done. This also means that leadership resides in each of the three Agile roles in a quantity that is not assigned or dictated but emerges according to need.

So if Agile groups are not hierarchical and leaders emerge naturally, then what is the role of the development manager?

The job of a development manager in an Agile organization is to promote both leadership and management; to value both within the organization; and to empower both to grow and change organically through the Agile principles. If it sounds like a development manager is more leader than manager - you are right.

I'm sure as you read this, many of you recognize command-and-control (autocracy) as a significant attribute within your workplace. Through your commitment to Agile principles, you are provided the opportunity of implementing the aforementioned organizational model - if not throughout your organization, then as a model for your organization.

Self-Managing Teams, Adaptability and Innovation

Technological advancements and the global economy has made innovation and adaptability a critical component for sustainability. Thus we need to push our conventional management model into antiquity and move towards the more dynamic model of self-managing teams.

As we all know, Agile promotes the concept of self-managing teams. This concept has been gaining steam recently but has actually been around for quite some time. W.L. Gore, for example, has been organized around self-managing teams since 1958.

Let’s start with what we have today and how we got here.

Top-down leadership is the prevalent model in most organizations and is ingrained in most of our thinking and behaviors. The current autocratic nature of management was introduced during the industrial revolution. Its ability to churn out vast quantities of manufactured goods is undeniable. Its primary limitation in today’s business climate is that it requires that a select few contain the wisdom, vision, and authority - and the masses execute the plan. This is great for repetitive tasks but less so for innovation and adaptability.

Just as it is irrational to think that we can plan the development of software up front and rigidly adhere to and execute the plan – as if change isn’t going to happen - so too is it delusional to think that adaptability and innovation is borne out of autocracies and bureaucracies.

Innovations are not planned or commanded into existence. Instead, innovations are developed serendipitously. We search for one thing and unexpectedly find another. We need to structure our organizations in a way that promotes the manifestation of the unforeseen.

As with all things, we must make compromises when changing from one management model to another. As Gary Hamel so aptly puts it in his book The Future of Management:

“You can build a company that is virtually error and mistake free. You can build a company that is highly adaptable. But you can’t do both. In this sense, perfection is the enemy of progress”

If I sound like an anarchist who thinks there’s no room for authority, I assure you I am far from it. Leadership is always needed and always sought out. I believe in authority too. I just think that it is ineffectively distributed in the conventional management model.

The requirements for managers in the contemporary world in which we compete are:

• Leading by pushing authority, accountability, and reward to small front line teams.
• Leading by creating an environment that allows for experimentation, collaboration, and not only self-managing but self-organizing teams.

These steps will encourage creativity, passion, and a sense of community and mission – all of which are ingredients for a dynamic, adaptable and innovative workplace. A workplace built to compete in the 21st century.

Another Explanation of Story Points

Story points seem to be the most misunderstood concept within Agile so I'm going to take my stab at helping others to understand what they are and their importance.

The typical question is: Why estimate user stories with these ambiguous and arbitrary things call story points when I can use hours which inherently make more sense to me?

Hours may make sense over story points at this very moment, but hopefully I'll be able to change your mind after you complete reading this article.

The major impediment to using hours is the variability between people and teams. I recently heard Jeff Sutherland state that a Yale University study has shown that what will take the best developer one hour to complete, the worst developer needs 10 hours to complete. When comparing best and worst teams that grows by an order of magnitude so an hour of the best teams translates to 2000 hour for the worst teams. The variability of hours is a real impediment and is typically a huge time consuming task on most projects.

Story points simplifies the estimation process by taking the developer/team variability out of the process by assigning a level of complexity to user stories. Many in the Agile community use a subset of the Fibonacci sequence as the units of measure; 1/2, 1, 2, 3, 5, 8, 13, 21, 34 and 45 per user story respectively. Think of story points as a more flexible version of assigning estimates as small, medium or large.

The story point estimation process begins by the team selecting the smallest user story and mutually agreeing on its complexity by assigning it a number from the Fibonacci subset of numbers. This user story is called the "keystone", meaning all other user story estimates are based on relative complexity to the keystone user story.

The byproduct of this is that upon sprint completion the team is able to report to the Product Owner in a more concise measurement of productivity - number of story points completed. The Product Owner sees things through the lens of project stories, features, etc. It makes more sense to communicate velocity, i.e. sprint productivity, in the form of story points than hours. Story points translate directly to what is manifested on screen when the working code is demonstrated and hours do not.

Here is an example of using hours as a measurement of sprint effectiveness. A team of four developers work on a project for a two week sprint. At 40hrs per week, the four developers have 320 hours of available time to work during the sprint. However, once the sprint is complete, their velocity shows that they only accomplished 60 hours of work based on the estimated hours assigned to the user stories they completed. That is a misleading depiction of productivity that leads to irrational conversation about whether the team is working hard enough.

Using story points, the team's velocity is expressed in terms of productivity related to the complexity of the tasks completed. For example, let's say the Product Owner knows in advance of the sprint that the team's goal is to complete 35 story points. At sprint completion, the effectiveness of the sprint is measured against the sprint goal and previous sprint velocities. Story point velocity is used to view the overall project productivity in terms of acceleration/deceleration, i.e. is velocity increasing or decreasing.

The Product Owner can also easily translate velocity into an estimated release date more easily than with estimated hours. As an example, if there are 350 total story points remaining in the product backlog, and the velocity of the team is at 35 story points per sprint, then the product backlog will be exhausted in 10 sprints.

Lastly, estimating projects is not only faster but more accurate than estimating in hours! Jeff Sutherland references two experiences related to this in one of his blog articles (read it here).

I hope this clears up what a story point is, why we use them, and provides a compelling reason to transition from hours to points.

Kano Model for Prioritizing User Stories/Requirements

Regardless of whether you subscribe to Waterfall or Agile as your preferred methodology, some form or prioritization of requirements (Waterfall) or user stories (Agile) will take place.

One of the more difficult tasks is helping the user community to determine the varying degrees of importance of each requirement. One method to help with this process is the Kano Model.

The Kano Model is named after Professor Noriako Kano who in 1987 developed a theory for product development to classify features into five categories based on answers to questions about the specific features. Following are the five classifications.

Attractive	Delighted to have but unexpected.
One-Dimensional	Features customers compare with your competition.
Must-Be	A must have feature.
Indifferent	Neutral about the feature.
Reverse	The customer do not want the feature and actually expect the reverse of it.
Questionable	Indicates that the customer is unclear about the nature of the feature

The features are classified by asking the customer two questions – one functional and the other dysfunctional – to which the customer selects one of 5 possible answers.

The questions are:

1. How would you feel if the feature was present in the product?
2. How would you feel if the feature was absent from the product?

The answers from which they may choose are:

1. I would like that.
2. I require that.
3. I don’t care about that.
4. I can live with that.
5. I dislike that.

The initial reaction of most people when posed with the functional/dysfunctional question think “won’t the questions offset each other?” As it turns out most often they don’t.

An excellent example that I’ve heard in the past is with a milk carton that has a thermometer on the outside so the customer can see what temperature the milk is. One may select answer 1 I would like that as the functional answer but select answer 4 I can live with that for the dysfunctional question.

The answers are then compared to a matrix below to arrive at the classification. The letters in the middle of the matrix represent each of the classifications via its first letter, e.g. A=Attractive. To take our earlier example of the thermometer on the milk carton, the functional was Like and the Dysfunctional was Live With thus the matrix indicates that the classification is A=Attractive.

	Dysfunctional
		Like	Expect	Neutral	Live With	Dislike
Functional	Like	Q	A	A	A	O
	Expect	R	I	I	I	M
	Neutral	R	I	I	I	M
	Live With	R	I	I	I	M
	Dislike	R	R	R	R	Q

With the Kano Model, one is able to ask the customer two short and concise questions and ultimately gather critical data regarding the importance of the feature to the product. As a result, a development team can easily discern what’s mandatory, what’s nice to have, and where the land-mines are.

There are additional techniques that can be used in combination with the Kano Model to further prioritize requirements like weighting features but alas that will have to weight for another day.

Estimating Defect Production

Estimating the number of defects a project should expect to produce and remove is one of the least talked about subjects in software development. In this article I'll provide some industry statistics to help with that estimation process and hopefully convince you of why Agile will likely reduce the level of effort associated with defect fixing.

There have been studies performed to estimate the number of defects that a software development effort will likely encounter during its life cycle. Obviously the larger the project the greater number of defects one should expect to encounter. If you follow this blog, you’ll know Steve McConnell’s book "Software Estimation: De-mystifying the Black Art” is one of my favorites and is always by my side. One of the chapters discusses estimating defects. In his book, McConnell references a Capers Jones (2000) study that indicates a reasonable expectation is to have 50 defects per 1000 lines of code (LOC).

However, a more granular look will show that smaller projects will experience fewer defects than larger ones; for example a project with fewer than 2K LOC will likely have 0-25 defects per 1K LOC where a project with over 512K LOC will likely have 4-100 defects per 1K LOC. Keep in mind that factors such as your programming language and other technologies will effect this estimate. It’s always more accurate to use historical data to estimate effort but in lieu of that, these data are better than nothing at all.

Here are a few more factors to consider:

- Defects occur at all points during development e.g. requirements, architecture, development, documentation, etc.

- There are best practices for defect removal such as design reviews, code reviews, prototyping, unit testing, system testing, and various levels of beta-testing – each of which have different removal rates. The highest removal rates come from formal code reviews (45-70%), prototyping (35-80%), and high volume beta testing (60-85%). Surprisingly (at least to me) one of the lowest removal ratings comes from regression testing (15-30%).

Here is where I transition from conveying data to providing my opinion on why Agile allows a development team to reduce the effort associated with defect removal when compared to Waterfall.

With Waterfall, the life cycle stages occur in a sequential manner,i.e. requirements, design, development, and test. Although it could be reasonably argued that the number of defects may not significantly change between Waterfall and Agile I think it is unreasonable to assume that the effort to remove them will remain the same. Defects introduced during the requirements gathering and design stages that are not found until development or even later have a snow ball affect because they pile up on one another.

Because of it’s iterative nature, Agile allows for requirements, design, and development defects to show themselves virtually immediately after they have been introduced. Dealing with defects introduced over a single two week sprint is a lot easier to manage than untangling a slew of defects that occurred over several months. We’ve all been on Waterfall projects where our integration testing revealed flaws that have required rewriting methods and even entire components. I contend that those types of wholesale defect removal efforts are mitigated substantially through continuous integration, daily stand-ups, two week sprints with customer tests immediately thereafter, as well as the other feedback loops inherent in Agile.

I’m interested in your thoughts.

Kanban Development Methodology

I was introduced this week to a development methodology called Kanban. For those of you who don't know the origin of the word Kanban, it's manifestation is as a physical card as part of the Toyota Production System (TPS) that signals the moving and production of parts in a "pull" system; a system where parts are made available as others are pulled into use downstream. The objective in a manufacturing setting is to control inventory based on the speed of production. The concept is applied to software development through controlling the development of tasks. In Agile, tasks could be user stories (the parts) which are subsequently developed into software features (downstream production).

The control of requirements, design, and development inventory is important to maximize project efficiency. A main focus of Agile is to gather requirements, design solutions, develop objects, and test working code at the moment they are needed. If any of these areas are far ahead or behind the others then a critical principle of Agile is being violated. Implementing Kanban helps to keep production of objects at each stage of the project at the appropriate levels.

Here is how it works. The team has a board that looks very similar to a Scrum board. It has columns for stages of development. The stages can look quite different. The images contained in this article are a few examples courtesy of InfoQ. Some look eerily like Scrum boards, don't they?

Regardless of the column names, cards start out in the far left column and move their way to the far right column. The inventory of cards at any one category is controled by open slots within a category. For example, using the image with the multi-colored postIts, when a card is pulled from the To Do column and placed in the Doing column, it leaves an open slot in the To Do column thus a need for more To Do items to work on. Unlike Agile, Kanban does not bundle work into sprints. The flow is constant.

In my opinion, where Kanban is most effective is on larger projects where there are teams that make up "columns" of work. The image with the Waterfall style stages illustrates this best. A large project will likely have teams that make up Basic Design, Detailed Design, Development, and Validation. With Kanban, each team can set their capacity of work by the number of slots they make available. If the Basic Design team has 10 slots available then they are saying they can work on 10 basic designs at one time. Detailed Design may have only 7 slots, thus their capacity is 7 Detailed Designs at a time.

It isn't hard to imagine Agile teams using Kanban techniques to control the flow of work. A simplistic view is to wrap Kanban into iterations and you now have Kanban Agile. There are additional difference between Agile and Kanban and I provided a couple of links at the bottom of the page if you are interested in learning more.

In a previous article, The Convergence of Continuous Integration and Continuous Release, I discuss the merits of deploying to production immediately after code is checked in and all test are run and are successful. Kanban would work exceptionally well in this type of environment.

Whether it's Agile based on Kanban or another style of Agile, there is a consistent attribute of Agile teams; the Agile team needs to be composed of multi-faceted team members who are adaptive. As production velocity shifts across any or all categories of the project, team members should be able to shift into different roles accordingly, i.e. gathering requirements, designing solutions, developing software, and/or testing working code (or coding automated tests). Personally, I think this makes being a software development professional more interesting but it isn't for everyone.

Click here and here to read two good articles on Kanban as it relates to Agile software development.

I'm interested in your thoughts.

People, Processes, and Protection

I'm going to drift a bit from my typical subject matter and talk about the importance of managing people and processes for the protection of all involved.

You may wonder in what context the word protection applies. Protection is the obligation of managers to protect their direct reports, direct reports obligation to protect their manager, and everyone protecting their customers and organization. The glue that holds all of the various protections together is a codified set of processes. I know codification is optional, but to be great instead of mediocre, the processes need to be as well understood and unambiguous as possible thus documentation is required.

Example:

Background: A consulting company has a custom software development effort with their best client. The project is highly visible and the client's financial investment makes it high risk as well. Each two week development cycle has a scoped set of features that the development team commits to and at the end of which results in a demo of the working code to the customer.

Manager Protecting Direct Reports: The development manager works with the development team to scope the features to be developed during the current cycle. Each team member commits to one or more deliverables and provides their estimated level of effort. The development manager is doing his/her best to set up his/her reports to succeed by involving them in the scoping, assignment, and estimation processes.

Direct Reports Protecting the Manager: As the cycle progresses, each developer is cognizant of the commitments to the client and all of them know that no one likes surprises. When a feature is bigger than expected or unforeseen obstacles arise that threaten the ability to deliver the scoped feature(s), the development manager is notified as early as possible to allow him/her to manage expectations with those outside of the team.

All Protecting the Customer and Organization: Because the development team does a good job with making the manager aware of the risks as they become known, the manager can notify the customer as early in the cycle as possible. Once the risks are known they are managed throughout the cycle. This allows the customer contact to manage expectations at their end. A byproduct of being disciplined with this process of protecting the customer results in successful projects and enhancing the reputation of the development team and organization as a whole.

Team Value System

Protection and process is all great but those items don't define what is being protected and why were the processes developed. Before processes can be designed and implemented there needs to be a team value system. The value system consists of the things the team views as important principles that are required to be successful.

There are several steps required to crystallize the team's focus of its value system as well as defining who the team is, where it's going, and how it's going to get there. Each of the steps should align with the organization, cost center, department, team, and individual.

1. Vision and Mission Statements: The team needs to know unambiguously why it exists and where it is going. If you don't have them, then write them. You'll be surprised at how much thinking you'll need to do.

2. Team Value System: A team's value system is essentially the rules of engagement at the individual level. Here is a small example:

• Team First
  
  • We constantly strive for balance of skills throughout the team.
  • There is redundancy within the team, e.g. primary/secondary client contacts.
  • Choosing the right resource for a particular task/project is dependent on:
    
    • Task/Project Context
    • Required Skills
    • Desired career path of team members
• Communication
  
  • We err on the side of over-communication
  • We are collaborative with solving problems
    
  • Conversation is more accurate than written correspondence
• Customer
  
• Everyone is everyone’s customer
• Super-pleasing is the standard level of service

3. Team Composition: This is the act of documenting how your team should be assembled; essentially what is the strategy with regard to the the required skills within the team and how that manifests itself into the types or categories of people needed to most effectively perform day to day activities. I'd suggest categorizing your current team members into each of the types that you identify to see if you are aligned properly.

Protection Through Process
Once the three steps are complete it is time to create the processes that ensure the value system is efficiently implemented on a day to day basis - without significant dependency on human oversight. Heavy involvement by people to ensure the plan is executed daily is inefficient because of the transient nature of people, the periodic unavailability of people, the expense of human oversight, as well as a host of other reasons. Processes need to be developed in a way where, for the most part, the team runs itself. This paradigm is scalable. When specific people leave the organization or become unavailable for periods of time, the processes don't fall apart. It also leaves people more time for innovations that make the processes stronger.

Teams and its members have good intentions that sometimes go awry. In most cases when things don't go as well as expected it is because the team/individuals don't have a clear idea of their value system and/or poor processes that don't protect them. The idea is to consistently put people in a position to win. In my experience, implementing the tools described here help teams be the best that they can be.

I'm interested in you thoughts.

Agile Feedback Loops

One of the most important aspects of Agile is the feedback loop contained in virtually every aspect of the methodology and the built-in efficiencies related to it. I know I'm being Master of the Obvious, but knowing about a problem immediately and thus fixing it immediately is so much easier and manageable than untangling many problems that were unknowingly compiled over the course of months and with a short amount of time to straighten everything out. Aggghh .. it's stressful just thinking about it. Below are the places in the Agile methodology (or at least the way I have implemented it) where we see feedback loops.

Continuous Integration (CI)
When code is checked in, the application will successfully build or it will not. On my team, we get automated emails after the CI process runs regardless of success or failure so feedback is received in both positive and negative outcomes. The rule is - don't leave for the day until your checked-in code successfully builds and the unit tests succeed. When the CI process fails, it is the top priority of the team to fix it.

Nightly Build and Deploy
Every night the projects that make up the application are built and deployed to a distributed environment. During this process the compilation, automated unit tests and automated QA tests should succeed. If anyone of those processes has a failure, then, just like with the CI process, it is the top priority of the team to fix the failure.

Daily Stand-up
Every day the project team meets for 15 minutes where each member tells the their team members what they worked on yesterday, what they are working on today, and what obstacles they have. As a result, missteps in priorities is only a day away from being corrected and information about what someone else is working on that is pertinent to a developer is communicated every morning.

Sprint Retrospective
At the end of every two week sprint, the team discusses what they think went well and what went not so well. This feedback provides the necessary information to tweak our processes accordingly. Little by little our processes gets stronger.

End of Sprint Demo
This is where the rubber meets the road. At the end of every two week sprint we have an immovable demo to the client. What does our customer think about our work? Did we get it right or wrong or a combination? What insight is gained about the application as a whole as a result of this sprint's development and what is the effect on the priorities for future development?

I was in a client demo yesterday for Sprint 12 - thus it was my 12th demo for this particular project with 4 more to go - when I had a somewhat out-of-body experience. As we were nearing the end of the demo where I was peppered with questions by a room of 10+ client stakeholders asking "will it do this? will it do that" of which my response was "well let's see" (and in virtually all cases the app performed well), I mentally became detached from the demo process and saw the entire project life cycle in my minds eye and was stunned.

That's when I said to the group "Can you believe how well this is working? This is amazing." And, that's when they started making fun of me by asking me if I wanted to be carried around the room. By the way, having a demo every two weeks with your customer promotes a positive bonding experience (assuming the demos are successful).

The reason for my impulsive utterance was that after developing software for the better part of the last 15 years (a lot of which was not using Agile), I'm still stunned how well Agile works. Of course you need high quality developers too but the constant feedback loops and addressing issues immediately instead of during UAT is directly related to successfully demo-ing an application 12 times with minimal glitches.

Creating and Maintaining a Sense of Urgency

A consistent sense of urgency is one of the separators of great teams from all of the others. Urgency promotes teamwork, focus, efficiency, collaboration, pragmatism, vision, and all the other important characteristics of a highly productive team and project.

I’ve been on projects where the management team wanted desperately for our team to have a sense of urgency but was unable to create it – never mind maintain it. Assuming a project team is made up of talented people who enjoy what they do for a living then the reason for the lack of urgency falls on management’s inability to provide a conducive atmosphere to instill it.

Knowing the ingredients that creates a sense of urgency is the hard part. Actually creating urgency is simple. All it takes is a disciplined approach to process by management.

The key ingredient are:

• Short and tightly focused goals that roll into medium term goals which roll into longer term goals.
• Individual accountability.
• Visibility into the goals of the team and it’s individual members.
• Knowing the dependencies each member of the team has on one another.
• Everyone’s involvement with process improvement.

Every project already knows the long-term goal – deliver the product that is mutually agreed upon between the developers and customer.

Agile does a great job of providing the short and mid-term goals via the daily stand-up and sprints, respectively. At the beginning of the sprint, the development team provides a scope for the sprint, which is usually between 2 and 4 weeks at the end of which is a demo to show what was accomplished. What rolls into the sprints are the daily stand-ups. Each member of the team provides an update on what was accomplished yesterday, what’s planned for today, and any obstacles they have.

For as far back as I can remember, my father has always emphasized that “if you take care of the little things then the big things will take care of themselves.” The daily stand-up epitomizes this philosophy. If we strive to consistently accomplish our goals on a daily basis, then it’s reasonable to assume that we should accomplish the goals for the sprint. The same holds true for the relationship between the sprints and the project as a whole.

The tightly focused goals that revolved around the daily stand-ups and the sprints creates an environment where creating and maintaining a sense of urgency is built-in. The best part is that it is self-maintaining. It doesn’t require constant reminders and direction from management. The best processes are those that work on auto-pilot where a manager’s job is to nurture it, make sure the team stays disciplined to it, and looks for ways to improve it.

That begs the question – as a manager, how should my sense of urgency be created and maintained? That’s a blog for another day.

The Miracle of Agile

I am a disciple of Agile as a software development methodology for the simple reason that it was brought to Engineering teams through divine intervention. That statement might contain a bit of hyperbole but only a bit. Agile has revolutionized the way in which software is being developed by many teams across many industries though it is still unknown or a mystery to many more.

What is Agile? Agile is an iterative approach to software engineering who's precepts are: collaborative teams consisting of cross functional members; frequent validation of requirements, designs, and implementations; self organized teams; and, unambiguous individual accountability.

How is Agile different?
I'm sure everyone reading this has heard of processes such as requirements gathering, analysis and design, development, QA testing, and user acceptance testing. Agile as well as many of the tradition approaches, Waterfall being by far the most common, embrace these principles. The differences lie in the implementation of those principles. Where Waterfall will attempt to describe the the entire application upfront through documentation which is then followed by development, QA testing, and user acceptance testing, Agile bundles those principles into iterative life cycles called "sprints". Sprints are of a fixed duration, commonly between 2-4 weeks, and repeated over and over again until all the features are developed, the project budget is exhausted, or time runs out.

Plan-Driven (Waterfall) vs Value-Driven (Agile)
The way in which the principles are implemented is the manifestation of their difference in philosophy. Where waterfall is plan-driven, Agile is value-driven. A plan-driven methodology is heavy on documentation and strives to fully describe the application before developing it through requirements, analysis, and design. That process provides a framework to methodically develop what's been documented. Typically there is a gargantuan project plan that is associated with the effort and everyone marches to the plan with little regard for course corrections and re-evaluation.

A value-driven methodology stresses an empirical engineering process using an inspect and adapt approach with frequent feedback loops, i.e. sprints. The reason for this is that Agile believes that requirements gathering, analysis, design, development and testing should happen together when the feature is ready to be implemented. This approach provides flexibility with project changes such as feature deprecation, adding new features, and changing the requirements of existing features. As these events occur in a Waterfall project the documentation becomes cumbersome to maintain. The most efficient time to write about it is when it's time to develop it. During an Agile project, it's easy to make course corrections such as changing requirements as a result of what's been developed previously or a reconfiguring development priorities because of extenuating circumstances.

Although it's comforting to know that so much thought went into determining what the customer wants and how their requirements should be implemented, there are significant inefficiencies with the level of detail that goes into the upfront analysis. The reasons are simple, some of which are:

• Users aren't always clear in their own minds what they want and how they want it.
• Large documents are not handled well by many people. They tend to be too abstract for people to fully grasp.
  
• Things inevitably change in the minds of many users once they can see and feel their requirements implemented.
• The business environment often changes and directly impacts the priorities of the project.
  

In my mind, it makes perfect sense to get your customer to see and feel the application features as soon as possible. This doesn't mean abandoning requirements, analysis, and design. It just means that upfront planning should be limited to:

• Project Initiation: Planning the sprints, project infrastructure, team members, communication matrix, etc.
  
• Developing a Prioritized List of Features: This is a list of features, prioritized by importance, with user-stories on how the features will be used.
• High Level Architecture: A high level architecture should be developed. This phase determines things like the application tiers, technologies employed, thick or thin client, etc.
  

Once those steps are taken then development should start. I prefer two week sprints at the end of which my team gets immediate feedback from the customer. Catching mistakes with interpreting the user requirements, or users realizing that their requirements need to change is far cheaper to address at this point in development than at the end of the project during user acceptance testing. The recurring customer demonstrations also builds user confidence because they see progress. From the developer perspective, sprints provide a clear mission and the immovable customer demo at the end provides a constant sense of urgency.

Why isn't everyone doing it?
There isn't a single answer as to why everyone isn't using Agile but the most common is - you guessed it - resistance to change. Here are a few reasons for resistance:

• The Devil You Know: People are comfortable with what they know and uncomfortable with what they don't know. In my experience, once the change is made, most team members see more similarities to their previous approach than they thought were there otherwise. The apprehension of the change is greater than the actual change itself.
• Personal Fear: Can I do this? Will I like it? Will I learn it fast enough? Will I look foolish? How will my job be affected?
  
• Risk Aversion: The chances of switching methodologies without feeling some amount of pain is low. It will take at least one, but probably several, projects to change behaviors where Agile processes are implemented and feel natural. The speed of the transition is dependent on the fervency and commitment of the transition evangelist.
  
• Existing Team(s): Agile is highly collaborative and tends to minimize attention on documentation, thus an inherent lack of detailed specifications. If your projects rely heavily on coding to specs, then the transition to Agile could be challenging. However, if your team is already working from prototypes, has close involvement by the customer, and is highly communicative, then you are already working in an Agile-like style and the transition will likely provide change in the form structure not in approach.
• The Iron Triangle: There is contention with each side of the iron triangle - features, cost, and schedule - and it is virtually impossible to fix commitments to all of them simultaneously. Agile makes clear that commitments can only be applied to a maximum of two of the sides. One side always needs to be fluid. For example, company x has a demo at a convention in 3 months where it must show y set of features, therefore the the schedule and scope are fixed so the cost needs to be variable. With Waterfall projects the commitments to date, scope, and budget are typically, and irrationally, fixed at the beginning of a project. This makes people feel comfortable. However, in reality one or more of those commitments will inevitably be violated because it is unlikely that enough is known to allow for committing to all three.

Although it is unlikely that Agile was brought to us through divine intervention, the genius in it's approach makes me wonder what took so long to get here.