Agile, Experience Report, People, Project Management, Requirements

My #1 Agile Failure

Some of you may have read my personal Agile Adoption Story and possibly thought that it was a good story on Agile Adoption and how Agile can sometime succeed on the first try. I know I’ve read many stories about the pain and suffering on the first Agile projects people have been on.

If you missed the Blog Post on my personal Agile Adoption story, you can find it here:

My Agile Adoption Story

So given that my first Agile project was successful? What was my #1 Agile Failure? Simply put, it was the fact that my first Agile Project was successful!


Please let me explain. We came out of that first project with a false sense of security. We thought we nailed this ‘Agile’ thing. I mean we didn’t do many of the core Agile practices and still we delivered on time, on budget, and satisfied the client. This false sense of security was at a personal, project, and perhaps even a company level. We thought that we could deliver again with different teams, different problems, and different technologies.

I often say that I would have rather failed slightly on the first project so we knew we still had a way to go. Unfortunately that didn’t happen.

Why did we succeed then?

I believed we succeeded primarily due to the expertise of the development team and the expertise of our client/Product Owner. Having these two factors can address shortcomings in many other areas.

To recap, here are the Agile Practices we did not follow:

  • Test Automation
  • Continuous Integration
  • Kan Ban
  • User Stories
  • Planning Poker
  • Pair Programming
I would not even dream of being on another project without at least 5 and possibly all 6 of these practices. We really had a project that we led in an Agile way but that did not use XP practices, Agile Requirement practices, or any Test Automation! In addition to these 6 practices, I have learned about many other Agile Practices that I also would not be without on a future project. Some of these are:
  • User Story Mapping
  • Paper Prototyping
  • User Design Studio
  • BDD
  • TDD
  • And many others
But it took me a couple of hard projects after this first successful project to teach me that the hard way. I’ll leave it up to a future post to tell the story of a couple of the hard projects. 🙂

Re-posted from

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: