When not to use Agile

When building products with teams of people over the course of months, I think the Agile project management approach works best.  I have my own customized Agile approach I like to use that I'll likely describe in a future post.  But first, this posting describes when not to use Agile.

I've been noticing an increase in the number of extremely short, tactical coding exercises to deliver urgently needed functionality within hours or days.  More and more, I see people doing things like: throwing together a web site, building a prototype, creating a custom ETL solution, creating a new kind of widget, fending off a hacker attack, or creating a new report.  Sometimes the code may only be used once, or it might be used for years.  Often times these coding exercises must be delivered as quickly as possible, and with no advance notice.

I've found the best way to deal with these situations is to immediately create a team composed of the people that need to work together to deliver this.  Have them meet and figure out who's going to do what and when, and then they go off and do it.  No sprint meetings, no burn down charts, no stand up meetings - the team just gets the job done.

The challenge here is that the set of people that are working on these types of urgent tasks may largely overlap with the set of  people working as part of an Agile team, and they will most likely be in the middle of developing work that they've committed to delivering by the end of the sprint.

I think there are a few solutions to this problem, each with pros and cons.

First, you can reserve a certain total percentage of your Agile team's velocity for urgent tasks - say 20%.  This basically comes off the top of the total team velocity that you start with at the beginning of a sprint planning session.  At the same time, you identify a few stretch tasks in the sprint - bonus features that are either in the next sprint or that would be really nice to have.  If you don't use up your 20% reserve, you can tackle some of these bonus features.  The down side of this approach is the extra cost for context-switching mid-sprint; it takes extra time to switch between a person's sprint tasks and their 20% urgent task.

Second, you can just make sure that these two sets of people don't overlap - reserve different people for the short, tactical projects and manage that pool of people differently (but also probably not Agile).  You can periodically swap people between these two sets for cross training purposes.  The down side is that this probably requires more total people, so it's much more expensive.

Sustainable Software Engineering

Something bad happens to many software development teams somewhere around the 4th or 5th year of life of their code base: Quality and productivity take a nose dive, following an ever increasing trend of problems.  I call this the "Developer Duldrums" (with apologies to Norton Juster) because it's a sad place to work.  It's insidious because the team is usually building software the same way it always has, yet they've lost their mojo.  Why?  The answer is that the code base can no longer sustain development.  Enter sustainable software engineering practices.

Sustainable software engineering consists of:

1. Automated functional testing.  I like to bias most of my QA team to writing automated functional tests.
2. True unit tests (not functional tests masquerading as unit tests)
3. Keeping your code bug free right from the beginning
4. Relentless refactoring
5. A solid and always-evolving architecture that is well internalized by the team
6. Properly componentizing (with tests on the interfaces) and isolation of subsystems in your architecture so that you can re-write sub-components when needed without touching other parts of your code base
7. Little overtime

Sustainable software engineering is usually not practiced because there is a cost associated with it, a cost which has a return that may be a year or more down the road.  However, if you haven't paid your dues and you get yourself a few years down the road, the chickens will come home to roost.  At that point, you're looking at rewriting your software - that's something you want to avoid because of the large cost and risks involved.


Counterpoint: In my experience, I've observed that technology trends move fast enough that approximately every five years, there may well be sufficient benefit to re-architect your code on top of newer technologies to justify a return on the investment required to do so.


So it may happen by luck that the Developer Duldrums curve may drop off close to the time you'd want to rewrite your product anyway because of advances in technology, so sometimes that's your way out of the Duldrums.  You kill two birds with one stone.  However, I wouldn't want to rely on such a coincidence happening.


Shorter projects benefit less from sustainable engineering, simply because you don't make your return on the investment because you don't have software you need to sustain.  So the amount of sustainable engineering you practice should be proportional to the project length or expected life time of the code base.


Sustainable software engineering isn't always possible to practice.  I would guess that there is approximately a 25% cost overhead for doing so.  This is due to the time it takes to write quality unit tests, refactor your code, and fix the important bugs as they occur.  (Counterpoint: The use of automated unit test generator tools such as Agitator from the beginning of the product development life cycle may reduce this tax.)  Often times, your primary objective is to reach your customers as quickly as possible to validate your market and product.  To do so, you could get to market faster by skimping on the sustainable engineering stuff.  That's certainly a valid argument.  But if you go down that route, you should be prepared for the chickens to come home to roost at some point.

Since I wrote this blog posting, I discovered the book Sustainable Software Development, by Kevin Tate.  I asked Kevin what he thought of my blog posting.  In his reply, which you can read below, he mentions something really interesting about proper componentization (which resulted in my point #6 above - thanks Kevin!):

I like the post and agree with the main points.  One thought is that you mention a 25% overhead, but in my experience people need to recognize that you typically get that 25% back (and more) through the knock-on effects of, for example, having reduced QA / manual testing and decreased effort behind release cycles.  

Another thought I had is that you touched on the need to periodically rewrite based on the latest technology.  That's where you might want to add one other "critical element" to your list: the need to componentize (with tests on the interfaces).  I talk about it indirectly in my book, but since I've written the book it's become increasingly obvious to me that this is another element of "secret sauce" because it allows teams to selectively rewrite their product as they go without having to throw out the entire system.  The rewrite from scratch scenario doesn't succeed very often, if indeed you even get the business support to do it!

Building high quality software fast and cheap

James Currier at Ooga Labs posted a blog entry that starts as follows:

"I’ve heard people tell me “We can build product fast, good, or cheap.  You can’t have all three.  Pick two.”  I believe this is a corrosive mindset, used by bureaucrats to justify mediocrity, or used by people who are afraid of failure to set the bar low enough so they feel comfortable in their daily lives."

I disagree with James and think you can only lock down two on a large, complex software development project.  While it's possible to build good software fast and cheap, I think that happens only under certain circumstances where the engineering risk is inherently low.  Also, sometimes you get lucky and nail it - I've seen that happens a few times. Projects having any of these characteristics generally can be delivered fast, good, and cheap:

1.  Young code base (generally a few months of development or less)

2.  Small team size (generally 1 or 2 senior developers, sometimes up to 3 or 4 if things are going well)

3.  Relatively simple feature set

As you get to bigger teams with more complex software that takes longer to create, your risk goes up.

The underlying principle at work here is "shit happens" - sometimes an engineer quits or gets sick, or you discover a fatal flaw in a library you're relying on and you need to retool, or you discover that a feature doesn't work as designed and you need to redesign it, or the market changes and you have to react.  When such a thing happens, the bottom line is that it's usually going to take you more time to do what you wanted to do.

So let's say such a thing happens AND you hold all three values fixed.  You can deal with such unexpected events by building in a "slop factor" to your schedule, so you eat into your slop time.  But essentially what a slop factor does is pull in the release date by saying "we expect this much shit could happen".  So you really are slipping in a way so the "fast" part is actually varying.  Or you could ask your team for overtime - that's one option.  But that's really tweaking the "cheap" part because you are putting more time in - if you paid for that hourly, your cheap just went up.  You could shave your feature set and simplify things and still ship, but then you're tweaking the "good" part.

Sometimes bigger shit happens than you budgeted for with your slop factor- we all get constipated from time to time - and if that happens, then what?  It's naive to believe that big shit won't ever happen.  Then what, if you hold all three fixed?

I call these three values by different names that more closely connote the values being managed:

1.  Release date
2.  Features & Quality
3.  Resources (people and hardware/software)

My basic form of project risk management is to look at these three values as dials that you can twiddle or tweak at the beginning of each sprint.  So I've folded this form of risk management into the way I practice Agile project management, by constantly reassessing the feature set, team velocity and composition, how the product is shaping up, and the importance of the release date relative to other business priorities, which may be more fluid than we'd like.

Why perform technical due diligence prior to an acquisition?

Michael Sisco put it well I think: "Conducting thorough [technical] due diligence can make the difference between a successful merger and a company's collapse."


If you're a high tech company looking to acquire another high tech company, please perform technical due diligence as part of negotiating the deal, ideally prior to signing a term sheet.  Here's what could happen if you don't.

First, you won't understand the costs, timeline, and resources required for delivering the promised integration of the newly acquired company.


Second, you won't have a good understanding of who to keep and who (if anyone) to let go as part of a Reduction In Force (RIF).  You won't be able to develop a new organizational structure because you haven't worked out what you're going to do and in what order.


Third, there is some value in the technology of the acquired company.  The value is significantly correlated with the quality of the code and architecture, and whether you have to rewrite the product code or not.  This should figure into the overall acquisition cost negotiation.


Fourth, you won't be able to optimize your own product development schedules to account for the possibility of the coming acquisition.  It's often possible to re-order development tasks to intelligently account for the possibility of the coming acquisition, without incurring cost if the acquisition falls apart.  Or you might pause or slow-roll hiring certain roles until you know how things are going to shake out.


There is always time to perform technical due diligence.  More information is always helpful.  For smaller companies, you can usually do the whole thing in a week.  Get the book Technology Due Diligence if you don't know how and want to do it yourself.  If you don't have the time or skills to do it yourself, you can hire a firm like blackduck to do the technical due diligence for you.


Since I manage the Chief Technology Officer Exchange over on LinkedIn, I asked some CTOs what they thought of the practice of investing in or acquiring other companies without performing technical due diligence.  Here is one response I find particularly interesting from a CEO in the group:

This kind of acquisition is a lot more common than it used to be. I'm seeing a growing number of companies decide they don't have to worry too much about moving software forward from its current state. That leads them to conclude they can do all sorts of things that seem like bad practices. Acquiring without diligence is one. Not taking care of the developer team is another. 

I haven't seen much evidence that these formulas are successful, it's just that I'm seeing companies try them more often. 

Another surprising one is for VC's to invest without proper technical diligence. This happens pretty often and has been going on a long time. They get stung by it periodically.

In general, most non-developer types have no real idea how to manage, value, or evaluate IP assets.

Multiroling

I'd like to introduce a new term into our team culture / process lexicon: multiroling.

Multiroling.  Noun.  The carrying out of two or more roles at a time.


When assembling a team, you first have to think about the roles you want on the team, and then you go about assigning people to those roles.  You ignore formal HR role names when doing this - you pick the best people for the job.  When a person is assigned to a particular role, they act in the capacity of that role rather than in their formal Human Resources Management Title.  So when I, for example, act in the capacity of product manager, then I do not exercise any authority that my official HR title would give me.

Multiroling is one of the key techniques I use when building a team.  The problem is that you usually don't have an instant, fully functional team.  You build it up over time, usually a few months.  During that time, you don't have all the skill sets needed, but you still want the team to build stuff.  So you create place holder positions for people you haven't hired yet, and you multirole other people into those empty positions until you fill them.  As the team grows, members may shed roles, to be assumed by new team members.  This creates the proper culture and process for the team so that you can grow quickly.

In larger organizations, if a person assumes multiple roles, they may need to engage in matrix management (also known as "dotted line" management) while assuming roles that cross managerial boundaries.  In addition, you may need to become fluent with multiple cultures.

During the course of a typical day, I assume different roles from hour to hour, depending on the type of meeting I'm in or what team I'm interacting with.  Here is the actual current set of roles I'm multiroling:

1. Interim-vice president of Engineering / Executive team member
2. Director of Engineering
3. Product Manager
4. Architect
5. Project Manager
6. Senior Salesman

In order to pull this off successfully, I've found that it works best to be clear about what role I'm assuming before starting a meeting or discussion or email.  I might even start a conversation with something like, "In the role of Architect, I'd say that..."

This is one of the dynamics that makes start-up companies so explosively successful - they are able to multirole.  What happens as an organization increases in size, though, is that people tend to be pigeonholed into one role only.  Some people really like multiroling, so if a company loses its multiruling culture as it grows, then those people move on.

The primary challenges with multiroling are two: First, you simply may not have enough time to do the new role justice - something has to give somewhere.  Second, you may not be well trained in your new role (although maybe you're the best your team has got).  You need to assess whether your skill level is high enough to do the job justice.  It doesn't make sense to take on a multirole you can't really fulfill in any meaningful way.

Perhaps this points to a short coming of our traditional HR organizational structure.  Perhaps we ought to adopt a more flexible HR title that reflects the multiple roles that people assume over time.  Oye, we'd have to print so many business cards as we added and dropped roles over time!  So that's why my current business card actually has the role name "Omelette chef" on it.  Really it does!

Team building

I've found that most large business goals are unique, and require assembling the appropriate resources to achieve. These resources start with people, and also include the equipment and other assets needed to achieve the objective.

With respect to organizing people, you look at the people you've already got on board in terms of existing employees and consultants, and you also look at new employees or consultants or outsourcing in various ways. The choice of which type of human resource to use often depends on the amount of time they'll be needed, how specialized, rare, or expensive their skills are, and whether the knowledge built during the process of doing the work is something that would add value to an existing strategic knowledge base or cultural asset.

In many cases, you must recruit existing employees or consultants that are already busy doing something, so getting them to take on these new tasks requires an understanding of how work is requested, specified, assigned, performed, tracked, and valued within an organization. This requires an understanding of both the processes (e.g. feature requests, hiring processes, purchase orders, help desk requests, budgets, etc.) and culture of how to get things done. It also requires an understanding of what motivates each and every one of the individuals involved, because those motivations need to be aligned as much as possible with an emerging commonly felt group motivation for getting whatever it is achieved.

Every team has a life span. Sometimes that lifespan is very short - a few hours - and some times it's years. Or anything in between. Sometimes the teams grow and shrink over time as new needs evolve.  It's important to know when to grow and when to shrink a team.

It would be a mistake to view a team as the sum of its members.  In the best teams, something magical happens when the team is working together well - a team spirit emerges that is palpable - you feel it on the team.  It's what makes working on one team feel really different from working on another team.  The members feel everything is clicking, they're in the groove.  And the whole company knows it.  They are able to deliver best in class, innovative software that solves some of the toughest engineering challenges around.

On such teams, they are self-organizing.  Team members instinctively know when and how to work with other team members efficiently.  Leaders naturally emerge when needed to solve problems with the support of others.  Overtime is rarely needed.  Deadlines are usually met, or if not, for good business reasons that have appropriate management / executive support.

Software engineering is different from other kinds of engineering

When a company's primary product is not software, but rather contains software as a sub-component of something larger such as a piece of hardware, I have found that the management, processes, and culture of such companies generally do not support innovative, high quality software development.  Some online internet services are similar, even though they are entirely enabled by software - since they aren't selling software, but rather a service, the support for innovation can be weak weak.

What happens at first, in such cultures, is that the software developers are left alone to figure out how to make things work, and they pull it off.  So management assumes that its approach in terms of management, processes, and culture must be working.  However, what inevitably happens is that things gradually, eventually start to fall apart in terms of productivity and quality.  At this point management often thrashes about trying various solutions to the problem that may be partly effective or not, not realizing that *it* in fact is the problem and that management is what needs to change.  Management's hubris in such a company can often get in their way of seeing themselves as the root cause.  This can create a morale problem for the software developers working in such an environment.

Management might try to bring in "process" in some form - importing processes from other organizations in the form of specification processes, project management tools, version control and configuration management systems, testing tools and procedures, and so on.  This can be helpful in some ways but isn't a silver bullet.

Management might try to bring in "culture" in some form - "Everyone show up at 8:00 am from now on and no more telecommuting even when you're working overtime," for example.  Yeah, that's going to go over well with software developers.  Not.

Management might try to bring in new management - a manager that supports upper management's values.  However, if management fundamentally does not understand or value software development, then it will bring in a manager with that philosophy and the result is that the manager will be a proxy for the culture and processes that management wants to inflict on its software engineers - "We just need someone to make them follow the process."  Yeah, developers will like that.  Not.

Managing a high quality team of productive software engineers is so fundamentally different from managing other kinds of engineers, it can lead to upper management's mistaken assumption that they can apply other engineering management practices and experience that, in the end, is not effective.