Agile, Agile Estimating, Project Management, Software Development

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’

 Summary

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.

 

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

Discussion

No comments yet.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: