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
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!
Our chief software architect, Aref Memarian, recently shared “Essential Scrum” with me. If you’re looking for a great review of scrum from someone who has obvious hands-on experience, I’d definitely recommend it.
While reviewing the various roles involved in agile development, the author describes two types of people: Pigs, and Chickens. Imagine this scenario:
A Pig and a Chicken are walking down the road. The Chicken says, “Hey Pig, I was thinking we should open a restaurant!”
Pig replies, “Well, perhaps, but what would we call it?”
The Chicken responds, “How about ‘ham-n-eggs’?”
The Pig thinks for a moment and says, “No thanks. I’d be committed, but you’d only be involved!”
This analogy is based upon the Pig providing bacon, an act which requires total commitment to provide (i.e., death), in contrast to a Chicken who provides eggs — a task requiring participant but not his life.
In other words, in a bacon-and-eggs breakfast, the difference between a Pig and Chicken is that the Chicken is involved, but the Pig is fully committed!
In most organizations, you’ll probably need a combination of Pigs and Chickens involved on any particular project. You want your Pigs to be committed, which means they should have autonomy and freedom, in exchange for being held completely accountable and responsible for the project’s success. Your Chickens can provide input and support as required.
Now, what if you apply this concept beyond a particular project, and apply it to an organization as a whole? For example:
If you’re a leader, what’s your mix of Pigs and Chickens? Do you want more of one and less of another? (And think: Which are you?)
If you’re in a non-leadership position, what’s your perspective? Are you a Pig, committed and accountable for your organization’s success, or a Chicken — involved, but only to a limit?
On a drive back from Fresno, my friend and fellow Mika board member, Jeff Tanner, described how he implemented Patrick Lencioni’s method for daily, weekly, monthly, and quarterly sessions to align his leadership team.
I’m fascinated by organizational methods for improving performance, and so I listened intently as he described the process. I couldn’t wait to visit our local Barnes and Noble to read Lencioni’s books (they’re short, written like short stories). You’ve probably seem them numerous times in the business section of your bookstore.
At MindFire, we’ve been using daily stand-ups as a core part of our engineering culture for about two years (watch an example here). It is by far one of my favorite times of the work day, as it gives me the opportunity to hear (in a succinct fashion) what everyone accomplished the prior day, and what they intend to do that day. Everyone gives Twitter-like bursts of information in the following format:
What they accomplished the prior day (not a lot of details, just the bullet-point summary)
What they intended to accomplish that day
Whether they have any “blocks”, i.e., impediments in the way of achieving their stated objectives
We’ve found that it is helpful to stand up (keeps everyone brief and avoids verbal diarrhea), and set a timer for 12 minutes. We start promptly at 9:00 AM, and if you’re late, we require one push-up for everyone minute past 9. Keeps things lively!
At the end of the session, everyone is aware of what their teammates are working on, and we’re able to make quick course adjustments based on the day’s activities.
Have you implemented daily stand-ups in your organization? If so, have they helped your organization? If not, what keeps you from trying?
Akathisia: Life In Motion -- David Rosendahl 