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.