This post originally written by Mike Cottmeyer for Agile Chronicles, August 2008.

Back so soon? I told you guys it was time to get this knocked out! Last post we talked about Quality Management, this post we are going to hit Human Resource Management.

According to PMI, Human Resource Management includes the processes that manage and organize the project team. Pretty simple huh? This is an interesting topic because we generally want agile teams to be self-managing and self-organizing. Do we throw this one out all together? Is there any way we'll be able to bridge the gap?

I've got to honest with you guys, I am not exactly sure where this one is going to end up. Let's jump in and see what we can do.

Human Resource Planning

PMI Definition:  Identifying and documenting project roles, responsibilities, and reporting relationships, as well as creating the staffing management plan

Does a RACI diagram have any place on an agile team?

Agile tends to assume that you are staffing your team with specializing generalists. What is a specializing generalist you ask? These are people that may have specialization in a given area but are willing and able to operate outside their area of specialization.

Specialization is problematic because it leads to matrixed organizations. If a specialized skill set is required only part of the time, we need to find something else for that person to do with their downtime. Organizations end up filling that downtime with other project work. The problem here is that working on more than one project dilutes focus and creates artificial dependencies between projects. Real dependencies are one thing, self imposed dependencies are quite another.

Specializing generalists allow me to have a single person do more than one kind of work, eliminating constraints, and reducing the need to matrix people across multiple projects.

Teams work best when they stay together and are all focused on a common objective. They establish a stable throughput, they trust each other, they understand how to work together. Agile values continuity and it's part of what keeps agile teams fast and lightweight. This is a very difficult, if not impossible, to achieve in a matrixed organization.

That said, we still need to know overall what skills are required. We need to do the necessary due diligence to make sure that our team collectively has the competencies required to deliver. We need people that can potentially fill several roles on the team. If a RACI diagram helps you figure that out… go for it.

Acquire the Project Team

PMI Definition:  Obtaining the human resources needed to complete the project

After giving this one some thought, I don't think agile has much to say here or much overlap with PMI. I'll just take this opportunity to restate the importance of building teams with specializing generalists. Getting the right people on the bus makes all the difference.

Develop the Project Team

PMI Definition:  Improving the competencies and interaction of team members to enhance project performance

Agile teams improve competency through collaboration and teamwork.

How does collaboration and teamwork come into play on agile teams? Most teams will have a mix of senior people and junior people, people who are better in one are of the application than in another area of the application. Agile encourages close collaboration amongst team members, pair programming, and shared ownership. It gives everyone the opportunity to broaden their skillsets, learn new technologies, and become proficient in areas of the application they might not otherwise touch.

Daily standup meetings keep people involved and connected with each other. Retrospectives help the team learn from each other and decide how to work together more effectively. Creating this collaborative learning environment is one of the reasons that collocation is such an important aspect of building agile teams. Agile leaders value team building and collaboration so much, they tend to focus more energy on activities that give opportunity to develop closer interpersonal relationships.

If your team members lack a particular competency, and no one on the team has that skill, training one or more folks becomes a critical success factor. Make sure you have that time and money in your overall project plan for formal training.

Manage the Project Team

PMI Definition:  Tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance.

Ideally we want our teams to be self-managing and self-organizing. Give people the objective and get them the environment and the tools they need to deliver. The agile project manager can play a huge role in creating the kind of environment for this kind of behavior to emerge.

An agile PM needs to lay out the vision, make sure the team has the necessary skills to do the job, layout the initial planning structure, establish the metrics, and support the team by removing the things that get in their way. Part of establishing structure is keeping things visible and maintaining a culture of accountability. Iteration planning, daily stand-ups, product demos, and retrospectives help create this culture.

As an agile PM, I almost always track project burndown, iteration burndown, defect trends, and historical velocity. These metrics, in conjunction with the daily standup, usually give me a pretty good idea of how the team is doing. There have been times when I have needed to track individual hours and individual velocity but these cases should be the exception to the rule.

Agile definitely puts more emphasis on leading the team over managing the team. The reality is that sometimes your team is not healthy and mature or in a good place to manage themselves. A good manager, with a focus on servant leadership, can help create an environment where teams can thrive and people can learn what it means to take full ownership of project outcomes.

Now if we could just get PMI to stop calling our team members Human Resources!

Over the last few years I’ve had folks from various roles on agile teams ask me if I thought it was important if the stories in a sprint backlog were executed on in their rank order of importance, because "after all, the team made the commitment and they should be delivering the entire backlog during the Sprint." Recently I heard the previous quote from a CSM so I thought I would set the record straight based on my experience with Scrum software development.

In the application of Scrum I've seen over the years, I would say that it actually is important that teams respect the order of ranking of stories in the backlog when executing. It is the tasks and tests of a story within the backlog they can work on in the order they want.  The reason for respecting the rank is that otherwise, too often you get teams that spread out over all the stories at once. The sprint team’s burndown chart will show the team burning through all their hours, but their cumulative flow graphs show little to no value being earned.  Many times this is a sign that the team is doing mini-waterfall within an iteration. Try applying WIP limits across the the team’s value flow and very soon you'll see the importance of executing in rank order when you're trying to maximize the value out of flow.

In my real world experience working with clients, the ideal of an uninterrupted sprint for companies that have substantial technical debt in the wild is not the norm, it is the exception and these organizations require approaches that can more gracefully handle escalations. I know that this is against "Scrum religion" but ideals are more easy to talk about than to practice, and the focus is usually to aspire to the preached doctrine. That is why we have retrospectives :-)

This post originally written by Mike Cottmeyer for Agile Chronicles, August 2008.

Okay… it has been a while since my last installment in this series. Aside from my general inability to stay focused on a single topic (what was I thinking committing to a nine part series) I got really swamped preparing for Agile 2008. I've got two talks coming up in November on this material, one of which has a presentation due in early September, so I guess it is time to get busy and get this series wrapped up.

Last time we covered Communications Management, in this post we'll discuss Quality Management.

As always, let's start with the PMI definition of Quality Management. According to PMI, Project Quality Management includes all the activities of the performing organization to determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. There are three processes included in this knowledge area: quality planning, perform quality assurance, and perform quality control.

If you've been following this series, you'll know that my general approach with the PMI is to take guidance from the PMBOK and figure out how to satisfy the intent of the process with a more agile practice or principle. Agile is all over quality planning, quality assurance, and quality control but we often use different language to describe how we satisfy these objectives and we often plan for these activities in a pretty different way.

Let's see what we can do to bridge the gap...

Quality Planning

PMI Definition: Identifying which quality standards are relevant to the project and determining how to satisfy them

Quality planning is really about the initial set of assumptions (we make as an agile team) about how we are going to manage quality on our projects. As it relates to developing software, quality planning has mostly been done for us… it is implicit… it is understood by virtue of the fact that we are using an agile methodology.

When we have discussions about doing test driven development, pair programming, or continuous integration; we are making decisions about how we are going to handle quality. The decision to make use of acceptance criteria is simply a decision on how we will know we have met the requirements of our stakeholders.

Are we going to do unit testing? How about manual regression? Will we need to test for performance, scalability, or security? How will we know we have met any applicable regulatory or audit requirements? I would venture to say that most agile teams are having these conversations. Even if your team is not writing this stuff down or getting sign-off, you are implicitly developing your quality plan.

It is up to the team to balance how much of this needs to be documented. Ask yourself to what degree will a document facilitate understanding or help with stakeholder communication? Consider how much documentation is required by your organization. Keep things simple, minimally prescriptive, and make provisions to adapt your plan as you learn more about the emerging solution.

Perform Quality Assurance

PMI Definition: Applying the planned, systematic quality activities to ensure that the project employs all processes needed to meet the requirements

You've made some initial decisions about how your team will meet the quality expectations of the organization… now it is time to execute. Quality assurance is about making sure we are building the right product from the very beginning.

Early in the iteration, we meet as a team with our customers to define exactly what is to be built. Every role on the project has the opportunity and is encouraged to be involved. There are people looking at the requirements from every conceivable angle: system architecture, development, QA, analysis and design, and usability. We explore the problem from all perspectives, before we set off writing code, to ensure we are building a complete product.

Once we get started building out the features, we immediately execute our testing plans. At a minimum, agile teams are writing unit tests and doing continuous integration. We know at every moment of the project how well the code is performing against the requirements.

If your team has dedicated QA members, the QA folks are testing right along with the development team. Sometimes it is more exploratory and we are not looking for sign-off, we are really looking for feedback. Feedback from the QA team is essential to making sure that the product is evolving according to the quality standards we agreed to at the beginning of the iteration.

The team holds itself accountable by meeting in a daily standup. This allows the team to stay plugged in, assess progress, and identify impediments. In addition, the team has constant access to the product owners. This constant visibility allows the customer to fine tune the solution, as it is being built, to ensure that the product will meet market requirements.

Perform Quality Control

PMI Definition: Monitoring the specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

Even though quality is the focus from the very beginning in an agile project, we still seek to validate outcomes and formally track the quality of the product we are building.

The advantage of automated testing is that we know the health of the product in real time. We are able to measure and track defects and get them resolved as soon as they are introduced into the build. Manual testing, in parallel with the automated testing, gives a more intuitive way to exercise aspects of the code the are difficult to automate.

As a project manager I am constantly tracking burndown at the project level to see how well the team is doing against the backlog. Within the iteration, I am tracking task progress to make sure that we can deliver on our commitments. Agile teams also track defects, defect status, and test trends. All this gives the team a way to continuously control the project quality.

Agile teams don't wait until the end of the project to test, when we have the least amount of time to actually fix a problem, or respond to a change. We know at all times the health of the project, if the team is burning hot, if defects counts are trending up or down, how well we are resolving issues, and if those issues are becoming impediments to getting new product built.

Agile teams review features with their customer as they are completed. They do formal product demonstrations and retrospectives at the end of every iteration. These processes allow the team to control, not only the quality of the emerging product, but also of the processes we are using to deliver that product.

All of this feedback gets folded back into the plan, adjustments are made, and the team adapts based on what they have learned from regularly delivering code.

Next up… Procurement and Human Resources.  We'll save Risk Management and Integration Management for last!

This post originally written by Mike Cottmeyer for Agile Chronicles, July 2008.

As promised… next up we're talking about Communications Management.

According to PMI, Project Communications Management employs the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. This knowledge area provides the critical links between people and information that are necessary for successful project communications.

There is a neat little book by Andy Crowe called "Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not". This book surveyed over 5000 project managers to find out what the best project managers are doing differently. One of Andy's conclusions is that top project managers spend significantly more time communicating than their less successful brethren.

In some cases these top project managers spent up to 90% of their time communicating in one form or another. I have to say, that is certainly consistent with my personal experience. If something is going wrong on one of my projects, it is usually because people are not talking to each other.

But maybe I am taking a naïve view of what it means to communicate on a project? It seems to me that the PMI definition of Communications Management is a little broader than just making sure the team is talking to each other. Communications management deals with documents and plans and stakeholders. Communications management is really about managing the flow of information.

Since it's common knowledge that Agile teams don't do documents, I am guessing we have some work ahead of us to reconciling these points of view.

Okay… I was kidding with the Agile documentation comment. That said, there is clearly a difference in how these two project management perspectives treat the issue of documentation, reporting, and even interpersonal communication.

Both PMI and Agile have quite a bit to say about how to manage project communications so let's get started.

Communications Planning

PMI Definition: Determining the information and communication needs of the projects stakeholders

When Agile teams talk about communications, they are usually talking about communications within the team. Agile puts a great deal of emphasis on the free flow of information between team members, between team members and the product owner, and even between the team and the direct customer. In some ways, the Agile community has really abstracted the entire stakeholder community behind the role of Product Owner.

Communication between team members, and between the team and its customers, is essential but it is not the only component of communication that must be planned. Sometimes there are other stakeholders that we must take into consideration.

At the team level, we usually deal with team member communication through collocation, whiteboards, wikis, and other rich and collaborative workspaces. Agile teams trade a great deal of written documentation for these more osmotic forms of information exchange. On a small team with a single customer, it might be sufficient to suggest that customers get all the information they need from attending planning meetings, daily stand-ups, and iteration reviews.

When there is more than one stakeholder, or possibly a hierarchy of stakeholders , sometimes it is not sufficient to suggest that these stakeholders come down to the team room and check out the team's progress on the Kanban board. Sometimes we need to do some roll-up reporting across a portfolio of projects or even programs. Sometimes we need to report status at a much higher level of abstraction for a more senior audience.

The key to planning communications on an Agile project is to follow the principle of simplicity. Don't write documentation for the sake of documentation. Find out what your stakeholders really need and provide it as quickly and as simply as possible. Make use of natural information sources that the team is already producing (task boards, burndown charts, architectural representations) and create documentation that enables your business to make decisions.

Keep things light, go for face to face whenever possible, and when your stakeholders require more; make things as simple, clear, and accurate as possible.

Information Distribution

PMI Definition: Making needed information available to project stakeholders in a timely manner

At the team level, information distribution focuses on those rich channels of communication I mentioned in the last section. Agile teams keep their status up to date using large, visible information radiators that everyone in the team room has access to and can update themselves. These repositories of information are there for the team to know where it is at all times and so they can manage their work. The side effect of these radiators for the Project Manager is that you have instant access to real time information about the health of the project, release, or iteration.

Often, design and architecture will be worked out on whiteboards and then minimally documented on a Wiki or Sharepoint so they can be easily changed as we learn more about the evolving system. Agile teams lean toward lightweight artifacts and central, universally accessible document repositories. Agile teams recognize that the only truly accurate representation of the product is the code itself ; therefore documentation is kept light and at a pretty high level.

Sometimes a customer has a need for more detailed documentation to manage an external dependency or possibly an audit requirement. In these cases, that increased level of documentation is built into the estimate for the feature. Documentation is not free and it will slow down the creation of working software.

The key once again is to figure out what is the minimum amount of documentation needed to satisfy the requirement. Document systems at the highest level of abstraction you can get away with. Make sure you understand the information needs of the external stakeholder, make sure that work is represented in the backlog, and that it is prioritized to meet the needs of the organization.

Use the same collaborative techniques you would use to build features to create the documentation required by the business.

Performance Reporting

PMI Definition: Collecting and distributing performance information.  This includes status reporting, progress measurement, and forecasting

Okay… so we've already talked about things like burndown charts and Kanban boards. These are tools that a team will use to organically manage their work and make sure they are on track. As an Agile project manager is your responsibility to help the team and encourage that these tools are kept up to date. For the most part, these are the only tools you will need to understand the health of your project, and you largely get them for free.

Performance on Agile projects is pretty simple. You know how big your backlog is and you know how much you are able to complete each iteration. Based on these two variables you are able to predict how many features you will be able to complete before the end of the project, release, or iteration. I personally like to keep a high level project roadmap that helps me understand where the project is expected to be at certain points as it progresses to completion. This is also useful for managing external dependencies.

These simple tools help you understand what progress you are making against expectations and if you'll need to extend the release, adjust scope, or request additional funding. Since you are an agile team, you'll more than likely be communicating how early you'll be, how much more you'll be able to do, and how much more value you've delivered to the organization.

Either way, you have a tremendous amount of information at your disposal to communicate project to the project stakeholders. Think EVM based on delivery of working product.

Manage Stakeholders

PMI Definition:  Managing communications to satisfy the requirements and resolve issues with project stakeholders.

Managing stakeholders is really about managing the issues that come up during the life of the project. A significant benefit of Agile is that nothing is hidden. This level of visibility gives the project manager the information they need to resolve problems and remove impediments.

Issues can arise during iteration planning, execution, closedown, or just in the course of day to day work. Just like on any project, these need to get tracked and dealt with as soon as possible. Issues are reviewed during the daily stand-up meetings and retrospectives.

There are always going to be some issues that cannot be dealt with by the team. I typically hold a weekly or bi-weekly meeting with senior stakeholders where they get a distillation of significant impediments and what I need them to do to help me resolve the issue.

It is my opinion that stakeholders need to be managed and issues resolved no matter what your software development methodology.

I think that does it for this installment. That was much longer than I had expected. I figured communications management would be one of the easier topics to discuss. Maybe I just need to go home for the day.

Let see… next up… Quality Management.

This post originally written by Mike Cottmeyer for Agile Chronicles, July 2008.

Okay… let's get back to our discussion on how to look at the PMI knowledge areas from a more Agile point of view. Last time we tackled Cost Management, this post let's look at Scope Management

According to the third edition of the Project Management Body of Knowledge, Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. PMI states that project scope management is primarily concerned with defining and controlling what is and is not included in the project.

I find it a little entertaining how these statements seem to be universally interpreted as "define everything you are going to do up front and make sure you deliver what was originally defined". While that may have been the intent of the PMBOK Guide, some projects don't lend themselves to that kind of up front planning. Some projects must allow for discovery. Some projects must adapt to changing markets, or at the very least, adapt based on the teams understanding of the emerging product.

For some of us working in more dynamic problem domains, ensuring that "the project includes all the work required", is a process of discovery. Controlling what is included, and what is not included, is an ongoing concern rather than something done once for the entire project. We need a project management framework that embraces this uncertainty rather than wishing it away or pretending it doesn't exist.

I am becoming convinced that Project Managers default to this static point of view because we have never been taught another way of managing projects. We just don't have the tools to deliver projects any other way. So… that said, let's take a moment to look at the PMI Scope Management processes from a more Agile point of view. I bet we find another way of approaching Scope Management that does not involve defining everything up front and then locking it down for the duration of the project.

Scope Planning

PMI Definition:  Creating a project scope management plan that documents how the scope will be defined, verified, controlled, and how the Work Breakdown Structure will be created and defined

Agile project management practices are really the embodiment of a scope planning approach. As a project manager, especially a traditional project manager making the switch to Agile, I have no problem documenting this for my organization. An Agile Scope Management Plan is going to address things like creating the backlog, characteristics of a good backlog item, how we are going to establish velocity or throughput, how we are going to measure burndown against the backlog, and how we are going to deal with changes to the backlog.

Scope Definition

PMI Definition:  Developing a detailed project scope statement as the basis for future project discussions

Scope on an Agile project is defined in the product backlog. The backlog is a listing of the features that your product owner would like to have included in their project. One of the most important considerations to keep in mind is that every item in the backlog should be independent of each other. This is the secret sauce that makes it possible to reprioritize and make changes on the fly. Bill Wake has a great explanation of what makes a good backlog item on his website.

Rather than looking at the product backlog as a static indicator of what WILL be built, look at it as the baseline for further adaptation. It is expected to change as we learn more about the emerging product.

Create WBS

PMI Definition:  Subdividing the major project deliverables and project work into smaller, more manageable components

This is one of the toughest things for traditional project managers to get their heads around. There is no WBS on an Agile project, at least not one in the traditional sense. From the Scope Definition section, we learned that our backlog represents the scope of the project and that each of the backlog items should be independent of each other. Independence is key because it allows us to do just in time scheduling.

Agile projects are broken down into smaller projects called releases. Project releases are broken down into smaller time-boxes called iterations. Content is pulled into a release just prior to its start, and only as the previous release is winding down. Likewise, content is only pulled into the upcoming iteration as the previous iteration is coming to a close. The idea here is that we are going to review what the team was able to complete and make decisions about the next increment based on what we learned from delivering the previous increment.

As an Agile Project Manager, I am generally comfortable laying out a high level plan to understand where I expect to be at certain points in the project. I am also comfortable keeping a chart of external and internal dependencies to help manage commitments. The key is to use these as guidance for decision making and indicators of progress. Problems arise when these tools restrict our ability to learn and adapt to the realities of our projects.

Scope Verification

PMI Definition:  Formalizing acceptance of the completed project deliverables

Each iteration we will decide the next best increment to build and then review the outcome once we are complete. The stakeholders either accept or reject the outcome of the iteration and work with the team to decide the next best set of features to build.

Because we want to maintain the ability to adjust the product as we learn more about the emerging solution, we focus on making and meeting commitments in smaller increments. Scope verification is done based on the outcome of these small increments of product and how they align with the product vision and the goals of the release.

Scope Control

PMI Definition:  Controlling changes to project scope

Agile teams take a value driven approach to delivery rather than an activity based, or even deliverables based, approach to delivering projects. The product owner can change the scope of the product at will, but is always focused on delivering the most value possible given the available times and resources.

Agile teams give the product owner a tremendous amount of discretion over how the system is constructed and even accommodate changes even late into the life of the project. It is understood by Agile teams that changing scope involves tradeoffs. The product owner is substituting features that add greater value for those that provide less. To add one thing, something often has to be taken away.

Next Up…  Communications Management.

This post originally written by Mike Cottmeyer for Agile Chronicles, June 2008.

Next up is cost management. According to PMI, cost management includes the processes involved in planning, estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. This knowledge area only includes three process, but as you might expect, we are going to put a little different spin on them and see what we can do to make them more agile.

Cost Estimating

PMI Definition: Developing an approximation of the costs of the resources needed to complete the project activities

We discussed in the last post that agile projects typically start with time and cost as the primary constraints and float scope through the life of the project. While this is true, there should always be some sort of assessment at the beginning of the project to determine what value the customer might expect at what level of investment.

The product owner might approach the team with a high level backlog of features that need to make the next release. The team would then estimate the backlog and calculate how many iterations they expect the work to take. There would be a negotiation of scope, team composition, and release duration as everyone comes to consensus around what is possible.

The cost of the project is then established as the product of team size and project duration.

Cost Budgeting

PMI Definition: Aggregating the estimated costs of individual activities or work packages to establish a cost baseline

Agile teams assess the relative size of each item in the backlog. Some teams also put a numeric value on the expected ROI of each feature in the backlog. In aggregate, the size of the backlog determines how many features can be delivered and thus the overall value of the release. Because costs are assumed to be a constraint, cost budgeting on an agile team is much more a statement of how much value can be delivered, over the life the project, for the approved budget.

The budgeted amount of value for the project is represented in the release backlog.

Cost Control

PMI Definition: Influencing the factors that create cost variances and controlling changes to the project budget

With the cost of the project now established as a project constraint, agile project are not nearly as concerned with controlling the costs and variances of individual work items. Agile teams are most concerned with how quickly the project begins delivering value and at what rate. We need to monitor how well we are delivering the anticipated features and if we have deviated from the rate we had originally expected.

If the project is not progressing as well as we might have hoped, we may need to remove less important features from the backlog. This will decrease the value to the customer and implicitly increase the cost per feature. If the product owner chooses to extend the duration of the project, to realize all of the anticipated value, this would increase the real costs to the project.

Delivered value is tracked primarily by measuring project burndown. Here we assess the total value of the release, what value the team had expected to deliver at the end of every iteration, and compare the actual value delivered against the ideal.

By monitoring project burndown the team can assess and control the cost impact to the overall project.

Next up... Scope Management.

This post originally written by Mike Cottmeyer for Agile Chronicles, June 2008.

The first knowledge area we are going to tackle is Time Management. According to PMI, time management involves those processes that contribute to the on-time completion of the project. This knowledge area includes six project management processes designed to accomplish this goal. We'll explore all six and see how we can adapt these processes to make them a little more Agile.

Activity Definition

PMI Definition: Identifying the specific schedule activities that need to be performed to produce the various project deliverables.

To make this process more agile, you first need to think in terms of defining the features of the system, not the activities. Up front we want to know how the system is going to behave. These feature specifications need to be small and independent of each other. Agile teams usually call these features a user story or a backlog item. Collectively the list of product features is called the product backlog. The backlog represents the scope of an agile project.

Activity Sequencing

PMI Definition: Identifying and documenting dependencies among schedule activities

While discussing activity definition, we stated that the backlog items need to be independent of each other. The reason they need to be independent is because we want to have the ability to change requirements as our understanding of the evolving system changes. By definition we are seeking to minimize the dependencies between the work items on our project. Sequencing on an agile project is based less on dependencies and more on risk and business value. We want to focus on sequencing based on which features are going to reduce the most risk and deliver the most value as early in the project as possible.

Activity Resource Estimating

PMI Definition: Estimating the type and quantities of resources required to perform each schedule activity.

In traditional project management approaches, we are usually trying to determine the type and quantities of resources when we know the least about what it is we are going to build. Spending time and money to get a better understanding of these variables is not going to yield a substantial return. Agile approaches use a technique of estimating that relies on the collective understanding of the team to determine a relative size estimate of the feature, often measured in units such as story points or ideal engineering hours. These units only asses the size of the feature relative to the other features in the backlog.

Activity Duration Estimating

PMI Definition: Estimating the number of work periods that will be needed to complete individual schedule activities

We've discussed that each feature in the backlog needs to be small. Our goal is to have every backlog item small enough that it can be delivered within a single iteration. Agile teams build in this constraint and then measure how many features they are able to complete in a given iteration. By measuring how many story points, or ideal hours, they are able to complete each iteration, the team can predict how many iterations it will take to complete the backlog.

Schedule Development

PMI Definition: Analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule

Typical agile projects begin with a time constraint, iterations are fixed periods of time and release schedules are usually established at some fixed interval. Each of these are set by the team and the product owner, but once set do not change. That language might sound a little strong but agile is about building trust with your customer. Good agile teams can always make their date, it is the scope that will vary.

Schedule Control

PMI Definition: Controlling changes to the project schedule

Because the iteration and release timeframes are fixed, it all comes down to a discussion around scope. These discussions are a constant collaborative effort between the product owner and the team. The product owner always has the option of adding additional iterations to include more features. Because the features are discrete, and the team is always working on the highest priority features first, the product owner also has the option of calling the project complete at the end of any iteration.

As always, if you think there is anything I left out, or should have dealt with in more detail, please let me know via response to this post. I speak on this subject quite a bit so anything you have to contribute to make this brief explanation more understandable would be really appreciated.

Next up we'll deal with cost management processes.

This post originally written by Mike Cottmeyer for Agile Chronicles, May 2008.

In software engineering, refactoring a module of code means that you change its internal workings while leaving its external interfaces intact. A developer might do this to make the internal workings of their software simpler, more efficient, or easier to understand. The key is that refactored code maintains it's contract with the surrounding system. Everyone can still get what they need from the refactored system component in exactly the way they have always gotten it.

There is something here we can draw from as project managers. As we make the switch to agile project management, we must stay plugged in with the language of the organization. We need to maintain the contract the business has come to expect. Over time we may be able to influence how our organizations think about project management best practice. At some point we may even be able to renegotiate the contract.

For now, we need to take what we know about adaptive and traditional project management and establish a framework for delivering in the language of the business. The PMI process groups and knowledge areas provide a well thought out and disciplined foundation on which to build. Our challenge is to approach the discipline of project management with an agile mindset. To figure out how to leverage agile practices within the constructs of the accepted project management best practices.

Over the next few posts we'll break down the PMI process groups, knowledge areas, and processes to explore how we can build an effective agile framework using the established contracts.

This post originally published by Mike Cottmeyer for Agile Chronicles, May 2009.

Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves"

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take...

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it.

My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

When I first read The Checklist Manifesto by Dr. Atul Gawande it got me thinking about a checklist that could be effective and easy to use by my clients to help determine if a change they were considering making to a policy, a procedure, an organizational structure, facilities or a practice would improve their level or agility or impede it.

I thought I'd share my Agile Scaling Checklist with you to help the community, but also to start to get some feedback on it so that it may be further improved.

To utilize this checklist there are a few basic theorems that you should understand and agree with, otherwise you may not think the checklist is that helpful.

• Concept #1 - The most valuable quality of a software development organization is predictability in terms of time and quality.  This is true whether you are in an IT department producing systems for internal customers or at a commercial software company.  It is even more important in the commercial software development setting.  Much goodness flows from such predictability.  One of the most important benefits IMO, is that it fosters trust within the organization, with customers and with Wall Street.  Trust is the lubricant which makes teams, especially cross-functional teams, work more efficiently and effectively together and fosters continual process improvement.
  
• Concept #2 - Agile transformations require systems thinking.  When planning and making changes in an organization, you need to be aware of how one change will affect other aspects of the system or how one change can require changes in other areas of the organization to be successful.  This may sound like common sense, but it is shocking how few people take a holistic or systems view of their work, their life and the planet.
  
  One of my favorite organizational examples of this is an organization that begins touting the importance of cross-functional teams of people working as teams and delivering as teams, yet the incentive policies of the same organization reward individual performance and heroics - the "rock star" and "firefighter" mentality.

Ok, so if you accept these two concepts then I believe this checklist will be useful to you.

Consider this checklist as a tool for assessing whether an action is conducive to your successful agile transformation.  I like using it as a legend for documents / emails that propose changes that may affect the agile adoption. If a change doesn't improve one of these facets of an effective agile organization then you should really question why you're doing it. Of course you also don't want a change that improves one while lowering others for a zero or negative net gain. But it should be understood, there is always give and take. This is why it is so important to have systems-oriented thinking when considering the impact of a change.

 
Agile Scaling Checklist

___ Trust

___ Collaboration

___ Transparency

___ Empowerment

___ Continuous Improvement

___ Simplicity

 

In my experience these are the key ingredients for a team / organization to reach predictability in terms of time and quality.

Let me explain a bit about each of the elements in this check list.

• Trust: Trust fosters open communication, and open communication increases the level of trust. If nurtured, trust continues to grow in this cycle.  Of course trust is a fragile thing, especially when you add variables like distributed agile teams where you lose the benefit of receiving the full meaning of someone's message through their verbal and non-verbal communication.  Having an environment where it is safe to ask "why?" requires trust in management.  More on why this is important in a bit.
  
• Collaboration: Successful agile organizations have cross-functional, highly collaborative teams.  This results in engaging more of the skill sets involved in software product development earlier in the process.  Not only is the efficiency of the team improved, but also agile development practices such as TDD enable a team to be more effective at validating what they are building. This helps to ensure that the product is what the customer wants and that it delivers to the conditions of satisfaction.  And let's not forget that sometimes over-used word, synergy.  Highly collaborative agile teams can enjoy a level of output that exceeds what the individuals on the team could accomplish on their own (just think back to waterfall, serialized, functionally silo-ed teams).
  
• Empowerment: This covers the areas of self-organizing and to some degree self-managing teams. These elements of an Agile Team are what make it capable of working efficiently with crisp decision making. Empowerment is also at the foundation of emergent design which to my experience is the most effective form of design because it adds the lean element of “last responsible moment” decision making. An empowered team has the necessary authority to realistically support their commitment to delivering a product backlog.

• Transparency: Agile teams that keep their current state of progress against a backlog visible on a day to day basis give the team and the organization the ability to see, as early as possible,  when trends in the basic metrics begin going in the wrong direction.  This ensures that the organization has the maximum number of options at its disposal to address the issue.  Teams that do not have transparency only communicate their problems when they reach the end of an iteration (or worse, release). At that point, the organization has no options to correct for issues, and the one option left is usually taken: Look for someone to blame - the blame game (truly a trust killer).
  
• Continuous Improvement: Agile development processes are learning processes, so a key ingredient for success is a Plan-Do-Check-Act cycle within any process.  Actions that dismiss or defer this cycle are damaging to a successful agile adoption.  Trust is woven in the fabric of continuous improvement as well; without it, getting to the root causes of issues can be challenging, and just treating symptoms of issues frequently doesn't result in improvement.  Therefore once again we see the inter-connectivity of these ingredients.  Actions that damage trust will likely reduce the effectiveness of continuous improvement activities.  I mentioned before about the importance of having an environment where it is safe to ask why.  Asking why is at the heart of continuous improvement.  If there isn't trust established both within teams and between teams and management that it is safe to ask "why," this will impede continuous process improvement.
  
• Simplicity: This comes back to one of the principles found in the Agile Manifesto.  Simplicity is the art of maximizing the amount of work not done.  This applies in prescribed processes for requirements gathering, analysis and design as well as project management, coding and testing.

With this understanding of the Agile Scaling Checklist, I encourage you to give it a try and see how balanced your systems thinking is when proposing changes.  If anything it will draw you more into systems thinking, which in my experience can only be a good thing.

I will continue to post as the checklist evolves... Enjoy!

I've used this theme before but I need to once again give my nods to Buffalo Springfield.  It is absolutely time we "Stop Children, what's that sound, everyone look whats going down..." 

I get involved in a heck of a lot of discussions about agile development and the methodologies that have grown from agile.  In my travels around the world as an agile coach, I've met a lot of people that have interesting takes on what agile is.  What seems to be missing in most of these discussions is the theme of *programming*.  We talk about how to convince the executives it's worthwhile.  We talk about how important a rhythm is.  We have lots of discussions about what user stories are and how big or small they should be.  But we don't talk about the code!

Now it is time for me to interrupt this rant with a couple of caveats and disclaimers.  I believe very stongly that agile methods require discussions about project management.  I believe strongly that we need to understand what stories are and how to create them.  And I believe with every fiber of my being that one thing that differentiates agile software development from all other forms is that the value of all members of an agile team is recognized, not just one particular role. 

The fact that agile has "elevated" the other roles to the same level as programmers is a good thing.  But have we gone too far?  Have we now gone to the extent that we are, in essence, focusing on everything except programming?  I believe that we have. 

Let's go back and consider what it is that makes agile special.  We believe that change, even late in a project, is something to embrace, as it will add value to our customer's final product.  We encourage customers and stakeholders to constantly review the priority of their stories and re-sort them.  We state that we will only sign up for stories that are sized in a way that they can be complete in a single iteration.  These are all good things, but they are predicated on one basic fact:  The code has to uphold these changes.

Back in the early days of Extreme Programming, many of us were getting very excited because we had finally found a process that got the programmers in touch with the customers.  We found that we can embrace change, because we are producing high quality software in small increments.  This software is covered by automated unit tests so that if we want to change something, we can feel comfortable that the tests will catch any egregious errors.  It is the very presence of these programming activities that make agile development work. 

And yet, as I visit with clients and join in discussion groups, I am surprised by the absolute dearth of discussions about programming.  I see teams that are 100% on the mark with all of the project management techniques in agile, and yet do none of the programming techniques.  And guess what?  They aren't seeing a huge increase in benefit. 

So let's renew our commitment to great software.  Let's keep doing the agile project practices that we hold near and dear to our hearts, but let's also focus on how can we write the best, cleanest code possible.  How can we make this code so cohesive yet loosely coupled that it can be changed at the drop of a hat?  How can we write code that will be so easily readable that *anyone* on the team can pick up any story and implement it, without having to rely on an expert or the original author?  And for heaven's sake, let's make sure that the code we write does what the customer wants.  After all, the customer really doesn't care what processes we used, they just want software that does what they need.

Communication is one of the most underestimated of the XP values.  The value of communication is not underestimated, so much as how hard it is.  There are many different ways to believe we are truly communicating, but they so often fall short.  When we are talking about software development,  we have even more communications models to consider.

One of the most obvious is face to face, just plain talking to each other.  I still feel that this is the best, most effective way to communicate.  This is why co-located teams are always the preferred mechanism for agile development.  Not only are we able to have a real-time understanding of what someone is saying, we are able to pick up on subtle body language and nuance that may or may not come out in the written form.  When communicating face to face, we still need to be aware of what we are saying and how we are saying it.  We still need to do our best to remember the context around the conversation, and ensure we are actually hearing what is being said.  I have many times had a conversation where I reflected back what I thought I had heard, only to have the speaker say "no, that is not what I said."  This is common enough that I encourage everyone to avoid assuming they understood something, but to actually confirm that they did.

I am definitely a fan of the written word.  Even so, it has its drawbacks.  To a certain extent, when I write something, I am talking *at* you, not *with* you.  There is no space for refinement, at least not instantaneously.  It's a little better with tools like IM, which is at least qausi-real time, but still falls short on nuance.  In the end we discover that for actual communication, written documents are far less effective than any other form.

So what about those forms of communication that are so important to agile software development?  How do we communicate with our stake holders, customers, and development teams?  So often we choose some sort of document.  We write up a very large requirements document, from which we create a specification document, which will then have a design document attached.  Finally, we will write some code and create the working software. 

Along the way, we will spend a lot of time going over these documents.  We will have meetings to discuss them.  We will create drafts that we will meet over and refine.  Only when we are finally convinced that we have a particular document right will we move to the next step in our documentation.  Now, I've been to a lot of these meetings, and it always turns out the same way.  If we allocate, say an hour, to the meeting, the first 45 minutes will be discussing whether or not we have used the correct format, filled in the right blanks at the right time, and generally done everything we can to satisfy the documentation standard.  The last 15 minutes, if we can, we will talk about the actual content. 

At some point in this crazy process, someone finally writes some code.  NOW we are getting somewhere.  Well, maybe not.  Code is also a form of written communication.  If we write hard-to-understand or very complex code, we end up once again getting into a place where communication suffers.  We then create a lot of comments that will "explain" what we are trying to do.  At least at the moment we wrote the code.  Code changes though.  As we start working with the actual software, we see things we would like to either modify, or perhaps even fix.  Most of the time this happens in a hurry, so we change the code, and don't have the time to ensure the comments are updated as well.  In essence, we start to lie to future readers.  "This code does this, and it does it this way" only lasts until the first revision.

This all brings me to my main point about communication.  Once we've written all of our documents, argued over the formats, written the code, reviewed the code (now *there* is an area where you can really see arguments about format) and delivered the code, what are we really going to be discussing?  The *working software*.  We look at what it is doing.  We play with it.  We talk about how to make it better, faster, stronger. We don't go back to discuss the document ever again.  

So let's spend less time worrying about the document.  In Extreme Programming, and of course in many of the other agile methodologies now, we talk about fitting a user story on an index card.  Any further elaboration comes best from writing software and talking about what we have.  Another great way of communicating our needs is to write automated acceptance tests.  We are identifying how the software is expected to work and we are unambiguously showing what we want.  

So to circle back to where we began, communication is about shared understanding.  Whatever mechanism we find most useful, we should embrace.  We have found that the most succesful mechanism, without exception, is the spoken word.  If for whatever reason we find that to not be possible, maybe due to the distributed nature of some agile teams, we need to look for the best way to communicate and overcome the inherent difficulties in not being able to talk to each other directly.  The best way to communicate what the software should do is to provide automated acceptance tests.  And of course the best way to communicate what the software does is to create it and use it.

Ok, I know we were going to talk about the four values of extreme programming, and we will.  I had an interesting interaction recently that I wanted to explore first though.  Alistair Cockburn is sponsoring a ten year retrospective for the thought leaders in the agile development community, and someone who will be attending has asked for some thoughts to consider while he is on his way there.  Now my colleague and friend, Mike DePaoli has posted his response in his blog.  It is an excellent analysis, and I think everyone ought to go read it.  Go ahead, it's right here. I'll wait here.

See?  I told you you'd like it. 

Rather than repeat a lot of what Mike has so well articulated, I’ll add a couple of additional points.  I feel that agile is about to reach an identity crisis.  Agile development started out as a way to improve the connection between the implementers of software and their constituency, or customers.  Over the past few years, more and more of agile thought has been focusing on the project management aspect of an organization, and leaving the technical aspects as “implementation details”.  While it is good that the PMOs are embracing agility, they are also rebuilding the barrier that was originally knocked down.

 

I believe this is why Kanban is becoming so popular.  The folks who were involved early on in the agile software development world are getting disillusioned that these great new ways of delivering software without all the ceremony are being replaced by a different set of ceremonies.  Cue Roger Daltrey: "Meet the new boss, same as the old boss."  I don’t know if I’m on board that Kanban solves any new problem, other than to give some of us old farts a chance to try again.  I personally feel that those of us who really are concerned should be taking this opportunity at ten years to take a good look at what is going on, and as Uncle Bob says, restore balance to the Force.  Lets remember why we got on this ride in the first place, which was to develop great software, not great project plans.   

Alistair Cockburn has been organizing a 10 Years of the Agile Manifesto event in Snowbird this coming weekend. 

A majority of the discussion is anticipated to revolve around three questions:

1. What problems in software or product development have we solved (and therefore should not simply keep re-solving)?
2. What problems are fundamentally unsolvable (so therefore we should not keep trying to “solve” them)?
3. What problems can we sensibly address – problems that we can mitigate either with money, effort or innovation? (and therefore, these are the problems we should set our attention to, next.)

Here are my thoughts on this topic.

I think we’ve solved many of the more micro mechanics of agile software development (on paper anyway). The challenge remains in regards to application.    

In regards to question number 3, I think we need to start having more of a systems thinking perspective to scaling agile development.  The issues in this area are usually not related to process and tools of the agile space itself but rather human, organizational and change dynamics in the application of agile.

The agile community needs to evolve people who think beyond the current application of  the basic tenets of the Agile Manifesto and apply them and additional thinking to the challenge of agile at scale, IOW, Agile in the Real World.  For instance, perhaps applying a change framework such as the one presented in the Heath Brothers’ book "Switch" to the problem of scaling agile.  I have written before about coming up with a framework that purports “using agile to scale agile”

Agile coaches, for instance, should be able to not only instruct and coach teams on agile practices, but also coach on crafting change programs based on situations that exist in specific organizations.  This requires longer-term relationships and interaction with clients.

One of the more disturbing trends I see with the rise of things like Kanban is that organizations expect a silver bullet with their agile initiative, and when that doesn’t work, they run to what they think the next silver bullet will be.  Don’t get me wrong, I find Kanban and its premises very useful, however, not exclusive of other agile practices.   We need to get organizations that are moving to agile project management to expect some failure and also help them learn what continuous process improvement is.  For some reason folks don’t seem to realize that this is a team skill like anything else, you don’t do it well just because you allocated time for a retrospective.

In this same vein of systems thinking, the agile community originally did a poor job factoring in how to integrate existing PMOs, legacy project management and governance systems into agile change initiatives, even agile pilots.  It was foolish to not have a well thought out plan for how to make allies out of those that would turn out to be one of your most significant "enemies"…look to Sun Tzu, "The Art of War".  Perhaps now enough has been learned by failure and some success to provide patterns that can be leveraged to help ally such groups early on.

Whether these problems will be seen as sensible or unsolvable I’m not sure, but IMO they are the ones that will impede the success of agile in the real world. If they are seen as unsolvable then we risk seeing limited application of agile in organizations, and by limited I mean both within the IT side and beyond.  Agile thinking can be extended well beyond developing software.

When working with distributed agile teams, first we have to ask ourselves, "What is our definition of making distributed teams work?"  I have managed and coached distributed agile teams that "make it work," however they understand that the level of effectiveness will not be the same as a co-located team, and some of them learned that painfully.

Unfortunately, all too often the leaders that decide to outsource do so strictly on a cost-based consideration and don't consider the other pitfalls of doing so. They don't take into account the value side. It doesn't matter if you cut your development costs by 30% if the productive capacity of the team drops and the quality goes in the toilet; often you end up increasing development costs because of mounting technical debt.

A few of my clients that track this find that the savings in money due to reduced cost per developer or tester doesn't make sense when you look at the value side.  Also, outsourcing decisions are rarely made with the longer term in mind.  By this I mean the cost of owning and supporting the product.  This is especially true for modern SAS solutions. 

This situation frequently happens because some 'superstar' comes in and shows a way to reduce agile development costs by some impressive percentage. They displace local employees, establish an off-shore presence and lower shorter term costs, but rarely as much as predicted. Too often this person is rewarded, held up as a star and promoted.  Then the poor bastard that takes their place inherits the true cost of the oursourcing: often dysfunctional, lower productivity teams that deliver lower quality products. This is followed by the inevitable dissatisfied customers who start to bombard the development group with escalations.  

Variability of requirements is the number one hindrance to achieving predictable delivery in terms of time and quality, and escalations are usually at the top of the list of things that cause variability in requirements.  This cost is not factored into outsourcing decisions, and I'm not saying it happens all the time, but in my experience, it happens more times than not.

The cost-benefit of outsourcing aside, we live in a world where distributed agile teams are a fact, whether gotten to by outsourcing or acquisition.  So, here is a checklist that I have found can help "make it work."

1. Minimize the dependencies between sites. If this means redrawing the ownership lines, do it. You will greatly lower the risks caused by lines of ownership with a solution that forces a higher level of collaboration.


2. Transparency of progress and quality. With distributed teams, it is even more important to have an up-to-date picture of the trends on a project because corrective actions can take longer.


3. Script the important collaborations. Don't make collaboration optional between the teams when planning, tracking and reviewing (of course this doesn't mean everyone on all teams). The level of collaboration will be context-specific to the domain of the work, its complexity and the maturity of the team.


4. Solid build automation and a strict policy of No One Breaks The Build. If someone 12 hours away checks in and goes home and has broken the build, trouble ensures and trust erodes.


5. Manage teams at different sites to the same measure of success.  I was leading an agile development initiative at a company that was building a suite product.  Unfortunately all the distributed teams weren't managed to the same measure of success. One had a very high commitment to quality and was managed to that, and the others were managed more to the feature checklist mentality. Their incidence of defects was 57% higher than the other team... I don't think I need to explain the issues that ensue from such a situation.


6. Monitor the level of trust between the teams. Leadership roles (SM, Agile Project Managers & Functional Managers) need to have their own backlog / plan for how to continue to grow this (use agile to scale agile).

Using this checklist I have seen distributed agile teams "work".  However, when we decide to distribute human beings, especially across significantly different time zones, we must keep in mind that we have chosen to lower their ability to communicate effectively, collaborate and hence build trust.  So before distributing teams for "cost" reasons, make sure you truly understand the cost of doing so in terms of reduced productive capacity of the whole, level of quality produced and the cost of supporting lower quality in terms of escalations.

Faster than a speeding kb article.
More powerful than a press release.
Able to leap tall release notes in a single bound.
Look! Up in the internet!
It’s a tweet. It’s a fan page.
It’s the VersionOne Product Blog!

If you’ve attended VersionOne training or spoken with us at conferences, then you’ve witnessed the passion that VersionOne employees have for helping organizations improve their software delivery.  Since 2002, we’ve focused that passion on creating the leading agile management platform so our customers can scale their agile software development initiatives faster and easier. Along the way, we’ve shared our opinions about agile principles, practices, and events on this blog.  Since our audience was the entire agile community, we left out discussion of our product.

Enter the VersionOne Product Blog.

A few weeks ago we had a chartering session about the product blog.  It didn’t take us long to agree that our main goal for the blog is to share our passion for the VersionOne product and how it benefits our customers.  You’ll see posts for new releases, tips and tricks, customer success stories, how we use VersionOne in our own agile practice and glimpses into life at VersionOne.  If you want to keep your finger on the pulse of what is happening with VersionOne, then look no further!