I’ve developed software in two distinct ways: (1) writing very detailed and elaborate specs, or (2) writing very little and instead using lots of pictures and conversations.
There are certainly situations where writing specs seems to make sense, but what I’ve found is that by and large, writing specs in an agile environment can be a complete waste of time.
(Note: There are situations where I’ve found it worth spending time writing things out; specifically, when the process of writing itself helps you clarify in your own mind what you’re trying to do. I happen to be someone who gains clarity through the writing process — but expecting your engineers to read pages and pages of your precious thoughts is usually a waste of time.)
Here’s the process we’ve found to work; most of the time, we’re using some variation of these steps: Read more of this post
In 2003 and 2004, as we were developing our cross-media LookWho’sClicking SaaS application, I had the privilege of developing our software in a way that has now become a part of my work-process: getting embedded at a Client’s location.
Early on during development, we succeeded at licensing our software for $4,500 to a local marketing services company (once we found our product/market fit, we eventually raised the price to $9,500). The company was located about 20 miles from our office, and I started making frequent trips in order to do training and on-boarding. Since they were one of the first on our platform, there was a lot to learn (on both sides).
At noon each day, I’d drive to their office and help users with learning how to use our software. In addition, I became very interested in how their business worked, and how our software made an impact on their clients, revenue, and margins.
Over the course of a few weeks, the practice of visiting their office became a daily occurrence, and eventually, I was able to grab an unused desk and set up shop.
Here’s what I found extremely helpful about getting embedded with a Client: Read more of this post
Here’s how we run the engineering stand-up meeting:
1) We start promptly at 9:00 AM. We experimented with having the meeting at 4:00 PM, but meeting towards the start of the day seemed to work better. I personally enjoy the buzz from getting everyone together in the morning, hearing the prior day’s activities, and charting the day’s course.
As I walk into the meeting, I make it a point to greet everyone, shake hands (or a quick fist-bump), and look everyone in the eye and smile. I don’t always succeed at this, but I like to try and give everyone a good start to the day. I feel it makes a difference.
2) We time-box the meeting to 12 minutes. We use an iPhone timer to keep us honest. These days, we usually finish with about a minute to spare. We used to get lazy and go for 20 or 30 minutes, but now that we stand up and use a timer, we’re good. I check the timer from time-to-time during the meeting and sometimes call out the number of minutes remaining. Even though each person only has a few minutes, you’ll notice that it doesn’t seemed rushed; everyone has plenty of time.
3) We go in the same order each day, cycling through 7 people. The people involved are:
The Product Owner (me). I report on both my product-related tasks, as well as whatever I’m working on with the Leadership Team or any other part of our company. If someone listens carefully, they can get a pretty good sense for what’s going on elsewhere in the company.
Our QA lead, who also is involved with our Professional Services. He goes first, and you’ll hear him mentioning working from home the prior day. We do this from time-to-time to improve focus.
Our senior architect and 3 engineers, each of whom are responsible for a different sub-system.
A member of our Support Team, responsible for communicating Clients issues, escalated cases, and any other meaningful data (we use SalesForce.com to track all cases). We added this person to our daily stand-up just recently, and we’ve already seen it pay dividends.
Even though we go in the same order each day (and it is written on the board!), I often forget. Senior moment!
4) We stay fairly disciplined. If something comes up during the meeting that requires additional discussion, we’re disciplined about putting it in the “parking lot” and discussing it later. I have to resist asking a lot of questions; you’ll see me ask a few quick ones, but I try to keep us focused and moving forward. If anyone is blocked, it’s my job to make sure that I do what I can to move them forward. You’ll hear me ask about blocks after some of the updates.
5) We update the Sprint board. We usually start updating User Story status (as a percentage towards completion) a few days into the Sprint, once we’ve started making progress. We recently changed what we display on the board, and it seems to have made an improvement. We can cover that in another post.
The meeting runs well if everyone is prepared (which is most often the case). Some come prepared with a summary of what they worked on, others seem to have great memories and can recite their work without notes. Personally, I write everything down in a Google Doc, and just reference this document during the meeting; otherwise, I’d never remember anything — maybe I’m getting old!
Here’s the video from one of our recent Scrum meetings; excuse the brief interruption around 1:45. Enjoy!
Akathisia: Life In Motion -- David Rosendahl 