Main menu:

Site search




Branches beware

December 31st, 2018

The use of branches for software development has become too commonplace. And no wonder, services like github have the best tools for reviewing and team collaboration on changes made in branches. If your team isn’t having discussions about how you use branches, you should, frequently. I’m not saying that branches are always bad, just that they should be used carefully.

A metaphor that I like for branches is that they are like ticking time bombs. The reason is simple: you should value working software, green builds, and quality designs and implementation over everything else.

When changes are checked in frequently to the mainline the potential magnitude of explosions resulting from breaking changes is small. Small problems are easy to fix so it’s easy to keep your software in a good state. On the other hand, the longer a branch is actively worked on without merging into mainline the bigger the potential explosion. Large changes result in large problems and these slow you down.

You may be thinking that sometimes you need to use branches to make large changes. Challenge yourself to think about the problem differently. In my experience, any large change can be made in mainline incrementally. It may take slightly more effort but the results are often better. For example, a few years ago my team realized we needed to change the database tech in our stack. Instead of working in a branch we put the new tech stack into production and routed all data into the old and new systems for a few months. This allowed us to make a data-driven decision on the superiority of the new solution because we compared behavior using the same data over a period of time. We were then able to switch to the new system and delete the old system without any of our customers noticing anything other than better performance. It was so cool.

Summary: keep branches small and merge frequently. If you think a long-running branch is necessary challenge yourself to find another way. You’ll get more done in the long term and be under less stress as a team.

Great by Choice

November 26th, 2011

I just finished the book Great by Choice by Jim Collins and Morten Hansen.  It is an excellent book and I rank it in the top tier of business books alongside Jim Collins’ earlier work Good to Great.  Great by Choice is a comprehensive study of elite companies that all outperformed the market by 10X and each company is contrasted by a comparison company that was in the same market and stagnated or disappeared.  What grabbed my attention was that all of the factors 10X companies used to achieve success were essentially practices of what I consider sustainable development.

There are many lessons to draw from Great by Choice that apply to software development.  I’ll highlight a few.

The 20 Mile March

The 20 mile march is the sustainable pace that the 10X companies used to get new products and services to market and to grow their company.  The 10X companies didn’t over-extend themselves, instead they deliberately held themselves in check and kept marching at a deliberate pace.  Their competitors on the other hand were sprinting ahead and while each sprint would sometimes leave them ahead they would lose their momentum and fall behind again.  It’s a variant of the classic tortoise and the hare parable.

This is exactly sustainable software development.  It’s not about hacking something together and rushing it to the market.  It’s about moving as fast as you can, but ensuring you are taking the time to get user feedback, design as you go, write automated tests, etc.  You have to find the right amount of discipline for your team, since you don’t want to hold yourselves back by for example demanding 85% test coverage on all new code.  Hacking products together to meet some artificial deadline rarely ends in success simply because of the technical debt that accumulates: you spend so much time after that date fixing the product that your team is shackled with cleaning up when they could be building the next big thing.

A Fanatical Sense of Discipline

The 10X companies were highly disciplined in their approach.  During the good times they stockpiled more cash than their comparison companies and when market conditions changed they didn’t lurch from decision to decision they analyzed the situation and then acted.

Discipline is critical in sustainable software development.  If you need to rush a product to market to beat the competition do it with discipline.  For example, do some design work so that after you ship the first version you can circle back and rebuild some of the components.  This is exactly the approach we used at Alias when we shipped the first version of Sketchbook.

There are many other aspects of discipline which are all critical for software development.  Stay focused on what you are building and don’t stop doing regular design, testing, code reviews, etc.

Fire Bullets, then Cannonballs

Most people in the software industry understand the value of prototypes.  The 10X companies relied on them: instead of investing in a product that nobody wants the 10X companies would focus on finding out where the opportunity is (firing bullets) and then once they found it they would add resources (fire cannonballs) with discipline and win.


It’s a great book and well worth the time, especially if you read it with sustainable development in mind.  Enjoy!

Agile Leadership

November 13th, 2010

Recently I attended the Cutter Consortium’s annual Summit in Boston as a panelist for Jim Highsmith’s talk on Agile Leadership.  Jim’s talk was great and got the attendees thinking and talking.  On the plane flight there I jotted down my thoughts on this topic, which is an important one because of how management / leadership has been dealt with by some people in the agile community, and thought I’d share what I wrote down.

The opening of Jim’s talk was perfect because he framed the agile leadership dilemma perfectly.  Some people in the agile community would have you believe that the role of the manager is to “buy pizza and get out of the way” (Jim’s words).  And why not?  When you have a self-organizing team who manage their own plans and choose their own work and clearly outlined roles like product owners isn’t that all you need?

The biggest thing I’ve seen team leaders struggle with is finding ways to add value, and that’s in general not just with agile development.

Many leaders try to add value by being better than everyone else on the team at tracking risks and dependencies.  They spend all their time trying to understand projects and connect the dots and people together to ensure people are talking and working together.  Unfortunately, this doesn’t scale and I’ve seen many teams where the people on the team get lazy and lack accountability; if details are missed it’s not their fault because you didn’t notice.  You definitely want your team making as many decisions as possible, thinking about risks, etc.  And owning them.

Many team leaders turn themselves into administrators in an attempt to add value.  They take on all the project scheduling, paperwork, status reports, meeting scheduling, etc. so that the team doesn’t do it.  Unfortunately, this doesn’t work either because it removes you from the project.  You really are just buying pizza and getting out of the way.  You need to do some of these things but it’s best to keep your team in tune with what the rest of the organization needs (like status reports), since that’s the best way to ensure your team continues to survive.  They need to be aware of how they are presented and have a voice in those presentations whenever possible.

Obviously, I believe that leadership is really important.  As I state in my book, I believe it’s critical and has to come from all levels: executives, team leads, developers, QA, usability, etc.  So how do team leads and executives add value in an agile culture?  Here’s my list.

1. Focus on Quality and Priorities

Successful projects start with a focus on quality.  You need to be the leading advocate and live and breathe quality.  Never let your team take shortcuts, make sure they do prototypes when needed, and above all be uncompromising because it’s not a trade-off.  Why?  In my experience, quality gives your team freedom: freedom to be flexible and responsive (agile), freedom to innovate, and freedom derived from the trust of your company and customers to go in whatever direction required.

Setting clear priorities goes hand-in-hand with a focus on quality.  Don’t let your team take on too much work, and make sure that everyone knows what the highest priorities are.  Your job is to help the team balance capacity with demand, because too many teams try to take on too much and wind up being less efficient than they should be and producing a lower quality product than they could.

2. Challenge the Status Quo

One of the key lessons I’ve learned in my career is that every situation and team is unique.  Think kaizen every day: learn, adapt, evolve, and embrace the fact that there is always something that could be better.  It’s your job to help find it and make it better and to create a culture where continual and gradual improvement is an accepted and routine practice.  And never ever go “by the book”; think of everything you know as a toolbox and look for ways to learn new techniques and ideas to expand and change your toolbox so you can employ your tools more effectively.

3. Set Clear Expectations and Follow up in Regular 1:1’s

I’ve found that it’s very helpful to have clear, written, expectations and to hold weekly or bi-weekly 1:1’s with the people on my team.  As a leader this is one of the most important things you can do.  Not only are you making it clear how they are being judged, but this is a unique opportunity to talk about what is important to the team, give feedback, and to listen to and get to know the people in your team.

Even in highly capable agile teams you can play an important role in helping people grow and develop.  You need to help people develop the right level of autonomy, accountability, and responsibility for their role on the team and personality.  And I’ve found that most people need help with time management, understanding the benefits of their work, and getting the work done so those benefits are realized.

4. Be Patient & Persistent

One way to think of your job is as a gardener.  Part of your job is to plant seeds of ideas and cultivate them; it might take a while for some seeds to bear fruit but it’s usually worth the wait.  And it’s critical to know when you can wait and when you can’t.

5. Keep Your Brain On

Credit for this phrase goes to a former boss; you need to stay alert to what is going on around you.  Remember that you’re in a unique position to observe and listen.  Ask lots of questions and listen carefully to what people are saying, their body language, everything.  It’s amazing what you’ll uncover.

And finally, I’ll end with this thought:

More them, less you = Success. — Marshal Goldsmith

Planning and Commitments (Or a Lack Thereof)

June 11th, 2010
schedule One of the more uncomfortable negotiations between a product team and business people typically happens at the start of a project. This is where the business people want to know what the team can deliver so they can communicate to customers and investors and the team is looking for guidance as to what they should build.

This situation can get uncomfortable if one or both parties are afraid, unwilling, or unable to commit. The business people don’t want to communicate unrealistic plans and the team doesn’t want to be locked into an unrealistic schedule. As my friend Gerry Hawkins said to me in a recent e-mail, this could lead to an endless round of questions: “what do you want?” from the product team and “what can you give us?” from the business people.

Agree on the Vision First

Make sure everyone is one the same page at the highest level first. What are you trying to build? Who is it for? Why are you building it? Who are your main competitors, and what do you think they are doing or going to do?

If you can’t agree on the vision then there is no point talking about anything else.

Understand Value

The next level down from your vision is understanding what value you are providing to end users. In particular, are there any areas where your company / team can provide unique value that your competitors are not likely to?

Stay away from checklists of features to compare with competitors. What can you do that your competitors can’t? Can you offer superior consulting and support? Can you get your customers involved in your development? Can you use telemetry to provide a unique level of service to your customers? The goal is to talk about VALUE with customers, not features, because if your product is being compared with others solely based on features you’re in big trouble. This should change how you communicate with customers too, since it shouldn’t just be about features. And this should help take the pressure off the internal negotiations.

One technique I use to drive all our discussions is the idea of value streams. Every high-tech product or service has a number of areas where the team provides value. For example, in one of my past teams we focused on a small number of areas: visual quality (to improve realism) and workflows (so our end users could create compelling presentations without a lot of work). Your goal in each release is to make progress in each area, and make sure you have the balance right between these areas.

Note that you don’t always need to invest at the same level in each area; the advantage of keeping value streams in mind is that it helps you focus on what is most important to your situation and have discussions around how you want to invest in each area. You might choose in one release to have a big push on one stream, but that should be a conscious decision by your team. It’s too easy sometimes to let a heavy burden of work in one area overwhelm your team and take over, which would hamper progress in other areas. Do it consciously, don’t just let it happen over time!

Use a Kanban

Use a Kanban for your priorities. A kanban is great because it puts your priorities in a visible place where everyone can look at it. Make sure your kanban never exceeds the capacity of your team to deliver and that on the kanban you highlight the value streams in a visible way. And be creative! Use different colors for your unique value streams for example. That way, you can tell from 50 feet away whether you have the balance right between your various value streams.

As with the above items, have lots of discussions around your Kanban before you dive into the details around individual features. I’ve had a couple cases where we’ve used the kanban to do iterative planning, where in each iteration we go through the kanban, changing priorities, breaking down some items, putting estimates on them, etc. This helped us converge on a roadmap and proved to be an excellent way to capture our backlog too.

Write User Stories

Once your priorities are sorted out, write user stories for each feature and make sure the stories include some idea of completion criteria. This is essential to ensure that everyone agrees on what must be built.

Don’t Hold Back

If you still find yourselves going back and forth make sure that all concerns are in the open.

A common problem for the development team is technical debt: if the code base is hard to modify, doesn’t have adequate test coverage, and expensive to change then you need to get some work onto your roadmap to gradually fix it. A word of advice: when you do fix it make sure that the changes are driven by business need and not out of a purist sense of the code not being good enough because it never will be!

For business people, make sure that the development team understands the business. Do you need to make a profit quickly so you can get a new round of investment? If the development team doesn’t understand then how can you expect them to have the same sense of urgency?

If users are involved, make sure your concerns are heard too and that you believe in the user stories. It is critical that if you aren’t comfortable that you say so, and as early as possible!


If you still can’t agree don’t be afraid to iterate from the vision down as many times as needed. Keep talking and above all don’t give up!

Don’t Fly Blind

May 9th, 2010
Flying blind Very few professionals would consider running a business without having reliable revenue and cost data.  Yet there are many software development teams who forget that having data to monitor the business of software development is critical.  Of course it’s hard to measure revenue, but we can definitely measure the costs and gather data that are indicators to show how efficient a software project is.

Why is having data so important?  Here are a few reasons:

  1. You can’t hide from facts.  Numbers can be misinterpreted (more on that below) but they don’t lie.  Having a gut feeling that a project is proceeding well isn’t good enough.
  2. Data often provides an early warning that can be used to get a project back on track with minimal effort.
  3. Data focuses minds and sparks conversations.
  4. If it isn’t visible it isn’t important and it’s usually just talk.  If you want your team to think something like quality is important, and you want to reward them for it, it must be visible.
  5. Published data ensures transparency.  Transparency inspires confidence, both from executives but also with customers and end users.
  6. Data helps with decision-making and is essential for critical decisions such as whether to cancel a project.

The Danger of Taking Data Too Seriously

There’s no question that having current data for analysis and discussion is critical to success, but you have to watch out for the dark side. Unlike revenue and costs for a business, much of the data you can collect for software projects is open to interpretation and too open for over-analysis.

For example, I know of one group that decided to achieve 100% test coverage. The team’s manager introduced bonus incentives for everyone on the team. They hit the target but their product didn’t ship because it was less stable than previous versions. Why? Anyone who has written a lot of automated tests knows that it is really hard to test that last 10% of branch conditions; the special cases that aren’t supposed to happen but often do. The solution this team reached was to delete those branch conditions so instead of returning from a function when a pointer was null for example the function would continue execution until it crashed.

The key point is that you need to keep your brain on when analyzing data. Use the data to make rational decisions, change conversations, and guide your business. Every number has a story behind it: concentrate on the stories not the numbers.

Essential Metrics

There are a few pieces of data that I think every software team should have. These are:

  • Historical bug count trends. Every team should have a weekly (automated) report mailed to the team and management that shows the bug trends, by severity, of at least the previous six months to the current day. Why? You need to keep discussions about quality front and center and the bug count is the best indicator that is not open to interpretation. If a course correction is needed, it’s much easier to do it when you’re dealing with an increase of 10 bugs versus 100 accumulated over a few weeks.
  • Test code coverage. A monthly report that shows the historical trend on the percentage of source code covered by automated tests for each area of your project helps spark discussions about areas of code that need more coverage. Automated testing is the best way to keep your team productive and away from boring manual tests that can best be done by a computer. I call this the ruthless testing mind-set in my book.
  • Source code versus test code lines of code. A monthly report that shows the historical trend of total lines of code for source and automated test code for each area of your project, minus comments and blank lines, is a useful report to compare with the test coverage. All you really want to verify with this report is that your team continues to add test code at an appropriate rate for source code growth. If you have an area of code that is being added without tests you can catch it quickly and stop adding technical debt to your project.
  • Source and test code modifications per developer. This one has a big-brother potential to it so be careful! However, I have found it useful to get a monthly report that shows how much source and test code was added, modified, and deleted by each developer in my team. It’s not that I don’t trust them, but rather that I use this as a good way to ask questions. Quite often I’ve found cases where someone is struggling with a problem and they’ve been afraid to speak up. The solution is often simple and I can help get them back on track. Of course, I’ve also found some rare cases where someone needs a reminder that they need to contribute, but I’d rather have that conversation after a month of relative inactivity than a few months…!

The Future: Live Telemetry

A couple of years ago I read an article about Rolls Royce’s jet engine division that has inspired me. Rolls Royce collects live data via satellite from every one of their engines world-wide that is in service. They are able to detect and diagnose problems in real-time, send notices to airlines about servicing requirements for engines, and even in rare situations tell an airline that a plane in flight needs to shut down an engine. This is an amazing level of service that has led to increasing revenues for Rolls Royce and a new business model.

The main point of Rolls Royce’s engine monitoring is that they are able to provide a service that is highly valued by customers. Google also collects vast amounts of data on its users and they are also able to provide a google toolbar with type-ahead for common searches, and these are also valued services. These are features that users value and keep them using Google’s services.

It is my belief that there is a huge opportunity in the software industry with the collection and analysis of live telemetry data. We of course have an obligation to end users to ensure that sensitive data is kept private, but if we can do that then there are opportunities to create new value and revenue streams, as Google and Rolls Royce have discovered.

One of the biggest challenges that I see with live telemetry data is analyzing the data. For example, in my current team we have a huge database that is updated every time a user starts or quits our application, plus all reported errors and warnings along with stack traces. It’s a vast amount of data and I wish that we could analyze more of it. What I’d really like is some kind of dashboard to be able to watch and analyze the data and only dive into the details when I want. We have to invest in that next, but talk about a huge opportunity! We’ve already had a few cases where we’ve seen users get an error repeatedly and sent them a fix without their asking. I want more of that!

The Off-site Customer

April 18th, 2010
Vidoe conference Most of the original agile methods have an explicit or implicit assumption that there is an on-site customer; a customer working in close proximity with the team.  Having the dedicated attention of customers who can write or help write user stories and provide continual feedback is a great idea.

I confess however that I’ve never been on a project where we had an on-site customer, yet we’ve been able to cope. The reality that I’m more used to is attempting to build a product for a diverse group of end-users, most of whom are off-site (or far enough away that they might as well be) and too involved in their daily work to pay much attention to what my team is doing.  This “degree of separation” from users mostly limits feedback to bug reports and feature requests; users are typically good at pointing out problems and are rarely able to see beyond their immediate work. And this means you can’t count on consistent priorities or even requests; that even if more than one user requests a feature you can bet they have a different idea of how it should work.

A worst-case outcome when dealing with a diverse customer base is a frustrated team and users. One symptom of this type of environment is silent users, who put up with poor workflows and stop speaking up because they feel their input isn’t being heard.  And your team will complain about users who are never satisfied, constantly changing requirements even with upfront definitions, and who don’t give feedback until it is too late.  Water-cooler grumbling conversations rule.

Here’s a paragraph that my friend Kevin Tureski from Alias sent me which speaks to the heart of this problem: “A fundamental premise of agile development is that by adapting to feedback on working software at each iteration you can spiral inwards to a solution that provides better value than is possible by holding a detailed upfront definition constant. But what do you do when your end users (or end user representatives) don’t provide a clear consensus on what they want or change their minds each time their input is needed or aren’t very accessible? How can we ensure that the project doesn’t spiral outwards due to conflicting or changing requirements? How can we find the right balance between ‘barely essential’ requirements while preventing feature creep?”

What to do? Here are a few things that have worked for me.

Start with your Mind-set

Start with your mind-set about the kind of relationship your team has with end-users.  Instead of referring to end users automatically as customers, see if you can think of them as partners instead.   The reason is that if you think of them as customers you are re-inforcing a degree of separation that might work in the restaraunt business but rarely works in the high-tech industry. 

You don’t decide what a successful product is, the end-users do.  You need to engage them and involve them in novel ways and build an environment where everyone is working together to create the best possible solution, where ideally there’s a joint sense of ownership.


If you want users to be engaged with your team you have to give them as much visibility as possible into your work.  Hold regular status updates and show them your priorities.  If you’re dealing with a number of teams or companies try and get them all in the same room for the status updates and give every single person the chance to give you feedback on your progress and plans.  This is a great way to bring out discussions on conflicting and overlapping requirements.  And don’t hold back: if a project isn’t going well say so, why, and what you’re doing about it.  This kind of transparency helps to inspire confidence in your team.

User Representatives on your Team

The Scrum agile development method has the role of a product owner.   It’s a great idea.  You need someone who owns the problem of speaking to end users, watching them work, and bringing all the feedback with clear priorities to the team. 

In my experience a role that is just as critical as a product owner is someone who uses your product in realistic ways.  E.g. if your product is used by 2d artists hire one or two and seat them in the middle of your team.   They will speak a different language sometimes but encourage and treasure that because they can speak to end users in terms they understand and will learn to translate what is required to your team.  And if at all possible, try to keep your user representatives working on a realistic project just as users would use the product.   You can use their work for demos but their work will help push the product and find problems faster.  It’s critical that you orient your testing towards more realistic scenarios as opposed to doing mindless sweeps through the product looking for bugs.

Feedback, Feedback, Feedback!!!

You can never get enough feedback.  Be creative and use as many different ways to get feedback as you can.  Do demos at the end of every development cycle.  Hold user focus groups.  Do usability testing with paper prototypes and working code.  Write user stories and run through them with end users.  Get them involved in planning of features they care about.  Do surveys, especially if you can get anonymous feedback.  Make it super easy for end users to report problems to you; anything you can do to lower barriers to providing feedback.  Be creative and find the people who give the best feedback and work closely with them.

Have a Vision

If you don’t know what your future is chances are you won’t have one.

Have a vision and longer-term goals.  Unless you’re on a one-off project, this is critical.  Very few end users can see beyond their immediate problems.  Find the people in your user community who think longer-term and involve them in regularly reviewing longer-term priorities and goals. 

Create the vision yourself if you have to.  If you don’t have an idea where you’re going you’ll spend all your time responding to requests, and in my experience what usually results is that users get more frustrated over time.  Your team will too; one of the strongest motivators for people is working on a project that is bigger than themselves, that is challenging, and that has a future. 

Ensure that the majority of the work you do is helping to build for that long term.  That doesn’t mean you avoid doing what users ask for, it means that you do that work in a way that helps build towards the future.  And yes, that means avoiding quick fixes.  If you have to slap a project together under high pressure, do a prototype and be prepared to largely start again if you have to. 

Clear Priorities

It’s critical that your team has a clear sense of what is important and what isn’t.  I use a project kanban board in a visible place.  It has three columns: highest priority (95% of the team’s effort goes here), next  (5% effort), and parking lot (0% effort).  I also keep a spreadsheet backlog where I keep good ideas and old parking lot items.  The key idea is to keep only the features the team is currently doing in the first column.   That sounds easy but it requires a lot of discipline because you need to use the board to have pointed conversations when a seemingly high priority feature comes in.  Have discussions like that in front of the kanban and if it really is higher priority figure out when and how to slot it in.  The kanban helps avoid making decisions purely on gut feel and constantly changing priorities which can impede a sense of progress.

Get the Facts

 Don’t rely on gut instincts to find out how your product is used.  Another post is coming on this topic shortly, but the idea here is to automate gathering of data on how your product is used, how often they use it, and the problems they have.  Think about all the data that Google has on you; why can’t you gather the same kind of information?

Give them a Sense of Ownership

Find as many ways as you can to get end users involved in the project.  One idea I like is to form a guiding council, where you get representatives from different companies or teams together to give you input on direction, priorities, and focus.  Great conversations will result and the increased transparency is good for everyone.

Another way to give a sense of ownership is if you can open source your project, especially if your end users are in the same company.  This is another form of transparency, but it also allows you to create workflows where they contribute to the project too.


The end goal in everything you do is to make sure your end users understand how critical they are to the success of the project.  You have to work extra hard to get them involved, but in the end it’s worth it!

Outsourcing: Cost-cutting and Efficiency

January 24th, 2010


A topic that is widely discussed today in the high-tech industry is outsourcing. The recession has pushed the industry past the tipping point, and every medium and large high-tech company plus many small ones are doing or setting up development in low-cost centers. For better or worse, outsourcing is here to stay; it’s time to move on, embrace it, and change our conversations.

The discussion we should be having is how to work more efficiently and how to achieve sustainable long-term success. Many high-tech companies, and most of the large ones, are already inefficient; outsourcing simply adds to the problem. Outsourcing is less efficient because of the greater amount of communication, review, and management (bureaucracy) required. Most companies don’t work efficiently when they start outsourcing, and outsourcing just makes the problem worse. However, investors and executives don’t notice because of the dramatically lower costs. For example, there are many manufacturing companies that ship partially assembled goods many times across the ocean. It’s so cheap that there aren’t enough people questioning the sustainability!

In my experience a change in process and mind-set can result in infinitely greater benefits, and those benefits lead to sustainable development and a competitive advantage over the long run. Outsourcing by itself will not lead to a sustainable advantage. In my current team for example, compared to three years ago we support twice as many customers, support three times as much source code, and we’re innovating on new workflows that will help our customers do more with fewer people. And most importantly, our team is 20% smaller. Those are measurable benefits that are a sustainable competitive advantage, but these results take hard work to achieve.

The question is, does outsourcing make your company more competitive? In the short term, simply through lower costs, the answer is most likely yes. However, in the longer term, the answer to that question is no. Why? Because unlike manufacturing the high-tech industry can only move to countries with a sufficiently large base of highly educated people. Competition for those people is increasing already in places like Bangalore and it’s going to increase everywhere else through the simple laws of supply and demand, and demand is inflated because so many high-tech companies are inefficient and use unsustainable practices.

The problem is it’s much easier in a large company to squeeze budgets to force outsourcing than it is to implement lasting process change. The loss of efficiency is going to hurt most on the front lines, and I believe that the companies that figure out how to work more efficiently and sustainably while doing distributed development are going to win in the long run. That’s where I see agile development fitting in, though admittedly not in the same form that it was first introduced, primarily for small co-located teams. I’ll save those thoughts for future posts because there are many angles.

Finally, these are the reasons why I think development in low-cost locations is here to stay:

  • Demographics and graduation rates. The developing world has a higher birth rate, more young people, and a higher enrollment and graduation rate from universities in high-tech related fields. And the quality of education is improving in many countries such as India, China, Singapore, Vietnam, Malaysia, Indonesia, the Phillipines, and Brazil.
  • Costs are dramatically lower. Not only are salaries lower, but many countries offer huge incentives to high-tech companies to hire local workers and make a long-term commitment. For example, there is one Asian country which I can’t name that will pay all startup expenses, provide free land and buildings, and tax incentives for five years if the company agrees to sign a ten year agreement. That’s impossible to compete with.
  • We can’t pretend that it’s just developing countries that want to diversify their economies. Many jurisdictions in developed countries are also offering incentives to high-tech companies. Quebec, South Carolina, parts of Germany, and Louisana are a few locations that I’m aware of that give free land, buildings, tax breaks, etc. in an effort to attract and keep high-tech industries. Frankly, it’s a good move because the same pressure to outsource doesn’t exist there as it does say in New York or California.

What does all this mean? The pressure to move jobs around the world is going to increase. Industry-distorting subsidies are going to increasingly be used as a blunt instrument to attract companies, and I don’t see any trade agreements coming soon. Agreeing on climate change should be easier, but we can’t get a global consensus on that! What we need to do now however is move on from blind cost-cutting to focusing on efficiency, sustainability, and long-term competitive advantage. It’s time to do the hard work.

Specifications: be careful!

January 16th, 2010
Stack of documents One of the things that teams who try agile struggle with is what to do about specifications, from UI designs to feature specs to test plans to software designs. Some agile books leave you with the impression you should avoid written documentation entirely, and it’s true that many teams who practice agile avoid any kind of documentation like the plague. And on the other extreme there are teams who don’t succeed with agile because they burden themselves with too much documentation: they fail to deliver. Most teams are somewhere in between the extremes, but just about everyone asks what to do?

I believe that what matters the most is your mind-set. Here are a few critical elements of the mind-set:

  1. Think minimal documentation, not no documentation. In lean development, any activity that isn’t an end deliverable is a potential waste of effort. One of the reasons many people advocate index cards for project planning for example is that the size is limited. Having a limited space forces us to be concise and to focus on what is most important. I’ve seen many teams move to some form of software for planning and this leads to longer specifications, which unfortunately means they’ve lost a key benefit of agile development!
  2. Remember that the effort that goes into the documentation is always more important than the document itself. I.e. the collaboration through discussions and alignment is where the value is, not in the document. Put hours into discussing a design, not documenting it. I’d rather have 6 hours of discussion in front of a white board over a class diagram and a picture of the white board posted on a wiki page versus 6 hours spent by someone writing a document in some prescribed format any day. The goals of doing a design are good design and alignment that the approach is right.
  3. Always remember that in software development the best way to get feedback from users is through working software, not documentation. Getting users to sign in blood that a spec will meet their needs is going to lead to trouble more often than not.
  4. Remember Alistair Cockburn’s Crystal methods: scale your documentation requirements to the circumstances. The larger your team is and the more distributed it is the more formal you should be about documentation. Too often, small teams will put too much effort into documentation and large teams too little. Small, co-located teams can just turn around and talk. With large teams there needs to be more electronic communication.
  5. Always, always, always look for improvements to your process. Do regular retrospectives as frequently as possible. In my experience, no matter how well things are going there is always room for improvement. Embrace continual change and improvement because when it comes to documentation this is the only way to deal with the question that everyone asks: “how much documentation is enough?”.

Finally, a few quick thoughts on the main sources of documentation: feature specifications (sometimes called feature briefs), UI designs, feature specs, test plans, and software designs.

Feature Specifications

Our natural tendency when negotiating with customers, end users, or end user representatives is to get a complete list of all their requirements, write a specification usually with some design in it, and look for sign-off. This approach might work fine if you’re specifying a building or a renovation project but most software projects are too open-ended with a huge variation in implementation and delivery options. Users will sign a document and more often than not when they get the software say “that isn’t what I needed!”.

Never ask for a complete list of requirements.  Instead, find ways to tease out the core requirements.  For example, google for “Design the box” and “elevator test”. 

If you can get a user to describe what they want in the time it would take to ride an elevator 5 floors you could just have your feature spec.  Great!  Move on and focus on the software as fast as you can and be prepared to iterate outside the core requirements. Agile methods are designed for iteration, transparency, and negotiation. Build an environment where you can trust the development team and the end users to work together and ensure projects are considered done as soon as possible.

Software Design

See point #2 above. Focus on a good design and agreement on the design, not on the document. Talk about design as frequently as you can. Keep a white board reserved for the latest design of your product, ideally if it’s in a place that everyone walks past every day.

UI Design

UI designs are great and very valuable if they’re done right. UI mockups that show a rough form of the UI and markup to show workflows or even a PowerPoint with simple animations can be tested with users and co-workers before any software is written. It’s almost always cheaper to iterate on a UI prototype than it is on UI coded in software. And don’t be afraid to steal good ideas from other applications!

A fun and simple package that we use at work is “Balsamiq Mockups” for UI designs.

A word of caution though: don’t get carried away on the designs. As with feature specs, try to spend the majority of your time on identifying and refining the core workflows. Do the rest in code and try to get to code as fast as you can since that’s where you’ll get the only feedback that counts.

Test Plans

You should always emphasize automated testing over manual testing. Specifying tests for completion for core workflows is fine, especially if it’s done in a brief form such as on the back of an index card. In my experience, if you require enough manual testing that you have to write test plans you’re doing something wrong. Usually, your software isn’t architected for testability. Put more effort into fixing that than into the test plans!

It’s Code-AND-Fix!

December 13th, 2009

The error in the first print run of my book that I most wish I’d caught in proofreading is at the start of the chapter on Defect Prevention.  In the opening paragraph I describe how a culture of defect detection is one of coding then bugfixing; i.e. code-then-fix, or “let’s add all the features first, then spend a few weeks fixing all the bugs”.  A culture of defect prevention on the other hand is one where feature development and bugfixing happen every day; i.e. “every day, let’s check in an incremental addition to a feature and fix the bugs that come up that day”.  This is a “code-AND-fix” culture, yet in the first print run the text says code-then-fix.  Oops.

There are other errors in the first print run (check out the Publications page for a list) but this one caused me the most stress.  I’ll never forget the feeling of opening the box of books from the publisher, pulling out a copy and skimming it only to find this.  Let’s just say it did not make my day.

So the big question is, why is this important?  Because teams that focus on features first (i.e. a culture of defect detection) have a false sense of progress.  Their project might be tracking to schedule, but nine times out of ten their product isn’t because once they try and release the usual outcome is stress as they fix bugs and try to stabilize the product again.  I’ve seen projects where a number of those fancy new features have to be disabled just to get the product out the door, and heroism and stress are required in equal measure.  The feeling the team has when the product finally ships is a sense of relief, which is a shame since a lot of hard work went into the product. 

The advantage of a culture of defect prevention, where the team focuses on quality first and features second, is that products are shipped with a sense of pride and with less stress and no heroism required.  True, there are always things to improve in every release, but these teams are able to make each release better than the one before it, and that gets the attention of customers.

If there’s one observation I have in my career to date it’s that focusing on quality first is critical.  Quality enables innovation and business success, which are critical for long-term success.