http://games.slashdot.org/story/10/02/09/0551202/Game-Development-In-a-Post-Agile-World?from=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Slashdot/slashdot+(Slashdot)

To my mind an agile variation of this is ‘We’ve already written 200 stories’. I think a lot of people don’t get that the ability to work on requirements as you go is one of the great benefits of agile. They think agile development is like Forrest Gump’s box of chocolates – you never know what you’re going to get.

On to the winners:

My favorite waterfallacy was Jose Papo who wrote about the common waterfallacy that since there’s no documentation on agile projects, we can’t use agile because our system has complicated business rules. I’m also shocked by the responses I get when I tell people they can augment a user story with a great big Visio flowchart showing a business rule if needed.

As for a random winner, I asked my assistant Jennifer to pick one randomly and she selected Niels Malotaux.

Thank you again to everyone for the great ideas. And congratulations to Jose and Niels.

The problem, I believe, is that the Waterfall practitioner sees Story Points as related to time. “If you tell me how many SPs you have I can tell you when the product will be delivered.”

This comes up a lot, especially if the Team has at any point related SPs to Ideal Days. Everyone seems uncomfortable, at first, with the concept of SPs not having a time element.

Teams usually get over this after playing Planning Poker or Team Estimation games through a few Planning Meetings. Stakeholders who aren’t getting the concept are invited to sit in and it seems to work (perhaps they just don’t want to have to sit through another Planning Meeting!).

Another step that helps is I get the Team to drop the estimation and recording of time for Tasks. This further separates SPs from hours. The added benefit of dropping hours is that planning and updating of Stories is much quicker.

I have run up against this waterfallacy many times. Here are some of the things I have heard:
- “Agile is all about coding, not about documenting.”
- “The Agile manifesto says documentation is not important.”
- “How can you deliver software without a requirements document?”
The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.

How to overcome these statements? I talk about 4 things:
- Agile manifesto – what it actually says
- Why Agile values face to face communication
- How Agile documentation works and how Agile teams document a lot
- If you are using Scrum, it’s up to the organization to define what is right.

*Agile Values: Working software over comprehensive documentation*
In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!

*Agile Principle: Use face to face communication*
One of the key Agile Principles is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This signals that people should talk to each other rather than communicating through documents. Does not it say not to document? No!

*Agile Documentation – just the right amount*
Agile teams tend use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.

Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.

*Scrum lets the organization decide how much to document*
If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.

There is no doubt that Scrum is a challenging paradigm shift when coming from a waterfall mindset. Even if it is known that Big Up-Front Requirements Gathering, or Big Up-Front Design is not going to provide complete requirements or a stable design, it at least gives people comfort that they have _some_ idea of where they are going, that progress has been made. The difficulty seems to be acknowledging the incompleteness problem, and recognizing that there may be a better approach. Learning to be comfortable with an incomplete set of requirements is like learning to sleep without your teddy bear.

The project I’ve been working on for the past 18 months has been a technology update of a VB6 application. The not-appropriate-for-greenfield-projects waterfallacy has been reiterated to the team fairly consistently, even though we have the older application to which we refer. Despite the backlog being in a good shape, and the business analysts and product owner having input into it, this waterfallacy still comes up about every couple of sprints. Something seems to scare them every now and again, and the comfort of the waterfall teddy bear is all too appealing.

The fallacy as we know is if we had waited until the point someone thought the scope was fully defined we would have started months later. Also, the reason why our scope was changing is because we were learning things as we were going which we would not have had the insight into before development began.

The resolution was to demonstrate a project schedule where you do requirements definition up front and still have some factor of change vs. one where you do just enough to define your vision and initial details and have potentially a higher (but similar ballpark) factor of change.

In the end getting started and building in shippable increments will deliver value to the organization faster.

To overcome it you need to show that on previous releases the development team could have anticipated the highest priority requirements well in advance of the official sign-off. Then the self-organising team can start sprinting instead of crawling around the office waiting for the signal. And if marketing department comes up with something that requires changes to the product backlog, well, that’s what being Agile means.

I’d like to share several beliefs I had the chance to cope with, about Agile and waterfall projects:
First is :
“Agile is more expensive than waterfall”.
As long as I could observe, this popular myth is stemming from the image of “upfront identified exhaustive costs” of a waterfall project. The best arguments for me to challenge this is to analyze (and retro…) if any project in today business dynamics can be exhaustively forcasted & designed 12 months upfront (or even 6 months..)
The second( my very favorite) is to illustrate the “Business value/time” curves for an Agile and an Waterfall project. The message is pretty clear: with Agile a value product can be achieved earlier in time, and the client can decide to stop the project if he or she got enough value of it. That’s an effective way to control and adapt costs. In waterfall projects you need to wait and see … at the end of the delivery cycle. And you need to pay all of it … even if you don’t need that anymore (or not quite like that).

The second strange “phenomena” is a complete opposite reflection about what Agile brings for the development group:
The first one is : Agile is “developer’s police”
The second is : Agile leaves all the power of planning to the developers. Managers and other actors have no way to put some pressure on the development team.

I can tell you that the two camps were pretty passionate about their position.

For the first situation: Developers passed 40% of their time on and calculating and reporting of individual daily velocity to the group of 4 managers (for a team of 6 developers). First step was to create a recurrent story to reflect this task that was planned in each sprint. Proved to the management that over-reporting velocity speeds down value creating velocity.

The second situation : A project that made a transition to Agile from a very top-down management. The way to make management adopt Agile was somehow the following: *
Well the basis : the project was blocked before Agile was deployed, so it needed some new ideas…
Second, anytime Product Owners were not happy with the volume realized/sprint, we used to review at the retrospective time the following items : Complexity embarked was understood and accepted? the priorities were efficiently defined?
After a while, the SCRUM mechanisms were well adopted, as the monthly project review (we were based on 1 week sprints) showed that it advanced better than it did before.

So, these are my favorite stories,
Best to all!