How do we know what to do?

One of the most contentious items for an Agile team can be the requirements. Yes, I said it - REQUIREMENTS. Because how you set up your communication with the Business partner matters a lot. It really can set you up to succeed or fail, especially if you have an immature organization, or an ambiguous process to work with.

Requirements can take on many forms, and each form has its strengths and weakness. The most common requirement form in most agile organizations is the User Story. And if you research it a bit, you can see why "requirements" and "user story" do have some significant and important differences. The one thing they have in common is that it is a vehicle that allows a development team to work towards delivering something of value to the business. Less common forms include use cases, Technical Specs, Functional and Non-Functional Requirements or just plain wish lists. Each form has it's particular nuances, and I wish to write about this because if you work with an organization that is familiar with the less common forms, I find that the  easiest way to "become agile" is to use the old process and re-name the new items "User Stories". This can lead to failure even before you get started.

When Success bites you...

Many posts so far have dealt with the challenges of growing and dealing with issues within a team or a project. But what happens when you actually start to get positive results? This can be a surprising challenge for many organizations, and some inadvertently end up snuffing out a success just because of the surprise factor. I'd like to help you today by speaking about what do we do when we succeed.

There are many factors with Agile implementations, they include the coach, the teams, the environment and culture of the organization. All of these factors have to line up in order to start getting some progress. There are some logical steps with the initiation of this effort that go along with the “growing pains” of culture change – but in all instances, one of the things that must happen is that people who have been selected to work together have to at some time choose to become a team and work together or decide that they are not the group to do so. When this finally happens, the simple, logical steps to Agile start to “click” – and then things can go really fast in either direction.

Care and Feeding of a Team

Lately, I have been working with a group of people that are involved in a high stress low feedback project. This got me to thinking - how can Agile help you treat your people well, so that the organization fully benefits from healthy happy team members? Is this even a goal in the organization?