I am a process wonk. And to my delight, we are following the agile methodology on the mschool project. And by following I mean, we are following it to the T.
- Daily standups: Here everyone (and I don't just mean engineers) gets to share what they are working on and what's blocking them. The engineers get to see the issues that designers and product folks grapple with, while the product folks have a better sense of the engineering challenges. The added benefit is we get to share little nuggets of information that gets people excited. For example, in today's mschool stand I shared the option of faking out a really large quantity of data to see how our app performs. This doesn't have an impact on just engineering, the product folks too would need to figure out how best to create a delightful experience when dealing with huge quantities of data.
- Project planning, estimation and sprint review: We get together once each sprint (more on what a sprint is later) and plan on what we are going to attack in the following few days. In these meetings, we have the stakeholders, a potential user of the app and design/engineer people participate. Here everyone sees clearly the direction the product is being built towards and everyone gets a sense of the amount of work (or unpredictability rather) involved in attacking each piece of work.
- Sprint: We focus on delivering something of value in a fixed time period. This could be a week, two weeks or even a month. We have chosen on 3 weeks. The shorter the better. The idea is to get everybody (the stakeholders included) into this mindset of always be delivering. Decision paralysis is something that plagues most software projects. Let's try and figure out everything from the start is just a fools errand. Martin Fowler said it best A software project is kinda like taking aim under high wind conditions. What you really want to be doing is, just taking a shot and moving the target to where the arrow lands. :) Eventually, you go through this process enough number of times and the target is where you really want it to be.
- Sprint retrospective: Everyone involved in the sprint gets together and shares stuff on a "Happy", "Meh" and "Sad" list. If something keeps coming back on the "Sad" list it is eventually going to be acted on. It's transparent and out there for everyone to see and there is no hiding behind anything. The "Happy" list gives everyone pause to celebrate and take pride in the work they did in the sprint and feel energized to keep going and making stuff awesome.
I might be missing some stuff but this more or less is our project workflow. Joann our scrum master is super awesome and keeps us honest about the process.