Friday, November 28, 2008

Flow - Building Lean Teams

There's few things more detrimental to the productivity of your thought workers than the interruption of flow, yet I think that so few teams recognize its importance. Demarco and Lister describe flow as

"a condition of deep, nearly meditative involvement"

Flow is a requirement in what we do. It's extremely productive time that increases quality, creativity and an overall feeling of accomplishment at the end of the day. For most, this state of immersion takes a bit of time to get into, but takes a split second to get out of.

In my experience, email and IM are disruptions that you can more easily tune out, or just flat out remove by turning them off. But the biggest disruption of flow that I've come across is when someone stops by a co-worker's desk with a "Hey, do you have a second?" Instantly the flow is lost. Your second is given to that person, at the expense of 15 minutes more of your time to get immersed again.

Say you have 5 of those interruptions a day (which is probably pretty conservative for most people), you've got nearly and hour and a half of interruptions. Tack on a few meetings, and you've got a half of a day of productive time on what was scheduled at 8 hours.

If you have taken the time to recognize this issue, often times what the response is, is to start padding scheduling. You start to say, "Jim is only productive 50% of the day". This results in timelines being pushed out or features being cut, and the overall sense that it takes forever to get stuff out the door. Not only that, but Jim doesn't want to be 50% productive. He want's to be 100% productive. He wants to feel like he knows where his day went.

It's easy to measure your flow. You can count the number of uninterrupted work hours per day. If you make it from 9-11 AM without an interruption, you've got 2 hours of uninterrupted flow. I'd challenge you to try measuring that with your team. I'd bet you'd be surprised at the ratio of uninterrupted hours to hours worked.

What can you do to curb interruptions? Designate certain hours in the day when people are "publicly available". Organize your space so that it's conducive to flow and impedes interruption.

If you need to make a case to higher-ups on the impact of flow, you can try measuring a developer who has usually low uninterrupted work hours, and put them up in an office for a week. Measure their uninterrupted work hours then. Say that they usually have 3 uninterrupted work hours for every 8 they work when they aren't in an office, but they've got 6 uninterrupted for every 8 that they work when they are in an office. By rearranging you've made them 50% more productive.

Protect the flow.

Sunday, November 23, 2008

Traditional Quality Assurance is Wasteful - Building Lean Teams

The traditional view of a software development team almost always includes some form of a quality assurance team. The classic QA team does some sort of formulated inspection of the product, balancing risk, time and resources with an end goal of eliminating as many defect leaks as possible.

The huge myth with this traditional view, is that the quality assurance team is your primary defense against delivering defects to your customer. In actuality it's far from being the most effective prevention. Building quality in to the product is the single best defense against introducing defects into a live system. Teams with agile approaches including unit tests and continuous integration are by nature building quality in.

There's a huge amount of waste in the traditional quality assurance team. So much time is spent making sure they are covering all the bases. You need to make sure that everyone on the team knows the product well enough to write detailed test cases. Even once a decent functional understanding is developed, there's still so much technical knowledge missing. What code is shared? Where could some concurrency issues occur? Those kinds of questions are rarely something that is answered by this kind of team.

It's also extremely difficult to staff a traditional quality assurance team. There's extremely high turnover in the position and general poor quality pool of candidates. To combat this, usually this function is shipped offshore, exacerbating the inefficiencies.

So many other inefficiencies stem from the formation of a QA team. For instance, how can a QA team write test cases if they don't know what the software is supposed to do? This leads to big up front designs (BUFD) and puts even more pressure on the design/development gap. Another inefficiency is the amount of effort that goes into maintaining the relationship between developers and QA. There's always a tension between the two teams that usually stems from under-communicating and a lack of mutual understanding.

If you've got a development team that's good about writing unit tests, uses continuous integration, and has a good grasp on unit test coverage, then you'll almost always find that a QA team offers little or no help in the quality of your application, and is far more of a distraction from getting things out the door. You may feel like arguing against the quality assurance team is an argument against quality, but it isn't. It's an argument for a lean team that builds quality into software that's getting out the door.

Saturday, November 22, 2008

The Design/Development Gap - Building Lean Teams

As teams grow larger, they tend to want to start the design for V2 release during the development of the V1 release. The thought process here is that you can get more features out the door. Why waste months doing waterfall linearly, when you can do waterfall in an offset parallel fashion? It's more productive, right?

This results in the introduction of roles like Business Analyst or Program Managers. Often these roles are filled by persons with primarily a project management based background, and less of a technical background (although most i've worked with have had a small amount of technical experience.) Usually this position is tasked with taking a rough list of high level features, and defining all the details in a functional spec.

The problem with this, is that when developers have little or no input into the details, they tend to lose any sort of emotional connection with the feature. By handing a developer a blue print, you give a position that's used to wired to think creatively, no opportunity to be creative. The more and more functionality that thats dropped on their desk in the form of a function spec, the more and more distant they become with what they are building.

The productivity loss as a result of this gap between design and development almost always rears it's ugly head first during the estimation process. A feature that the developer has no connection with will always result in a bloated estimate.

If you're thinking that you're going to get more productive by further parallelizing your waterfall process right now, you're dead wrong. Get the features into the developers hands to do the design. Work with them and be open to new ideas, coach them on what's important to the customer and the business, and make sure your vision is clear to them.

By doing this, you'll see that you've got developers who are designing great things, and are pumped to be coding them. You'll also see that your "wow" features will increase, as your developers will start thinking about how they can make this one little thing cooler by using Google Charts, or smart Ajax, or rich DHTML.

This is the kind of productivity you need. You don't need lots of features, you need great features, and closing the design/development gap will get you there.

Upcoming Posts on Building Lean Teams

The current economic environment has got me thinking a bunch about what some of the things that are important ingredients in a lean software development team. God knows that now is the wrong time to be on a team that's struggling on getting things out the door and into customers hands. Those that are providing real value, faster and at lower cost are the ones that are going to rise to the top in this climate.

Over the next few posts, the topics will be about what I'd describe as a few reflections on what it is that I think drives productivity, creativity and valuable output on software development teams.