July, 2008
A Backlog for Ruthless Prioritizing
Submitted by Matthias Marschall on Thu, 07/31/2008 - 21:24
So far, I've talked about how I went for Introducing agile practices to manage a remote development team as well as User Stories - Making Sure Your Customers Get The First-class Seats. While User Stories are a good start, enforcing ruthless prioritization of these stories can really streamline your development processes.
Priorities get mixed up when you're doing to many things in parallel
One of the worst things about dealing with too many issues at once is that every one of them seems to be the most important one when you're looking at it by itself. The reason for such misjudgment is that while you discuss one issue via chat, phone or email, you often don't see the whole picture. Before you know it, you're constantly changing priorities and generating a lot of context switching in development.
Starting more work does not lead to faster results - on the contrary!
If you keep talking constantly about all your issues, you tend to think that everything is being worked on in parallel even if you have only one developer. So your expectations rise to unrealistic levels and you tend to push harder (often to the misfortune of both product quality and your team's morale).
Avoiding Code Inventory with Staged Releases
Submitted by Dan Ackerson on Tue, 07/29/2008 - 21:27
Have you ever found yourself in Sprint 4 or 5 without a single release under your belt? Is it because the new functionality involves a big database upgrade or depends upon coordinating three or four different departments? Not only does this kill motivation, but it's extremely risky to push out this mountain of code and configuration changes to production all in one release.
User Stories - Making Sure Your Customers Get The First-class Seats
Submitted by Matthias Marschall on Thu, 07/24/2008 - 21:26
In my last post about Introducing Agile Practices to Manage a Remote Development Team I described the issues we faced with our existing development process and provided a step-by-step overview of the agile practices we implemented. In this post, I want to introduce you to the concept of User Stories and how you can use them to streamline your development process and put your users first.
Concentrating on Individual User Values Instead of Complete Feature Sets
One of my main concerns was the mix of topics being simultaneously discussed: Complete new modules and single features as well as typos and minor layout enhancements. To simplify discussions, I asked everyone to break down bigger features into individual user functionalities - User Stories. Instead of trying to fully specify a complete module like Questions & Answers, we started to talk about things like
"As a user I want to be able to ask questions so that I can solve my issues with my car" or "As an expert I want to be notified about new questions regarding my field of expertise so that I'll be able to help quickly".
Get Your Team Working Together
Submitted by Dan Ackerson on Tue, 07/22/2008 - 21:09
Let's face it, compared to other engineering disciplines software development is just coming out of the stone age. Heck, I'm sure I'll get a lot of flak for even suggesting that software development is an engineering discipline (though I have to admit the way a lot of developers go about their work, calling it engineering does seem a bit of a stretch). Real life is seldom black and white, but I'd like to describe the two basic camps below.
Serial processing through departments for Release X.Y.Z
Most of us have worked at a place like this and, unfortunately, most of us still do. You know what I'm talking about - a traditional shop running with the waterfall process. Each department spends months working on a feature that ultimately, not many people are thrilled about releasing.
Introducing Agile Practices to Manage a Remote Development Team Series
Submitted by Matthias Marschall on Fri, 07/18/2008 - 06:30What would you say if I told you that you can double multiply the output of your development team while simultaneously increasing quality? Let me show you how I made this happen in a small team a couple of months ago.
What Developers Want
Submitted by Dan Ackerson on Tue, 07/15/2008 - 21:37
Developers are people too. Believe it or not, they have needs and wants just like everyone else. Here are some, which the Operations department should be able to satisfy for a more harmonious and productive workplace.
Robust development environment
Just as sysadmins have those black sheep servers in the back of the server room used for testing the latest and greatest version of sysinstall, developers need a dedicated sandbox where they can try out all their great ideas. Give them some elbow room in their development environment (at least 4 GB of RAM), plenty of disk space (500 GB) and a quad-core workstation. What in the world would they need this much power for on their desktop? Virtual machines, heap dump trace analysis, and virtual machines. Did I mention virtual machines? These give developers the means to run their own test environments directly on their local system saving both you and QA a lot of time and hassle. Imagine simply giving the disk image you used to install the production instance configured with cfengine to the developer to run! Now any configuration change you make in the master test environment can be broadcast right to the developer's machine.
6 Bad Ways of Conveying Urgent Tasks (And How to Fight Them)
Submitted by Matthias Marschall on Thu, 07/10/2008 - 21:30Sometimes, due to the high urgency of issues, the owners of tasks are not patient enough to use your standardized way of filing a ticket in your issue tracking system. Instead, they resort to various ways of conveying the new task to you or your team, disrupting your seamless ticket flow. Here's a list of some of their favored weapons (from least devastating to most):
Continuous Integration Helps Find and Kill Bugs
Submitted by Dan Ackerson on Tue, 07/08/2008 - 21:27
Today, automated test builds are a goal of most development shops, and Martin Fowler's article on Continuous Integration provides an excellent overview about the major aspects. Regardless of where your team is on the path to achieving this goal, here are a few hints how to ease your way.
The committer pulls test coverage out of the team
At the start, your test coverage will be somewhere between nothing and miserable. But, remember, you already have an ace up your sleeve. That's right, put the "Committer" to work enforcing test coverage for every bug fix and new, complex code changes. Bug fixes are exceptionally interesting code changes. First, they show a place in the code that's actually used by customers! This is really important information if you know that only about 30% of your code base will really ever get used. Additionally, it makes a lot of sense to write a test for this piece of code (would have made more sense to do it for the initial release, but baby steps to success) as it broke already once. As for complex code changes, I'm talking about things like nested if declarations - these are usually ugly to read (and harder to understand) so why not just enforce test coverage for them.
The Importance Of Having Seamless Ticket Flow
Submitted by Matthias Marschall on Thu, 07/03/2008 - 06:30I don’t know about you, but I want to organize my day's work as it suits me. Sure, there are the inescapable meetings, which block part of your day, but the rest of it (hopefully most of it) should be under your own control.
Issue Tracking as Pull System
To enable developers and sysadmins to be able to organize their day, we established a pull system for tasks to be done. We usually do a weekly planning meeting where the team takes on an amount of work, which the team feels comfortable of being able to deliver. Out of this pile of work, which we manage in an issue tracking system, everyone can “pull” a task whenever he likes during the week. This sounds like a pretty optimal process, right? But this is where real life kicks in: During the course of a week a lot of new, urgent things pop up, which need either immediate, or at least short term, attention. Often, these things can’t even wait a week to go into the next planning cycle.
How Leasing Can Improve Cash Flow and Uptime
Submitted by Dan Ackerson on Tue, 07/01/2008 - 21:00If your company is strapped for cash, buying a new file server for $10K is a lot of money. But you might not have to shell it out all at once if you consider leasing or cloud computing. Although you ultimately end up paying more, going in front of the board and explaining an extra $300 per month expense for expanding your file server capacity is a lot more easy than asking for a "one time", ten thousand dollar payout.
