It’s Caves AND Commons…

Posted by indomitablehef | Filed under Anti Patterns, Agile, Productivity

…not Caves OR Commons, and not Commons only.

Australian scientists have reviewed a global pool of research into the effect of modern office design, concluding the switch to open-plan has led to lower productivity and higher worker stress.

“The evidence we found was absolutely shocking,” researcher Dr Vinesh Oommen from the Queensland University of Technology’s Institute of Health and Biomedical Innovation, said.

“In 90 per cent of the research, the outcome of working in an open-plan office was seen as negative, with open-plan offices causing high levels of stress, conflict, high blood pressure, and a high staff turnover.

If you have to choose one or the other, you’re better off giving everyone a cave than forcing everyone into a common area. It’s feasible to cram multiple developers into a cubicle for pair programming and collaboration. It’s not feasible to focus and achieve “flow” in an open plan office when working alone. The last time I worked in such an environment, it turned into a shanty-town. Developers would build little “forts” around their half-cubes with marker boards, stacks of books, and pieces of cardboard. They’d hang up signs saying “do not disturb”, and invest their own money in expensive noise-canceling headphones - just to be able to get a little work done once in a while.

Amazingly, this is one of those fundamental things that almost nobody gets. I’ve never worked in any place that got it right. Software developers are expensive resources, especially good ones. And as a manager, you would think that getting the absolute most out of that expensive piece of equipment would be one of your top priorities. Instead, developers are crammed into cubicles instead of offices, and at worst, forced to sit out in an open floor plan. It’s money down the drain.

How about a little math?

Let’s say you’ve got a good developer, and he makes 90K year.
Now let’s make some assumptions…hypotheses, if you will.
1. Assume that working in an office would make him more productive by 1/2 hour per day, over working in a cube
2. Assume that working in an open floor plan would make him less productive by 1/2 hour per day than when working ina cube.
3. Assume that having an office with a door, and a common area to work with and collaborate with a team would make him more productive by 4 hours per week.

There are 260 working days per year. Assuming an 8 hour day, your developer’s half hour is worth approximately $21.60. His four hours per week is worth approximately $173.

So, in one year:
1. If you give him an office, he is more productive to the tune of 21.60 x 260 = $5,616.
2. If you sit him in an open floor plan, he is less productive to the tune of $5,616
3. If you give each developer an office, and the team a common area to collaborate, each member of the team is more productive to the tune of 173 x 52 = $8,996

Assume your office floor plan will last 3 years or more and you are considering an open floor plan. Can you afford some sort of an office for every developer for less than $33,696? Not a corner office with a view, mind you…just walls and a door.

Assume you have a team of 6 developers, average salary of 90K, and you are considering an open floor plan (for 3 years)…can you afford to set up offices and common areas for less than $161,928?

Can you afford not to?

(I think my productivity assumptions are highly conservative, and that the real return would be much higher. Probably double. Maybe more.)

Also, I have at least heard of one place that got it right: Joel Spolsky’s Bionic Office.

Table Stakes

Posted by indomitablehef | Filed under Agile

In a card game, “Table Stakes” means that you can only play with what you have on the table.

All poker games are played table stakes. This means one can only bet what one has in front of him on the table on any given hand. Players cannot reach into their pockets and add to their bets. If a player runs out of chips in front of him in the middle of a hand, he or she is considered all-in.

The same principle applies when your are planning a project, a release, or a sprint. Whether you’re limited by a fixed budget, a hard delivery date, or just a self-imposed sprint or release length, you can only plan for how much you have on the table. I recently worked on a project where I violated this principle. Working with the customer, I hashed out the requirements and gave them rough estimates. It was a fixed-bid project, and when we added up the estimates, it came out to nearly double the budget.

Under pressure to do so, and against my better judgment, I agreed to get started working. I warned the customer that we were over budget, and that we’d have to make cuts. But I agreed to work through the first (1 week) sprint, and do that “cutting” the next week. When that next week came, I again warned the customer that we were not going to get done, and that we’d have to make cuts, but I again agreed to wait till the next week. And so on, and so forth. In the end, expectations were never realistically set, and no one was really happy.

Rookie mistake, I know. But now I have a label, something I can use to remind myself never to do that again. And I can the Table Stakes analogy to explain to customers why I won’t do it. From now on, we’re not done planning and ready to get started coding until we have gotten our list of requirements down to something we can actually do in the time allotted.

AgileOfficeEssentials.com

Posted by indomitablehef | Filed under Agile

Monday marks the official launch of my new blog/business idea, “AgileOfficeEssentials.com“:

AgileOfficeEssentials.com is about the work environment, equipment, and supplies that enable Agile software development teams to work more effectively. It’s about working arrangements that enable both collaboration and concentration. It’s about creating an environment that encourages innovation and creativity. It’s about breaking free from cubicle-farm despair and “open office” frustration. It’s about being Happy where you work.

In its current incarnation AgileOfficeEssentials.com is a blog devoted to the physical trappings that make an Agile Office: Office layout, agile teamrooms, pair programming setups, Caves and Commons, whiteboards, Information Radiators, continuous integration build indicators, sit/stand desks, etc. Check it out, tell your friends/boss/space planner, and please feel free to comment/discuss.

Getting Real

Posted by indomitablehef | Filed under Agile

I just finished reading Getting Real, a book by 37 Signals. I can’t recommend it highly enough. Their own promo review quote says it best:

“Every once in a while, a book comes out of left field that changes just about everything. This is one of those books. Ignore it at your peril.”

-Seth Godin

You can read it for free online, or buy a PDF or paperback.

Here’s a quote:

A happy programmer is a productive programmer. That’s why we optimize for happiness and you should too. Don’t just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here? Would you truly be happy working in this environment eight hours a day?

and another:

Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn’t a true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on: “Wait, that’s not what I had in mind.” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.

and one more:

Our favorite answer to the “why didn’t you do this or why didn’t you do that?” question is always: “Because it just doesn’t matter.” That statement embodies what makes a product great. Figuring out what matters and leaving out the rest.

Acceptance Tests

Posted by indomitablehef | Filed under Agile

This post is all “out of order”, since I should probably talk about User Stories first, but I feel guilty for not posting often enough, and when I have something to post, I reckon I’d better just throw it out there…so here goes.

Read up on User stories here: http://en.wikipedia.org/wiki/User_story

For every User Story, we should have one or more acceptance tests. I use index cards, (4×6, but I wish I had stuck with 3×5). I write the user story, title, number, and effort estimate (in story points) on the front of the card. I write the acceptance tests on the back of the cards. Like everything else along the way towards agile development, writing user stories and acceptance tests is a growing process. Our first pass at acceptance tests for our stories was woefully inadequate, but it got us used to the idea and got us thinking in the right direction - believing in the principle.

Now, we’re working on getting better at it -writing “good” acceptance tests. Remember that user stories are written by users. So are acceptance tests. Still, everyone will need coaching, and sometimes hand-holding. Take it slow, be a salesman, not a tyrant. (something I have to remind myself of)

Acceptance Tests
Think of them as a script that you will eventually use to evaluate whether a story is complete. Imagine a scenario where you write the story on the front of the card and hand it to the developer. When the developer is done, he returns the card to you. You then flip it over and proceed through the acceptance tests, and if all the conditions you specified are satisfied, then the story is done.

Acceptance tests are “black box”: that is, they focus on expected results or observable behavior. Avoid design discussions whenever possible.

An example:

Story: Add Patient Health Risk
The Clinician selects a drug from the patient’s list of drugs, and enters a Health Risk related to that drug. He selects Risk category/subcategory from drop-down lists (see cat/sub-cat list), and selects severity (severe, critical, major, moderate, minor) and status (identified, opened, closed-resolved, closed-unresolved, pending) , also from drop-down lists. He can enter notes for the HR and Sub-Category specific details (see list of detail fields for Health Risk sub-categories).

Acceptance Tests
1. A Clinician can view a patient, select a medication, and choose to add a Health Risk specific to that medication.
2. A Clinician can enter category/subcategory/status/severity/notes/sub-cat-details for the Health Risk and save it.
3. A Clinician can view a list of Health Risks for a patient and see, at a glance: Drug/Cat/SubCat/Severity/IdentifiedDate, Status. List should be able to “group by” the available columns and filter by status/severity combinations, as well as Identified date ranges.
4. The system automatically records status change dates and user info whenever the status of the Health Risk changes. Status history info is available on the Health Risk detail view.
5. The system will not allow the Clinician to add multiple Health Risks for the same drug with the same category/subcategory.

Things to notice:

• #3, #4, and #5 are not specified in the original story. These are the kind of undiscovered requirements we hope to uncover while writing acceptance tests.
• #4 is packed full of undiscovered requirements:
  • It mentions a “Health Risk Detail View” not discussed in the story – a requirement tucked into a prepositional phrase at the end of an acceptance test.
  • “whenever the status of a Health Risk changes” – when does the status change? At the very least, this probably means that the user can edit the Health Risk, but this hasn’t been mentioned yet, either in the story or the acceptance tests. It could mean more: are we expecting the status to change automatically based on some event? Better find out now.

Some questions to kick start the brain when writing acceptance tests:

• I will know this story is complete when:
• I will be satisfied that this is done when I can:
• For this to be complete, the solution must be…
• For this to be complete, the solution must have the following qualities:
• When complete, the solution must meet the following conditions:
• When complete, the solution must conform to the following standards:

Agile Project Management

Posted by indomitablehef | Filed under Agile

I’m working on some more thoughts on managing projects on an agile team. I’ve been doing some reading on the subject, and trying to make it work in my organization. Until I have my thoughts ready to post, I’ll share a couple of the things I’ve been reading/listening to:

Managing the Work in an Agile Project - Dan Rawsthorne, PhD, CSM

Agile/Lean Documentation: Strategies for Agile Software Development - Scott Ambler
and check out the Featured Webcast (I can’t link directly to it, so find it on the page), at IASA - Scott Ambler on the basis and implementation of agile architecture.

It’s pronounced Co-Burn

Posted by indomitablehef | Filed under Agile

Interesting audio interview with Alistair Cockburn over at itconversations.com, where he discusses agile development and some of its history. I enjoyed it, and recommend the book, too.

Refactoring

Posted by indomitablehef | Filed under Agile

Some people will tell you that “Refactoring” is just another word for “rework”.

Almost, but not quite.

Properly understood, “refactoring” implies an important distinction: it doesn’t change the end result. Refactoring is changing software code in order to improve its internal structure, without changing its external behavior. [Fowler] So, when you decide to change how the system works, fix something that doesn’t work now, or add something that wasn’t there before, you aren’t exactly “refactoring”. Those are all activities you will engage in during your Iterative Development cycle, to be sure, but Refactoring is something else.

When you refactor, you improve the design of existing code. You redesign the internals, but what the code actually does doesn’t change. Usually this is done to make future changes to the code easier. It can be understood to improve the application overall, but only if the application is intended to grow and change after the refactoring. If you are looking at an application you have no intention of changing and that works as it is, there’s no reason to refactor.

There are a couple of situations you may find yourself in that will drive you to refactor. If you look at the code and realize that it doesn’t effectively communicate the proper meaning and structure you intended, refactor. This can be as simple as changing the names of classes, properties, and methods to make them more descriptive of what they do. It can be as complex as taking an application built on Table Module and Transaction Script patterns and converting it to a Domain Model with Data Mappers.

You also refactor in response to gaining new understanding. If some part of your application seems clumsy, as you proceed through your Iterative cycle, it may be a clue that you need to refactor. When you suddenly gain new insight into “how the business works” based on your collaboration with project stakeholders, you will often want to refactor that new understanding into your domain model. Refactoring in the domain model is a high-value target during your development cycle. Sometimes it takes some commitment to take the time to do all the work required to embed your new knowledge into the domain layer, but it is usually worth it.

Refactoring is a much discussed topic in Computer Science. I can hardly do it justice, considering the volume of resources available on the subject. For now, I’m going to direct you to some of those resources, and bid you Godspeed. Next time, we’ll talk about the safety net you’ll want to employ while refactoring: Test Driven Development.

Refactoring Resources:

• Refactoring with Martin Fowler: A Conversation with Martin Fowler, Part I
• Refactoring at Agile Alliance.org
• Martin Fowler’s refactoring.com
• Xp’s “Refactor Mercilessly”
• Database Refactoring
• A Story about refactoring
• Resharper

Books:

• Refactoring: Improving the Design of Existing Code
• Refactoring to Patterns
• Refactoring Databases: Evolutionary Database Design

Active Stakeholder Participation

Posted by indomitablehef | Filed under Agile

As mentioned in the previous post, one of the key success factors for doing iterative and incremental development successfully is Active Stakeholder Participation.

…Active Stakeholder Participation is an expansion of eXtreme Programming (XP)’s On-Site Customer that describes the need to have on-site access to people, typically users or their representatives, who have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements, and prioritization thereof. While this level of participation is required to make your software development efforts effective it often isn’t sufficient in many organizations, particularly those where politics and not reason are the order of the day. Project success often requires a greater level of involvement by project stakeholders – senior management needs to publicly and private support your project, operations and support staff must actively work with your project team towards making your production environment ready to accept your system, other system teams must work with yours to support integration efforts, and maintenance developers must work to become adept at the technologies and techniques used by your system.(agilemodeling.com)

Whether you are attempting to put Iterative Development into practice or not, having this kind of cooperation from the customer/client/user/stakeholder is key - obstacles to good communication and cooperation with stakeholders are obstacles to writing good software, plain and simple. The realities of time, distance, politics, access, priorities, and personalities can get in the way of the kind of cooperation we want. Users and stakeholders themselves can be an obstacle:

Customer buy-in on the development process, particularly end-user involvement, is crucial. Insufficient end-user involvement is the number one reason why projects fail. Unfortunately, some customers resist getting involved. “Why should I spend time thinking about what I want?” they complain. “I’m paying you a lot — you go figure it out!” In fact, in such cases, the customer is delegating the definition of the problem rather than the task of solving it. That is why it is important to get their buy-in on the development process during project start-up.(Cardozo, 2002)

First and foremost, the responsibility for creating the kind of collaborative environment required to develop useful software falls upon you, the software developer. You must become evangelist, negotiator, counselor, beggar, cat-herder, and knee-capping thug in order to get the kind of cooperation you need. You’ll need to bargain, seduce, cajole, empathize, threaten, feint, jab, pick-and-roll. No one told me I would need those kinds of skills when I was studying Computer Science in school. It’s not enough to be a really smart guy, or to write really “good” code (as opposed to really “useful” code). Unless you are content with having someone to blame for your failures, be prepared to gird up your loins and wade into the fray, in order to snatch victory from the jaws of office politics.

Some tips on recruiting your customer into the active participation you need from them:

1. Learn about their business, and let them see you do it.
   Show a sincere interest in learning everything you can about how they do business. Never take the attitude that you have “some great ideas for how you can do things better”, or demand “business process re-engineering”. Instead, be humble, and be hungry and thirsty for knowing everything about their business. When they are confident that you really understand them, they will trust you more and be more willing to work closely with you.
2. Explain the idea of “Ubiquitous Language”
   When you express to the customer that “I want to learn to speak your language”, they will teach you. Again, stay humble. Don’t start trying to teach them new words, or change the names that they call things. If they need help hashing out the meanings of things among themselves, you should be a neutral facilitator whenever possible, or just stay out of it entirely.
3. Use “Inclusive Modeling Techniques”
   Don’t try to teach them UML. Most people, however, can learn to interpret boxes, lines, stick figures, and arrows on a whiteboard. Use simplified diagrams, index cards, post-it notes, string, modeling clay, legos, lincoln logs and large mounds of mashed potatoes if you have to. Whatever it takes to get clear understanding between you and the domain experts/users/customer/stakeholders.

Worth reading again: The seven habits of effective iterative development

Iterative and Incremental Development

Posted by indomitablehef | Filed under Agile

There are many aspects of software development that are often given “lip service”, but (relatively) seldom implemented successfully. Near the top of this list, you’ll find the next three topics we are going to cover: Iterative and Incremental Development, Refactoring, and Test Driven Development.

We’ll start with Iterative Development:

The basic idea behind iterative enhancement is to
develop a software system incrementally, allowing
the developer to take advantage of what was being
learned during the development of earlier, incremental,
deliverable versions of the system.
Learning comes from both the development and
use of the system, where possible. Key steps in the
process were to start with a simple implementation
of a subset of the software requirements and
iteratively enhance the evolving sequence of versions
until the full system is implemented. At each
iteration, design modifications are made along
with adding new functional capabilities. [1975, Vic Basili and Joe Turner, see reference below]

It is hard for thee to kick against the pricks

As we said before, “you never know enough.” Rather than treat this as something that went wrong, such that you have to retreat to a previous stage of development and re-consider your design, we will embrace it. We’ll not struggle against it, but instead use it to shape our new modus operandi. Rather than a sequential, phased approach of analyze, design, build, deploy, we “iterate” over the problem, beginning with the simplest part, and aggressively refactoring to make the application better and more complete with each iteration.

At the beginning, don’t even try to include all the features you do know about. Take a simplistic view of what appears to be the core of the functionality you intend to deliver. Begin with the core. Do the simplest part in your first iteration. In your second iteration do the hardest part. Or part of the hardest part. Let the software grow and get better and better.

Sounds simple enough, but in practice the entropy of the waterfall model is often hard to shake. Without Active Stakeholder Participation (which we’ll discuss next), it’s sometimes not even feasible. If you can’t get cooperation from the customers, you’ll have no choice but to compromise in your attempt to employ this model. That doesn’t mean you have to abandon it completely. You can do internal iterations, among the development team, and still get some benefit from that. Whenever possible, though, you should demand access to and cooperation from the users/stakeholders of the system.

Incremental Development, then, is an approach in which features of the application are delivered to the users in increments, in whatever order is most beneficial. So, you carve up the application’s eventual feature set into manageable chunks, and deliver them one chunk at a time. In many cases, the final product cannot be delivered piecemeal, however, so sometimes your “increments” are internal to the team. It’s still a useful approach, however. At the end of each increment, the team will evaluate their approach, and use what they learn from that in the next increment. Each increment will contain several iterations, where the team iterates over the feature set intended for that increment, until all the planned features for that increment have been completed. (clear as mud?)

Recommended Reading:
Iterative and Incremental Development: A Brief History (pdf)
Another Look at Incremental and Iterative Development(page13) (pdf)

Lest you think think me an expert, (or for those of you that know me, lest you think me full of shit), let me say this: Every project I have worked on so far has had at best an imperfect, flawed implementation of Iterative and Incremental development. Some projects have been closer to the ideal than others, but none has yet matched “how I think it should be.” I’m out to change that, however. In Drive.

With that in mind, check out: The seven habits of effective iterative development

Reference: Vic Basili and Joe Turner, 1975, from
R. Zultner, “The Deming Approach to Quality Software
Engineering,” Quality Progress, vol. 21, no. 11,
1988, pp. 58-64.cited from Iterative and Incremental Development:A Brief History