InformIT recently posted an interview with Scrum evangelist Mike Cohn. The interview has a lot of great information and hits on a number of points, including the benefits of user stories and agile estimating, and some of the reasons why many companies fail to successfully transition to Agile.
Check out the interview here.
Agile Purists beware: The following post may cause uncontrolled vomiting, convulsions, gnashing of teeth or “soap box”-style ranting to anyone who will listen.
Alright, now that we’ve got that out of the way, let’s talk about that headline!
At work, I’ve just started working on a small three-person project to build a relatively simple Windows application. Two of us on the team serve the roles of project manager/ScrumMaster, Business Analyst and Developer. The third serves as our customer/acceptance tester.
Last week was our first week of our first two-week iteration. Our “customer” was on vacation for part of the week, but we held our planning meeting ahead of time so that the other two could move forward and have something to show our third when she returned. We implemented daily scrum meetings, but found them to be a bit excessive for just two people. So, for part of the week, we held our scrums over an Instant Messager.
I asked myself this question at first. One of the tenets of the Manifesto is the idea of “Individuals and Interactions over Processes and Tools”, with the implicit supporting argument that face-to-face communication is the preferred approach. However, remember that these ideas are not absolute. We do not have to promote individuals and interactions by sacrificing our ability to take advantage of technologies and tools. Instead, we should take advantage of tools and processes where it is beneficial to do so.
In our case, myself and the other developer sit on different floors. Rather than walking to a separate floor for a 2-3 minute meeting every day, it made more sense to take advantage of a tool, like a phone or instant messager.
Now, I’m under no illusions that this is a good practice in general, nor that it should become a recommended practice at large. While there were some benefits in our specific case, this practice would quickly become unweildy as soon as we start adding more people to the daily scrums. Even with three people, I feel like more could be accomplished more efficiently if we met face-to-face (or, at the least, over the phone).
The point I want to get across is that we need to remain pragmatic in our approach to software/solution development, and not fall into the trap of following any manifesto, principle or practice so blindly that it becomes detrimental to the team. It’s up to us to decide what makes the most sense for our specific situations.
There is a good post over at the Agile Advice blog regarding Scrum’s definition of “done” and how to customize it to your own team environment.
This is something my team has been struggling with lately. We’ve been implementing a Kanban-like approach to managing our work items. For most of our work items, we have common activities that we need to accomplish, such as:
However, we don’t keep a list of these activities out in the open which means we sometimes forget – or “forget” – to do a particular task.
By creating a checklist of tasks required to call a work item “done” and posting it in a visible location (like a wall), this helps keep everyone on the team honest and makes sure that no tasks are forgotten.
I recently stumbled upon a good post that Mike Cohn wrote a a while back on his blog about the problems that often arise from textual communication.
It is especially meaningful how he relates this, from a software development perspective, to requirements documentation and the impact it can have in that respect, as well as the day-to-day e-mail traffic that goes into and out of… mostly into… my Inbox.
I often find myself among the minority of developers who, instead of firing off an e-mail, opts to pick up the phone, or stop over for some face time with my fellow business users, business analysts or project managers. Perhaps that is the weakness of IT: brilliant (usually) at analytical and technical skills, but lackluster in social interaction skills…
Think back on the past week. How often have you opted to write an e-mail to a co-worker instead of pick up the phone or walked 10, 20, (or, god forbid, 50) feet to the person’s desk? Worse yet, how often have you been part of a conversation that took place entirely via e-mail. You know, the kind where a dozen (or more) people are included in the e-mail chain — 18 of which could care less about the discussion?
(I know I’ve brought that issue up once before…)
It is at times like these where I stand up, blow the virtual whistle (loudly) and suggest (strongly) that we schedule some face-time to hash out this discussion in person (or at least via conference call).
Now, think about what agile methodologies and practices propose to combat this issue…
Daily scrum meetings?
On-site / Nearby customers?