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.
Let’s consider the following statement:
Don’t always deliver what the customer wants;
Always deliver what the customer needs.
There’s a subtle distinction between the two parts of the above sentence, but it’s an important one.
Most of us have heard the argument "Do you really need that?" at some point in our lives, usually when it has to do with something we really want, and are willing to argue passionately about its inclusion in the realm of all things necessary. Usually, this "voice of reason" manifests itself as a parent, spouse or some incorporeal, 3-inch tall, white-robed, haloed dude – or chica – hanging out on your shoulder.
But I digress. The point is that it’s a good question to ask ourselves. Do we really need something, or is it just something we desire to have?
All too often, we – the technical folks – will get a long list of requirements from our business stakeholders, some of which are necessary for them to do business, and some of which are fluff features, or “nice-to-have’s”. Unfortunately, it’s also common for these different category of features to be lumped together into the same set of requirements, and it’s difficult for us to tell which is which. It’s our own fault; we’ve conditioned our business partners to think this way.
So how do we tackle the list? Generally, I’ve seen it done one of a couple ways:
Both scenarios have major implications. In the first, we risk burning out our teams, the business partners, or both. Burned-out folks tend to leave, or produce lower-quality results. In the second scenario, we are putting the decision of what is important to the business in the hands of the technical folks (as opposed to the hands of those who are actually doing the business work). I’ve got another post planned for this second scenario, so I’ll just leave it at that for now.
Half of the Agile Manifesto talks about promoting Customer Collaboration and drawing focus to Individuals and Interactions. So, the first step is to get the business partner involved in the planning of what gets worked on first. After all, they were the source of the requirements, so they should have a good idea of what’s most important to them.
Using iterations (the backbone of iterative and agile methodologies) can also help to promote adaptive and risk-based planning by forcing the team (which includes the business partners) to decide on a subset of requirements to implement during each iteration. Responsible teams will choose features that are the highest priority. (Note the word responsible in that last sentence. Agile practices alone do not a successful team make). Iterations also help the team to "course correct" between iterations of a project if they start going in the wrong direction, or if changing business needs dictate a change in what features are most important.
And while I’ve said this before, I must stress it again. Get the customer / business partner involved. Let them tell the team what they need, and what they want. And, like that voice of reason, the team should sometimes question their needs to make sure they really are needs, and not just a want hidden behind charismatic arguments.
For the last couple of months, I’ve been leading an adoption effort at work to migrate developers away from our current version control system over to Microsoft’s Team Foundation Server. During this time, I’ve been approached with a number of questions regarding best practices around source control usage, causing me to brush up on my own level of knowledge on the subject.
Recently, I was asked the following question: When should I check in source code that I’m working on? At first, this seemed like a trivial question. But, since I didn’t have a good immediate response at the time, I figured it can’t be all that trivial.
So, upon further reflection – and consultation with several fellow developers – I’ve compiled the following list to be good situations in which committing changes to source control is a good idea.
You should check in files…
In what other situations would it make sense to check in files to source control?
I work in a financial company, so this analogy is especially poignant to those I work with.
We all know – or hopefully should know – the risks associated with being in financial debt. At times, it makes sense to go into a little debt to buy something we can’t yet afford out of pocket (like a house or a car). If we get into too much debt though, we end up paying all of our money in interest and don’t have enough to pay down the principal. Eventually, we may default or go bankrupt.
The same idea can be applied within IT. Ward Cunningham coined the term Technical Debt to refer to instances where a developer chooses a poor design over a more well-crafted, sometimes “more expensive” design (in terms of time and/or effort). At times this make sense – such as if we want to get something out to production sooner to take advantage of new features.
It’s important to identify these risks and be sure to pay down the “principal” (through refactoring and re-designs) over time so that we don’t bury ourselves in too much of our own technical debt. And, just like when paying down financial debt, it’s ok to pay down a little at a time (through small design changes/refactorings) instead of trying to make one big “payment”.
Think about any projects or systems you have on your team. Are you incurring any technical debt from those systems? Is that “interest” hindering your daily activities? In what ways could you try to pay down that debt today, if you had the time?
Some food for thought…
During the first week of March, I co-presented on a topic about iterative and agile software development to a group of Business Analysts within the company I work for (which follows traditional Waterfall practices). It was a good presentation, and I had a great time doing it. I wished there was more time to field questions, because it seemed like there was definitely some interest (or at least some curious minds).
What I found most interesting was how I had to adapt my presentation to the audience. Talking about pair programming, test-driven development and continuous integration is not as important to a group of BAs as it would be to a group of developers. Instead, I focused more on the benefits of moving from BRUP to more JIT requirements, and trying to justify why it’s ok to define high-level requirements up-front, yet defer the details until the point where the development teams are actually going to implement them.
With any luck, there will be some ensuing discussion about the merits of agile and iterative practices; if nothing else, it will have been an opportunity to get some new ideas into a few more minds…