My #Agile #Manifesto

Over the last several months my blog posts have given people an insight as to what I believe in regards to developing software and working on teams. I thought it might be a good opportunity to sum up those blogs in a post that clearly says what my beliefs are and what My Agile Manifesto is.

My Agile Manifesto has 6 principles

1) Vision before Iterations

Whether you are developing a new Claims system, Website, or Data Warehouse I believe you absolutely need to have a shared vision and understanding of the vision of success before you start iterations. If you do not are expecting the vision to magically materialize during the project you are taking on a huge risk. This vision does not need to be very detailed, but it is imperative that the clients and the team share this vision so all decisions made align with the vision.

2) Estimate to confirm minimum Viable Product is feasible

There is a lot of discussion out there about not estimating projects at all. And it some ways I think they have a of merit, IF you can confirm that you have enough time and budget to at least deliver the Minimum Viable Product. If you can confirm this, you can indeed place less emphasis on estimating and just progress through the prioritized backlog. This is because you have guaranteed that the client will still be satisfied whenever you need to stop. If you can’t guarantee client satisfaction wherever you may need to stop, you have a huge risk on your project. 

3) Tacit knowledge should never exceed documented knowledge

I’m not a proponent of large reams of documentation, but the project’s tacit knowledge should never exceed the project’s documented knowledge. There should be a balance to capture tacit knowledge about a project so the project exists outside of what is in people’s heads and the code. High-level architecture, requirements, and planning documents are usually the areas where this is usually required.

4) Plan at a high level

After the shared vision is validated, a high level plan should be done to validate how the project will execute. I’m not condoning a Work breakdown Structure, but a high-level plans that defines the deliverables and the deliverables prerequisites are usually a prudent activity. Remember that Agile is all about reducing risk and if we have a risk that the deliverables can’t be completed by a certain date due to dependencies, we should inform the client when we start not 4 months in. It is also never a bad plan to allocate vacations and holidays onto the calendar to ensure that hours available match available effort overall.

5) Estimate a deliverable level to define scope

I also estimate each deliverable at an intermediate level. Yep, I’m an Agile Heretic. But every single accomplished developer I have worked with has asked me for the estimated effort so they can plan their work and let me know asap if they think there are issues with the amount of time remaining. I’m aware of the science that knowing the estimates will cause the work to fit the estimates, but I feel that can be addressed with a proactive a trusting approach with my teammates.

6) Manage forward

This is related to principle 5. If you always manage forward and are not concerned with the past, (except to ensure you learn from it) missed estimates are just learning opportunities. Forcing people to abide by previous estimates is just bad management plain and simple. It is also an example of managing backwards. If you always manage forwards after every new piece of information, estimates are just a way to learn.

“A and B just happened, what do you we do now? C? OK.. let’s go’


And my final principles is that you need to customize and configure your approach for every project, client, team, and team member. No absolute approach is ever correct – Only a Sith deals in absolutes.


Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.