What we mean when we say 'Agile Building'
One thing we like to talk about here at Because We Can is the fact that we're 'Agile'. It doesn't mean we are just handy with the robot, or that we can catching things when you throw them at us (and jump away when those things are sharp), but it actually goes a lot deeper than that. We use something called 'Scrum' to manage our projects and business.
One thing we like to talk about here at Because We Can is the fact that we're 'Agile'. It doesn't mean we are just handy with the robot, or that we can catching things when you throw them at us (and jump away when those things are sharp), but it actually goes a lot deeper than that. We use something called 'Scrum' to manage our projects and business.
So what's Scrum?
Scrum is a project management process that came from the 'Agile Programming' and Object-Orientated worlds in the early 90's. In other words, it's a way of working to get projects done. The term 'Scrum' itself comes from Rugby, and while there is no blood involved in our Scrum, you'll soon see why it's called that. It shares many common ideas with 'lean manufacturing', something Toyota is famous for (well other than all those Priuses... Priuseses... Priusi?!?).
Before we get too much into Scrum, let's first talk about why it's unusual for us to be talking about it in regards to what we do, seeing that our company doesn't write software for a livin'. Most design firms, custom fabrication shops, and the construction industry in general use something that some call a 'waterfall' project management process. That's a fancy term for more or less a phased, planned project that's done in progressive stages. It's also sometimes called 'Big Design Up Front'.
Waterfall: What most folks do.
The idea in the Waterfall process is that you figure out all the problems and issues on the phase you're in before you move to the next part of the Project. "Measure twice; cut once". Early on all the requirements and ideas for the project are clearly defined, documented, evaluated, talked about, and then acted upon in long phases of work with big clear goal posts everyone is running towards. The classic 'Schematic Design - Design Development - Construction Documents - Contract Administration' pattern that most Architecture firms follow is a good example of a Waterfall process. Another one would be the way most folks plan a camping trip: get a map, figure out where to go, make a list of what you need, pack the stuff, drive to the campground, then set up camp. Each step 'falls' into the next, and you don't move onto that next step until the current one is complete.
In an ideal world, this works rather well. Teams working together in harmony, all running towards the same big goals, with all the tasks and work defined, planned, and scheduled out in so many lovely cascading Gantt charts. Then everything comes together at the end and fits together perfectly, and the next phase of the Project is undertaken.
If the World was perfect, we'd all be really bored.
However, design can be a very non-linear process. Requirements change. Clients change their mind. New ideas come along late in the project, ideas that you simply wouldn't have realized before. New technology pops up halfway through the Project. Material costs suddenly change, impacting the budget. Or worse, some fundamental thing about the Project turns out to be wrong, and it wasn't obvious that was the case until a whole lot of work was done (or in the worst case, the building was built, or the product is shipped!).
So those who are running with a 'waterfall' development process are forced to hate and minimize change. Change is Bad, for it disrupts everything and costs too much. Planning, documenting, and meetings are good, for every detail needs to be though out, written out, and talked about before things can move to the next stage. And when something is forced to change it unravels part of the Project, lots of work is thrown out, and it all starts over again. Finally when there are risks, problems, or mistakes, it's best to minimize them in any way possible to keep them from impacting the Big Plan. Sadly this sometimes includes sweeping them under the rug or passing them onto someone else, for it will be so long before anyone notices that it might not matter anymore.
So why is Scrum different than this?
Scrum puts this whole thing on it's head. It assumes from the start that change is a reality and that you can't possibly know everything about the Project when you start it. So instead of focusing on the Big Plan and trying to get everything perfect before moving to the next big stage, it focuses instead of a steady stream of small incremental goals that when accomplished result in something small of tangible value being delivered to a client.
This, in turn, changes everything about the process in which you work.
Planning, documenting, and meetings aren't as valuable as getting real things done and delivering something to a client. Input and communication is vital, especially with the client or customer. It also gets you to pay attention to what's really going on, rather than that Big Plan in your head. Also those things (or people) which aren't working and effective become pretty obvious in short order. This is because that small part of the Project you're working on has to really work and deliver value along with what everyone else is doing by a very near deadline. It also makes it such that problems, mistakes, and risks are things that aren't scary and to be swept under the rug, but instead just factors that need to be considered in getting to the immediate goals.
It's more like "Measure a little, cut a little, & then see what happened. Measure again, and then cut a little more, and by then have something useful you can give to someone else".
Until fairly recently a Waterfall process is all you could really do within the design and construction industry. It took so long to change anything in the hand-drawn blueprints, communications were slow, anything custom took a long time to make, and everything being so expensive and full of risk, well, that no sane person would do anything but try to plan out every detail and keep change at bay. But now, with things like CNC automated tools and BIM, and modern communication means like e-mail and project Wikis, we can embrace change, be ready for it, manage it, and let it help us make better things instead of being an constant problem.
Scrum is simple, lean, fast, and only has a few tools it uses:
The Sprint. The 'sprint' is an interval in working time. Ours is a week, sometimes more, other folks use a few weeks to a month or two. But it's short. That's key. Within that time, you're going to try to do everything you can to meet your project's immediate goals from the Sprintlog so that you can deliver something of value to a client. For example, we might say on Monday that by Friday we'll have designed, built, and finished a table for a client so that we can deliver it at the end of the Sprint.
The Backlog. This is a big long list of all the things that need to be done, along with how long you think it will take to do them, for the Project. Big things, like 'build the building' get broken down into smaller chunks that one person will be able to do within the time of a single Sprint (or less). When you come up with a new idea for the project, it goes on the Backlog. If a client changes something, it changes the Backlog. Some folks also prioritize their backlogs, depending on changes and what's going on within the Project. We categorize ours, using a spreadsheet, by project, client, and context, for we always have many things happening for many different people.
The Sprintlog. This is a list of items taken from the Backlog that you're going to get done within the Sprint. These are the 'small goals' you're aiming to hit, that once are all met within the Sprint, will result in some tangible thing of value being delivered to the client. It's not really a 'to do' list for this reason alone, for when the Sprint is done you deliver something of value to someone, no matter how small, not just a completed checklist for some big, far-off goal.
The Daily Standup. Every day the project team meets. We meet in the morning, but some pick the afternoon. No one sits, everyone stands, and it's a dollar fine to whomever's late. We try to hold our standup in a different place every time as well. Only people committed to deliver something for the Project are allowed to talk, but anyone can listen in. Everyone answers these three questions:
- What did you do yesterday? (we also log how long it took, but that's not required)
- What are you planning on doing today?
- What things got or are getting in your way and slowing you down while doing these things?
The point is for this meeting to get everyone on the same page, figure out how things might be done better, and to take as little time as possible so that you can get to work. Ours are down to ten minutes or less now.
There are a few more things to Scrum, and some stuff that some folks do (like Burndown Charts and such) that we haven't adopted just yet. And we aren't that big, so we swap duty per Sprint of who's the Scrum-Master and such. But overall it's been a wonderful tool for us. We've been doing this since March, and it's really helped us focus our efforts and made us much more productive while allowing us to be very flexible and responsive to our client's wishes. To practice what we call 'Agile Building'.
If you want to get started with Scrum, we can't recommend more this great PDF.
I hope that this has been a help, and that you're now more interested is spending more time doing than talking ;-)