Monthly Archives: December 2006

Flashback: A Year Ago This Week on Tyner Blain [2005-12-30]

mirror

Managing Requirements Conversations 2005/12/27

conversation

In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do – he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents.[…]

Why We Should Invest in Requirements Management 2005/12/28

investment

Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments in this post by sudhakar -[…]

CRUDdy Use Cases And Shakespear 2005/12/29

yorick

CRUD (Create, Retrieve, Update, Delete) is an acronym used to refer to a set of mundane, important, and indirect (if not implicit) requirements or use cases. To create a report on orders, you have to first create the orders and retrieve them. Further, the ability to update (edit) and delete the orders is probably also important. Another description of the CRUD pattern is here.

Going Agile, 10 Mistakes: Trash Computer-Based Tools

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 8: Trash All Computer-Based Project Management and UML Tools

In short, this mistake is the mistake of not documenting. Computers make documentation tasks easier. Don’t discard them as “overhead.”

Our Addition

Agile isn’t about no documentation, it is about just-enough documentation. Tools that improve the efficiency of the team should not be discarded. Activity diagrams and other design/architecture/requirements artifacts are valuable. Tracking the changes in these documents is worthwhile.

Keeping track of project progress and how things advance and change over time will be critical in helping spread understanding through the organization. Remember, this is a pilot – its purpose is to learn. Lack of documentation will make it much harder to learn later. It will also make it nearly impossible to compare future projects to this one.

Going Agile, 10 Mistakes: Overdo the Team Room

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 7: Overdo the Team-Room Concept

If everyone is forced to sit in the same room too early, then some people will be underutilized. At the start of a project, not everyone can start working – there is some up-front planning that has to happen before getting started.

Our Addition

This up-front organizational work should not get out of hand (which would violate agile principals), but it should not be dismissed either. The first time a team takes an agile approach will require some thought about how to organize things. Restructuring the classical architecture/design/implementation/test cycle into an agile one is not easy for people the first time they do it. Let that initial planning happen first, then focus on collaboration and collocation.

Going Agile, 10 Mistakes: Don’t Create a Project Plan

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 6: Do Not Create a Project Plan Before the First Two Iterations

After doing the ‘prep work’ for the project, you are ready to begin. When “the boss” asks for a project plan, tell him to wait 6 weeks.

Our Addition

One of the biggest weaknesses of agile approaches is that it is difficult to plan and communicate the “ultimate results” or when they will be achieved. Agile approaches rely on their ability to react to change, and save time by not asking questions until the answers are immediately useful. Don’t exacerbate the challenge of setting external expectations by waiting as late as possible. Remember, this is a big change for the current organization – a little upfront forecasting and planning will pave the way for organizational change.

Going Agile, 10 Mistakes: Fail To Define Roles

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 5: Fail to Define Roles Within the Agile Team

We have to define the roles and responsibilities of each person within the team. This helps both with execution and communication (to people outside the team).

Our Addition

This is project management 101. The people on the team are going to be new to operating on an agile project. They need to understand how everyone works together. The people outside the team will see this as a confusing effort, or a black box. By defining roles, we can manage expectations and improve our ability to execute.

Going Agile, 10 Mistakes: Fail to Identify The Sponsor

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 4: Fail to Identify the Sponsor

If we don’t identify the champion of the endeavor to convert to agile processes, we can’t keep them informed of progress. Their expectations need to continually adapt to progress just like every element of agile.

Our Addition

Close collaboration with stakeholders is critical to any product success. Converting an organization to agile is a change-management project. The sponsor of this change is the stakeholder for this project (not to be confused with the stakeholder of the project that is underway). Keep the stakeholder informed.

Flashback: A Year Ago This Week on Tyner Blain [2005-12-23]

mirror

Use Case Series: Formal Use Case 2006/12/20

formal

This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management.

Use Case Series: Informal Use Case 2006/12/21

informal

The informal use case is the tool of the Agile Requirements Manager. It is a paragraph describing the user’s goals and steps. Also referred to as a basic use case.

Top Five Use Case Blunders 2006/12/23

broken

We all make mistakes. When we mess up use cases, it is most likely one of these five things.

Going Agile, 10 Mistakes: Ignore the Corporate Culture

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 3: Ignore the Corporate Culture

Many companies operate with each department acting as a silo. Agile techniques rely upon cross-functional contributions. When there are barriers (“not my job”, “not your job”) within an organization, they have to be addressed before agile will work.

Our Addition

Setting management expectations is critical here too. In addition to looking for the switch-hitters on the team, we also have to set expectations in terms of pacing and delivery. We’ve written before that waterfall processes are better for planning – because they provide perfect predictions of what the team will fail to do. Many organizations rely on the “predict, deliver, fix” model.

Going Agile, 10 Mistakes: Go Fast To Go Fast

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 2: Go Fast to Go Fast

In this mistake, Levent warns us that “just doing it” without training and explaining won’t work. Everyone needs to understand exactly what agile is and what it isn’t.

Our Addition

Our experience has been that people and teams operate the most effectively when they understand the context in which they are operating. Give them a view of the big picture, and help them understand how all the pieces fit together.

In a manufacturing assembly line, you can get away with people who understand their job. With a simple understanding of what they can depend on, and what others depend on them for, they can do their jobs. You cripple people’s ability to innovate or contribute outside of their role when you do this.

And software development, especially agile software development is not an assembly line. Understanding how it all works is critical to doing each piece well.

Going Agile, 10 Mistakes: Go All In

snowman

Levent Gurses has an article, 10 Mistakes in Transitioning to Agile, in the Dec 2006 Dr. Dobbs Journal. He writes about the most common mistakes that companies make when transitioning from “legacy development methodologies” to agile ones. In this series of short articles for the winter holidays, we’re looking at each of the ten mistakes he identified. Enjoy the light reading, and don’t think too much about work.

Mistake 1: Go All In

Levent points out that the biggest mistake is to not do a pilot project, but rather to convert a large and risky project – or even worse, all projects. He points out that it is a mistake because you won’t have time to learn from mistakes.

Our Addition

Politics trumps people. Levent is right about needing to do a pilot project, but not just to minimize the cost of mistakes. People in large organizations can become entrenched in their ways. Changing the way “we do business” is ultimately a top-down decision. Agile is very much a bottoms-up religion. With a pilot project, we can convince people up-the-chain, in order to drive change back down. It’s just the nature of the beast in large companies.

Using a pilot project is also a form of “agile change management”, where we gradually change our company over time, improving with each iteration. Fewer mistakes, better forecasting, solving problems that are unique to our company along the way.