Having spent a good part of the past several months talking to companies about agile methods and what it means to be agile, we have found people to be very receptive to the benefits of working in ways designed to emphasize communication, collaboration, working software, and embracing change. At times, however, near the end of a discussion in which a potential client truly seems to be “getting it”, they will ask a question or two that shatters that illusion. Usually it will be about budget and/or project definition and will often involve a request for a proposal in which the cost, time frame, and features to be included are all fixed.

We are getting pretty good at talking people away from that ledge but we still aren’t perfect. The simple answer we could give them would be that because they desire to fix cost, time, and features, there is only one place that remains to flex: quality. If there is anyone who hates cutting corners and producing an inferior product more than software developers, it is clients who rely on such software. Why is it, then, that so many companies believe that you can attempt to hold all the variables of a project constant?

We can talk until we are blue in the face, quote industry experts who have been through the trenches, and point to numerous failures in RUP or waterfall projects we have been a part of but nothing seems to work as well as pointing to big, respected companies that are doing what we suggest. Toyota (practically invented it), Netflix, and Google all use agile methods to accomplish great things. Now we can add Adobe to that list. A recent interview with lead architects at Adobe explains how they changed the development cycle for the development of the forthcoming CS3 product suite and underscores the point about how quality often gets squeezed out of traditional software development projects.

The change we made was going from a traditional waterfall method to an incremental development model. Before, we would specify features up front, work on features until a “feature complete” date, and then (supposedly) revise the features based on alpha and beta testing and fix bugs. But we were scrambling so hard to get all the committed features in by the feature complete date - working nights and weekends up to the deadline - that the program was always very buggy at that point. We’d be desperately finding and fixing bugs, with little time to revise features based on tester feedback.

At the end of every cycle, we faced a huge “bugalanch” that required us to work many nights and weekends again. Of the three variables: features, schedule, and quality, the company sets the schedule and it’s only slightly negotiable. Until feature complete, we could adjust the feature knob. But when we hit that milestone, quality sucked and we had only a fixed amount of time until the end. From there to the end, cutting features was not an option and all we could do was trade off our quality of life to get the quality of the product to the level we wanted by the ship date. We’ve never sacrificed product quality to get the product out the door, but we’ve sacrificed our home lives.

Of course, Adobe is going to say the only “flex-point” in the system was the work-life balance of its employees and that their new product is of the highest quality, but that cannot be true. The late nights and stress involved in this type of “cram-it-all-in” development style inevitably causes a degrading of quality over time coupled with the opportunity cost of additional features (and the underlying value to the business they represent) that cannot be created.

Many companies are throwing around the term agile when defining who they are and what they can offer but, as the Agile In Action blog points out, many may not be practicing what they preach.

In this post I have collected some of the telltale signs for use when determining if a company is truly agile:

“Notice the characteristics of communications with the company. One of the things I notice are the amount of red-tape involved in setting up any meetings. The more paperwork the worse it is likely to be. Long company email signatures can be the first clue.

Companies with dress down Friday who display a large cardboard cut-out of what garments constitute casual wear want drones and probably don’t encourage new ideas. Motivational posters decking the walls could be a hint that the management team is clueless.

Companies with very swish offices tend not to understand the need for developer messy thinking tools such as whiteboards. Conversly, companies whose offices look in a poor state of repair are probably also neglecting their computing infrastructure so developers will have a hard time setting up development environments, etc.

A clue that teams may be open to new ideas can be books (fiction or technical) and newspapers around. Personalised team environments can hint that the team are trusted and allowed to make changes in their space. Seeing developers talking to each other around a whiteboard or screen rather than with headphones on can also hint that they are open to reviewing ideas with their peers.”

[Rachel Davies]

“It‘s difficult to characterize an entire organisation as ‘Agile’ without working with them for a while either as a partner or as a member of staff - you need to assemble some tacit knowledge about that companies’ culture and decision making process.

It‘s much easier to analyze a specific product development team as you can look at their environment, team identity, output etc. There are a couple of properties one can extrapolate from such a team to it‘s surrounding company - is the team empowered to perform its function? is there respect between the team and the company? does the team have a clear project charter and product owner? You can get a pretty good feel for what the company is like from these kind of indicators.

It‘s also good to look at the relationship the company has with its partners and suppliers - do they enter into mutual benefit partnerships and work proactively with suppliers to improve both companies’ positions? Essentially you’re trying to determine how much trust exists in these relationships - it‘s not the only indicator but it is a useful one - it allures to the underlying culture of an organisation.

Structurally I would expect an Agile organisation to be ‘wide and not deep’; management hierarchy and bureaucracy is kept to a minimum with workers being aligned along product streams rather than into functional hierarchies such as ‘technology’ and ‘hr’.”

[Gus from JavaShed]

(more…)

Part of the reason it has been a bit quiet around here is that we are busy taking the advice of Guy Kawasaki and others and have started a company.* Refactr is just a weblog no more. Now we are poised to take our message and skills to the masses (starting with the Twin Cities), develop powerful new software with people, and change the way people who do what we do for a living are perceived.

The truly exciting thing for us is that we get to utilize much of the process and methodology we bring to rapid software development and apply it to starting and running Refactr. Guy (if I may call him that) has outlined many ways of starting a company in an agile way.

Take a look at the Great ideas for starting things chapter from the Art of the Start (PDF). It is great stuff - making meaning, making mantra, and especially, the advice you hear from most entrepreneurs, “just start”.

There has been a lot to do to get ready for this point: There’s incorporation, drafting operating documents, filing federal tax documents, opening bank accounts, setting up payroll services and accounting systems, purchasing equipment (15.4″ MacBook Pros woohoo), and lining up projects - but we don’t let that stuff bog us down. We are outsourcing anything that is not in our core set of competencies, we are going to stay small, and we are going to form lasting relationships with everyone with whom we work. Oh yeah, and we’ll probably get a trio of those sexy Apple iPhone’s when they come out as well.

So that’s it, Refactr is open for business. We hope to find some people out there who are as excited about software as we are, but have, perhaps, had less than ideal experiences with software development or software developers. We’ll change their minds.

* OK, so Guy didn’t give us this personal advice but his great books and blog pretty much pushed us off the cliff on which we were standing.

Seth Godin is a bit nonsensical in some of his arguments for why small companies can compete against and even outperform larger ones (i.e. he cites the growth %’s of small companies compared to larger ones as evidence). Even though his latest book: Small is the New Big is just a compilation of his articles and blog posts, and does not have a unifying message (which I consider essential in a book) he does makes several good points regarding the effectiveness of small teams and I wanted to discuss a few of them here:

Small means the founder makes a far greater percentage of the customer interactions. Small means the founder is close to the decisions that matter and can make them, quickly. Small means you can tell the truth on your blog.

This may be the biggest benefit of smallness and is one of the key advantages Refactr has over traditional digital agencies and consultancies. The entire company is focused on the project during its engagement. There is is a real relationship between the entirety of Refactr and the client team. And yes, we don’t have to try to sound bigger than we are because we are not ashamed of our size.

Small means that you can answer email from your customers.

Another benefit of small is that you don’t have communication channels. Or more correctly the channels of communication are a circuitry connecting each team member with each other. No bottlenecks, no games of telephone.

Small means that you will outsource the boring, low-impact stuff like manufacturing and shipping and billing and packing to others, while you keep the power because you invent the remarkable and tell stories to people who want to hear them.

We are small enough to not have to worry about many of the things with which large companies must deal - administration overhead, interviewing, hiring, payroll, accounting, marketing, sales, we outsource any of these services that we need. Online payroll and benefits, external accounting and sales resources, and very low administrative costs all add up to more time and energy we can spend doing what we are passionate about, building great software.

A small law firm or accounting firm or ad agency is succeeding because they’re good, not because they’re big. So smart small companies are happy to hire them.

To succeed as a small company you have to be good. You are not afforded the “luxury” of being able to hire B, C, and D-teams to do the “less important project work”. Every project we take on is important and every project warrants and receives our best efforts.

The kind of project that’s “interesting” is now very different. It doesn’t have to be strategic or scalable or profitable enough to feed an entire division. It just has to be interesting or fun or good…

That is good news for us as we like to work on fun and interesting work and are able to choose work based on these merits and how they fit within our model, but it is equally important for the people who’s projects of which we are a part. Now entrepreneurs with a great idea are on an equal footing with large companies wanting to outsource a smaller project - each can take advantage of small, talented teams like Refactr and come out of the process with a great result. We have already had offers to take on additional resources or join larger organizations, but we have made a conscious decision to remain small for the foreseeable future for precisely some of these reasons above.

Kerry Buckley wrote a great post that made me laugh and think.

When people talk about large organisations making major changes to their core processes or values, sooner or later someone will compare the process to steering a supertanker – if you turn the wheel now, you’ll have travelled quite a distance before there’s any noticable change in course.

This analogy falls down when you’re trying to introduce agile software development. If you want to be agile, a supertanker just won’t do the job any more. It’s time for small teams to jump into the lifeboats and set off in their own directions, leaving the heavy old legacy systems to continue their progress on their predictable course. The lifeboats are far nimbler and can react much quicker to changing conditions.

I rather like the visual of agile teams racing around in swifter craft (though I would perhaps not have chosen the lifeboat, perhaps a hovercraft?) encircling and aiding the larger, more lumbering ships. We have been drawn to work with smaller companies and less entrenched processes because we saw good opportunities to connect and create some early successes. What Kerry’s analogy made me think about, however, is that nimble teams and new perspectives can be welcome in any fleet and that there is opportunity for cooperation and accomplishment in large companies looking to react and perhaps capitalize on speed just like the little guys.

In Cargo Cult Network Administration, Esther Schindler in her weblog for CIO Magazine discusses an interesting problem that is similar to that of hiring and Interviewing Programmers. This is by no means a new idea, but it did get me thinking again. The example has to do with network administrators, but I’ve seen exactly the same behavior in developers - as I’m sure we all have.

… the dangerous stage of career development is the the cargo-cult sysadmins, who don’t know why what they’re doing works (or doesn’t work). But, because the magic worked in the past, they continue to repeat the same actions, under the presumption that it will continue to work.

Seeing people in action can help to reduce the possibility of hiring one of the Cargo Cult, but it’s sometimes difficult to see the difference between someone using a pattern or rule of thumb because they understand it and because it works and those doing the same without understanding any of the underlying principles. Often times, you really only find out which one you have is when something doesn’t work and they need to dig in and troubleshoot the problem. Just knowing where to start looking can be a good indication.

As an (only somewhat related) aside, I’m reminded of developers that have little to no understanding of general web principles, such as HTTP. They can do a fine job, but sometimes tracking down what is happening and why that something is happening (whether in your code or in a web framework), it helps to think about the actual interaction between the web browser and web server. Now, this isn’t even fully necessary to be a good web programmer, but I think it distinguishes those who understand what’s going on from those who just guess at (or just take on faith alone) why certain parts of code are being executed.

The other day I heard a piece on NPR about American Airlines involving their mechanics in making decisions about how to run a maintenance facility.

At first, [VP Carmine J.] Romano was wary of the idea that the only way to avoid bankruptcy was to start sharing his power with his union workers. But a deal was worked out. The 6,000 mechanics in Tulsa agreed to a significant cut in salary, benefits, and vacation. In exchange, the workers would have equal input in running the operation. Two years into it, the veteran company vice president is a true believer.

What was a dysfunctional relationship between management and the union has become a very collaborative one and brought the facility back from the verge of bankruptcy. To stay competitive, the airline needed to cut the time it took to do a major overhaul in half. The mechanics went to work and completely redesigned the way their work was organized.

This reminds me of Mary Poppendieck’s thoughts on Lean Programming - a term she coined after applying the principles of Lean Manufacturing to software development. Especially relevant to this story is Lean Rule #5: Empower Workers (Decide as Low as Possible)*:

A basic principle of Lean Manufacturing is to drive decisions down to the lowest possible level, providing both the tools and the authority for people “on the floor” to make decisions.

The thought is that those closest to the real work are in the best position to make decisions because they are the ones with the most information and they fully understand the implications of all the tradeoffs involved.

The idea of empowering workers to make decisions helped Toyota improve quality and productivity at a GM manufacturing plant. For American Airlines, it helped to involve workers in a plan to improve productivity at a maintenance facility, which reduced time and cost, while increasing quality. In addition, it saved the plant from having it’s work outsourced to South America and instead turned it into a profit center for the airline - in fact, airlines from South America are now flying planes to the US for maintenance at this facility. By sharing decision-making with workers, management was able to win concessions from the unions, which was also a big factor in saving the facility. Though people were initially skeptical of the plan, this agreement has turned out to be a win-win for both the union workers and American Airlines.

Hearing the story on the way home, I thought it was a brilliant move by the airline - and really smart for the workers to accept the plan as well. What really struck me was that management was willing to release full top-down control. It’s one of those things that makes a lot of sense to me - if you have competent employees, let them do what they know how to do.

_{* Apologies for the lack of a direct link, but there are no html anchors in the article.}

Alexander Kjerulf posted some time back about how secret salaries are a bad idea. Here are his major reasons:

1. It frustrates employees because any unfairness (real or perceived) can’t be addressed directly.
2. They’re not secret anyway. People talk, you know.
3. It perpetuates unfair salaries which is bad for people and for the organization

I have been involved in situations that were complicated by people not knowing how much those they work with made and, in addition, not understanding how certain people/positions contribute to company success. In many cases the speculation and perceived injustice is much worse for people than coming to grips with the fact that someone might be more valuable in their current position than they are.

A couple benefits to being open and honest are:

1. People don’t gossip as much
2. Bad feelings about salaries do not linger and fester, they come to the fore sooner.
3. There is greater trust in “management”.
4. There is a thought that effort, skill and knowledge are rewards.
5. A greater effort may be given because people feel that effort and good performance are fairly rewarded.

I think the idea of open salaries is a great idea and one that I would put in place were I to run a company.

[source: SuccessFactors Blog]

I have been on too many projects where the discussions went way overboard (many times through my own causing.) It is so easy to fall into the trap of “let’s just discuss it quick” and one hour later still be debating the finer points of a relatively minor architecture issue. The truth of the matter is this happens more frequently for teams that don’t do pair programming. When pairing is used, the discussions tend to be shorter and you are generally still working while you are debating. So the question is, how much time should “discussions” take?

Here is a simple scorecard you can use to figure out if you have beat-the-horse-dead.

Tally your total points and see below

Now take your TOTAL answer and multiply it by 10 minutes. In the absolute worst scenario the discussion should only take 60 minutes.

If your TOTAL was zero or negative, you should be doing more development and less “discussing.” As a rule of thumb you should limit all design conversations to ten minutes, anything over is waste. If you find your conversations are getting out of control try some of these tactics to reel them back in.

• If you aren’t already pairing, do so. Sit down and pair for a few hours. You will get so much more done than having a 30 minute debate about if you should use polymorphism or delegation.
• Start a team decision maker baton. When you get hung up in a debate, it is the person holding the baton’s job to step in and make a decision. After the dispute is settled pass the baton to a new team member to solve the next problem. This way everyone at some point will be the final decision maker which will foster collective ownership.
• Remember winning the battle doesn’t mean you are winning the war.
• For 90% of you, relax and remember, you are just building a social networking app for teens. It isn’t pace maker firmware.
• Cite actual evidence; show patterns or examples of others in the industry that are doing it like you are proposing.
• Take precedence of a solid object model that represents your domain and reduces your complexity *** (I highlight this one because I think people sometimes take exception to it. Some argue if you spend time on a “solid object model” you are building more than you need right now. I argue it is generally as easy to build it the “right” way than to piece it together the wrong way. When there is a significant difference in time (hours) between “ways” choose the faster, (and I know this is many times at the heart of debate). If they are pretty close in time, (within hours) choose the one that reduces and cleans up your model. Performance should not come into consideration at all at this point.)
• Tell your partner this time we do it his way if next time he promises to do it your way.

I hope these few simple tips will help you save time and headache in your next design discussions.

Somewhere between the long nights troubleshooting the CSS and XHTML for the new Alt Text and the creation of not one or two but three lists of tasks that needed to be completed for the site to be “just so” I mentioned to Jesse the things I still needed to do before I launched. He told me something interesting, and off-handed. He said “Just launch it, that’s agile baby.” Now I may be paraphrasing a bit but that is the gist. I laughed him off, thinking that launching a half-finished redesign of my personal blog is not really what the agile method is all about. But as it turns out Jesse was right. I finally did allow many of the tasks on my list to flow onto the “after launch” list and even some big ones to be open for public help. The way I looked at it, the new design represented a pretty big improvement (even with the bugs) over the older one and I just needed to get it out there.

It turns out Guy Kawasaki would agree. I am currently reading his last two books:The Art of the Start and Rules For Revolutionaries and there is a lot of similarities with what he is saying and what folks like 37signals are preaching. Kawasaki tells us in Rules for Revolutionaries that we shouldn’t fear shipping an imperfect product…

Revolutionary products don’t fail because they are shipped too early. They fail because they aren’t revised fast enough.

He goes on to quote Winston Churchill:

To improve is to change, to be perfect is to change often.

Although he calls it churn, Kawasaki is really talking about constantly changing and refactoring your products be better. He illustrates the Japanese model as it contrasts with the traditional American way:

American:

Concept –> Engineering –> Marketing –> Customer

Japanese:

Concept –> Engineering –> Customer –> Churn (repeats as a circle)

You must plan for change and embrace it in your products life cycle. Furthermore you should change your product for your users, not for your non-users. This may seem to make sense but many companies ask, “What would our product need to have in order to increase market share?” That is the wrong question. A better question would be “what do our user’s need to make their lives easier?” or “how can we allow our customers to use our products less?”

Though only somewhat related to this post, Guy Kawasaki’s The Art of the Start presentation this past May at TiECon is worth checking out.