I am really perplexed by the notion that whether you commit to a task as an employee/manager or volunteer it has anything to do with agile.
I do agile workflows and waterfall workflows (often pretending to be agile) for a massive International corporation currently, owned and ran companies with agile workflows (servicing the ultimate waterfall workflow the U.S. Military
) and I would encourage the thought exercise of the process for anyone - even a volunteer organization (much like GeeTwo suggested take what works and abandon what doesn't).
I can't count how many times I've sat in a room with a project manager used to waterfall and they tell me about how they don't understand how agile leads to timely execution or doesn't lead to mayhem. I personally don't understand why waterfall advocates don't understand that waterfall's success is based entirely on heroism which leads to burn out and drives up the cost of the work because the World we live in is moving too fast.
One needs to understand the difference between an innovation and execution workflow. One needs to understand the scope of the work involved and the nature of the commitments. One needs that regardless of the reliability of the people doing the work. If one doesn't have time for an innovation workflow then be aware that you are crossing agile and waterfall together because execution is judged entirely on the triangle: time, cost, quality and with only 6 weeks (assuming no prior time to build season) you may find you must make that compromise.
In fairness if you don't know the reliability of the people executing work - say because you don't know each other at all or they have external critical paths no one can control (jobs, sick relatives, personal issues) - you can't really rely on any planning because it is out of control. In those cases you plan on minimum deliverable in the maximum available time and set those standards rock hard with extra resources to insure they must be done. Worst case you KOP as the final target as much as possible tossing what would be money into the critical path to insure that time and at least some quality is there even if nobody can keep it on track.
I really think that agile teaches very important skills: break tasks into parts you think you can do, plan to shift delivery when things do not work as expected, understand when a workload is so critical path it drives execution waterfall and direct resources accordingly. It is a shame that the build season is so short because it doesn't leave adequate time to really see the difference. If you create epic goals that span build seasons you can see where the differences are. Keeping in mind that by necessity creating an epic that exceeds a build season puts you into the summer where most people are unreliable
.
Where agile becomes a major time commitment is where a business decides that sprints mean tasks always to be hard delivered at sprint end - done & done - never be opened again. This defies the total point. Yes you should divide a larger task into parts. Yes large tasks have deadlines. However if you find yourself constantly racing from sprint end to sprint end under threat someone is not doing it correctly. Now that said: if you run a business and you can use agile as an excuse to beat productivity out of your employees week after week, and your employees let you get away with that as I often see, then you actually have a problem where a company is doing something for questionable reasons. Agile should make innovation easier to understand for the business - because you don't just pay some smart person to disappear for a 1 year and come back with great ideas: you see how they are arriving at the destination and if they are not arriving there at all.
People don't lead because they are chosen to lead; they are chosen to lead because they lead. - EricH [more] 
31-12-2015, 09:08
Hybrid Mode
