Marcato

There is an old poem based on an even older Indian fable about six blind men that happen upon an elephant – as each of them touch the elephant they each reach a different conclusion of what the elephant must be like, with the composite looking something like this:

Elephant

A couple of days ago I opted to join the local OTUG (Object Technology User Group) meeting – I had been receiving occassional invites for a while and since it was associated with another group called the Agile Experience Group, I decided to give it a try.

Frankly, it was like getting dropped from the sky onto a foreign planet where the language and ideas were so strange as to be nearly incomprehensible.  If I hadn’t already heard some of this bizarre new dialect at the dinner table talking to my 16-year old, I would have been at a complete loss.  Soon my babelfish started to work better and I actually started to follow the discussion, but I really perked up when I started hearing the word “agile” over and over again.

“Ahhhh – finally something I understand – I bet I can contribute to this part of the conversation”, I thought.  And yet, here we were still espousing the relative vices and virtues of a variety of functional programming languages such as Haskell, Scala, F#, Clojure, and Groovy.  So I started concentrating really hard to see if I could find something of significance to Agile in this sea of jargon when I had one of those moments where your camera spins around and all of the sudden you see things from somebody else’s perspective. 

We WERE talking about Agile, but from the perspective of someone whose interests lie not in the team behaviors and organizational dynamics that lead to building great software, but rather someone who is driven to understand how the nature of their programming language and architecture enables easy understanding and rapid refactoring.  Given that change in the code is a constant, how does the design of the language lend itself to readability?  How can their IDE make it easier to find what needs to change and to change it?  Do language idioms bring forward the essence of what the code is trying to accomplish or mask important details that are essential to understanding its performance or consumption of resources.

Coon Rapids Dam - Coon Rapids, MN

They were talking about Agile, and now that this blind man has touched a leg instead of just the ears, I’m compelled to learn more.  We were given the strong recommendation to read “The Little Schemer” by Daniel Friedman as a primer to functional programming, but I suspect I will already find it unsatisfying.  My challenge is that I can follow the almost trivial examples of how to build interesting and cute functions for operating on things like lists of strings.  I’ll grant you they are cute, especially in their rampant use of recursion, but I get lost in trying to expand what I can understand in the small and extend it to a large, complex system. 

I did get a little help here, as one of the other guys there observed that the nature of building stateless, functional implementations lends themselves naturally to massively parallel architectures.  This I understand, but still more in the context of calculating PI to 10 billion decimal places rather than building a multi-tier web application.  My kingdom for someone that can help me bridge that conceptual gap.

But, back to the theme of this post – my next trip will be to a scrum special interest group.  There I expect to find a group of more like minded individuals to me that see Agile from the perspective of the project manager.  But better yet, what if Agile can become more than a common vocabulary of words used by different groups with different goals to peacefully share the same space and instead actually lead to common understanding and interest between these different groups.  Or maybe that’s asking for too much, and its good enough to have a common rally cry that at least points all these groups in a common direction – building software and teams that can more rapidly respond to the changing needs of their customers.

One of the hardest adjustments to make when adopting Agile is to get used to the idea of using a unitless measure like “story points” to do estimation. I think that most engineers get used to the idea eventually, especially as they grasp how it functions in combination with measuring velocity and using that to estimate future capacity of the teams. It’s a simple feedback system, and as long as the estimator itself is stable, it really doesn’t matter in the long run if it is accurate in estimating effort.

Even after you get used to this idea, you will find an ongoing concern expressed by the feature teams that the estimation process is flawed. Now, I have to admit that early on my reaction was that this was just natural – we all know that software work always expands to fill the container in which it is placed, and it takes a while for each feature team to learn this and for the velocity estimates to correct to the point that the team does not enter each iteration over committed. I also noticed that there was a tendency for feature team leads to let the product owner buy more than their original estimate, usually because there is a pet story that they really want to squeeze in so the decide to go for it even though the numbers don’t substantiate it. However, even as I used time and coaching to try to bring both of these aspects of the process under control, the frustration still remained as a consistent theme in ongoing retrospectives.

My next thought was to address this by getting more people involved in the estimation – my assumption was that participation would help to neutralize the concern; if they saw the process in action and participated in the estimating, then they would come to appreciate why and how it works. So I opened up the invitation to the entire extended team, adjusted the time schedule for the meeting so that all participants around the world could join, and rejoiced over what a smart manager I was. We had one or two new participants for one meeting and then it quickly relaxed to the same participants as before and the same grumbles re-emerged.

At this point, I was running short of ideas and getting frustrated with the situation, so what did I do? What any manager would do – delegate the problem! I know that sounds like passing the buck, but I can also rationalize it by saying that I needed both new ideas and a shift in responsibility for resolving the problem to those that worked hands on with the teams – the feature team leads.

As the leads started to tackle this problem, one thing quickly became clear – the individuals doing the work wanted more influence over what they were committed to accomplish in the iteration, but I would not budge on the approach or need for the high-level estimation process. The natural inclination was to try to force these commitment processes together, but the reality is that they serve two very different purposes. Story estimation in the product backlog combined with the buying meeting are needed to allow for macro level management of the release cycle and for gating the flow of the quantity of work allowed into the development engine. To plan the work at more detail meant creating a significant distraction for the developers and testers in the team, a process which starts the slippery slide back into waterfall. We needed to keep our high level, less accurate estimation process in place, but we needed to add an inner ring of commitment that would occur within the confines of the feature team itself.

Dirty Sweet at Lollapalooza - Chicago, IL

One of our feature team leads (Jeff Whiteside) really took this to heart.  Jeff wanted to figure out how to overcome this barrier by focusing on the iteration kickoff and planning process and figuring out how to best build shared responsibility within the team that ALL of the stories that were purchased could be finished and if not, then we would invent a new way to unallot them from the team. I’ve asked him to relate the specifics for how he has accomplished this in his own words and will post the details here in a separate article, but let me take a moment to relate the results I witnessed.

Jeff decided to formalize the kickoff as his means for transferring ownership of the deliverables and for planning the scope of the iteration.  He realized that these were two sides of the same coin – if he didn’t force the team to take some time up front to consider all of the stories in the iteration then the natural behavior was everyone to just grab one and go.  Now they break these stories down into tasks and estimate the tasks in hours.  If the rolled up detail estimates across all of the stories exceed the available hours of his team, then we know we have a disconnect and revisit the story list. 

 These task level estimates become the element that is tracked for burndown during the iteration – story points tend to be too coarse for doing day to day project management, and this gives Jeff (who is remote from the rest of the team that he is leading) better visibility to what is happening day by day.  What I have observed as the result is that the pressure felt by the team to deliver when they feel they were over-committed has been resolved (as have the complaints) and planning in BOTH layers of the organization (macro planning for releases done by the director and product owner and iteration planning done by the feature teams) are working smoothly.

Props to Alan Atlas for an amusing and meaningful metaphor comparing waterfall and iterative development:

http://www.rallydev.com/agileblog/2009/09/the-opposite-of-waterfall-is-pond-a-metaphor-for-agile/

You do have to be careful to avoid typos when inviting someone to your Pond Scrum

I was first asked to tackle offshore development roughly six years ago while still a relatively new director for development organization at HighJump.  This was our first experience with distributed development, and like most organizations in the same situation, we approached it timidly and with a fair amount of skepticism.  We were concerned about what this meant to how we organize, how we manage delivery schedules, and what we would see for work quality.  We chose to partner with an existing business representative in Chile; this team had shown the ability to use our tools to customize our reference application, so we knew that they could do the technical work, but they had no experience with the processes and tools needed to make offshore successful.  The impetus for this investment was led by our board and our CEO, so knowing that resistance was futile, we rolled up our sleeves and started.

Fast forward to today; we’ve had a great strategic partnership for the last couple of years with an outsourcing firm based in Minsk, Belarus and we are in the process of transitioning from working with them to an even larger team that is part of our new merged company based in Bangalore, India.  Now confident in our use of Agile, this methodology has proven excellent at managing the pace and communication needs when interacting with distributed teams.  We’ve also figured out the structure, roles, and skillsets needed to make it work and we now have roughly two-thirds of our head count offshore.  This article will focus on explaining the possible structures, those that we tried along the way, and finally the structure that has proven most productive for us.

We have over the years done a lot of experimenting with different organizational patterns.  One possibility is to outsource a “function” such as product management, coding, project management, manual testing, architecture, or automated testing.  I’ve seen organizations conclude that certain functions are less strategic to their organization, so they choose that function for outsourcing.  Management literature recognizes this approach as a sound strategy, but to choose which functions are less strategic, you need to make certain value judgments about the work that these functions perform.

A common conclusion reached is that code development is the most important function.  People reach this result through a flawed process of elimination;  without developers, there is no need for testers, architects, or project managers.  Ergo, coding is the most important, highest value add activity, right?  Of course, I might make the argument that without a product manager, the developers have no idea what to build, but it’s usually the business owner having these thoughts and she of course has no shortage of ideas, so it makes perfect sense to just hire some developers and go.

Nothing can be further from the truth, but this is the mentality that causes people to devalue the other functions.  Once devalued, then the natural next step is to conclude that since I have to spend some money on these other activities, I may as well try to get them as cheap as possible.  The conclusion?  Development is a strategic core compentency.  Outsource your testing.

Taughannock State Park - Ithaca, NY

I’ve avoided this option for a couple of reasons – first, it doesn’t scale very well.  If you decide to only outsource testing, then you are inherently limited to only saving money on that portion of your R&D spend.  If we assume a typical 3:1 to 5:1 developer to tester ratio, then obviously this strategy can leave you with no lower cost option for 75-90% of your resources.  My second reason relates to the process and organization – I am firmly opposed to separating the test resources from the developers in the feature time.  I use testers as an “in line” participant that works side by side with the developers to design and test the solution.  The natural barriers to accomplishing this kind of cooperation are only reinforced if there is a geographic boundary separating the teams.  Since the testers need to belong to the team and sit right next to their lead and fellow developers, this has never been an attractive option.

Another option is to choose your outsourcing by product line (which often maps to one or more codebases that support that product line).  For example, you may have a new development effort to build your next product or technology platform and conclude that it is best to keep this work local.  A common decision is to outsource the ongoing feature development or defect fixing of an existing legacy product so that the attention and energy of the local team can be focused on more strategic work.  I have used this approach in situation such as device development where is has been impractical to have the developers and testers offshore as the device is best tested on network during normal use.

From here there are numerous details to consider – can requirements, development, and testing be done by remote teams?  How will final product acceptance be done?  How will I divide the resources?  Have some teams local and others remote, or have all teams have some functions local and others remote?

These decisions form a crossroads for your engineering organization.  I’ve seen a lot of energy go into rationalizing and justifying one plan over another, and it is certainly true that any decision made here is subject to strong political influence.  Rightly so, as quite literally the future of some people’s jobs lies in the balance, either because the job may be eliminated or the responsibilities change to the point that they may not choose to stay.  Either way this is an emotionally charged topic and it is not to be taken lightly – I’ll devote a future topic just to staging and managing the transition to distributed teams, but in order to keep this topic on track, let’s focus the discussion back on the desired end state.

In the simplest and coldest of terms, every organization is looking to minimize the cost associated with product development and maintenance.  There are certainly situations in which the product strategy of the company helps to justify the decision to work only with a local and more expensive team, but while most companies start with this in mind as they race to get their initial product to market, few companies choose to pursue this strategy in the long run. 

I’m reminded of a great article on this topic that is actually published as part of the literature on supply chain management entitled “The Triple-A Supply Chain” by Hau Lee - you can read it for yourself at http://images.ed4.net/images/htdocs/hbsp/050117/AAA_SupplyChain.pdf.  If your organization is a “job shop” that is frequently switched to new and unfamiliar products or codebases and you need to rapidly reconfigure the teams to match rising and falling workloads, then “agility” is truly at a premium and you may need to use local resources indefinitely.  However, if you are working on established products with deep product roadmaps, then stability and consistency in the team brings effectiveness, so you may as well also configure the geography of the teams to maximize efficiency (through lower cost) as well.

The net result is that I propose a hollow local organization comprised only of the following roles:

• Senior Product Owner – the product manager that is responsible for the product or product lines; this person works with the director to negotiate release schedules and scope and writes the high-level stories (often epics) that drive the release content
• Director – this person is responsible for the setting the overall rhythm and sustaining the process; this person schedules and moderates the iteration reviews, estimation meetings, and scrum of scrums and works with the product owner(s) to determine the release rhythm, set release scope and schedule, and to make sure there is always sufficient product backlog ready for each iteration.
• Feature team lead aka scrummaster – this person is responsible for the work product and for all communication with the remote feature team.  This is usually a senior developer that has also made the transition to a leadership role; the drive the architecture and design, review code, and manage the flow of stories into the team throughout the iteration.  This person is responsible for coordinating all team functions including kickoffs, daily scrums, and retrospectives although they may offload some or all of this responsibility to the remote team lead.
• Customer response team lead – this person is responsible for triage and resolution for all immediate reaction and customer driven work that can not be handled by the normal release rhythm.  They may also provide the configuration management function for the team as they sit at the nexus of multiple code branches and are responsible for back- and forward-port activity needed to keep these branches functionally complete.  See http://craigkn.wordpress.com/2009/09/12/customer-response-team/ for more details.

That’s about it.  Everything else, including the stabilization lead, is a candidate for outsourcing.  In fact, let’s dwell for a moment on one role that may be a surprise to you – technical product manager.  First, to clarify – this role is responsible for converting epics determined by the senior product owner into digestible stories that are granular enough to fit within the iteration interval.  This person needs a detailed understanding of the existing product and will produce detailed user interface designs and requirements based on the overall direction of the senior product owner.  They need to understand the users of the system, but they do NOT need to understand overall market direction or demand.

Taughannock Falls - Ithaca, NY

When we first formed this team structure at Gearworks, the most common complain during our retrospectives was that the developers did not have enough access to the product owner.  We could have opted to try to convince marketing to spend more money to hire another local product manager, but instead we opted to use development funds to bring on staff a technical product owner on site with the remote team.  The difference was phenomenal – not only did we start receiving much better defined stories, but the remote teams had access to a decision maker that also understood the details of the requirements they had defined.  The product owners scrummed daily to review progress on definition of detailed stories and to answer any questions that had been escalated over night by the remote team, but over time the remote product owner became confident enough that she could handle these questions without help and just get her decisions confirmed by the senior product owner later.

Now let’s take a look at this from the point of view of your board or CEO.  Assuming that your organization scales somewhere from 15 to 100 FTEs, you are going to see the following distribution of headcount between local and remote resources:

As you can see most of the real coverage comes from scaling the team above 10 people; I have a hard time recommending the use of offshore for product organizations with less than 15 people as you are not getting a lot of leverage from the onshore staff.  I’ve found that offshore efficiencies of at least 2.5 are very reasonable to expect, and in some geographies you can do even better than that.  Using even 2 as a very conservative estimate of the cost multiplier you will experience for remote staff, let’s look at the two extremes and summarize the leverage both as a potential cost savings or as increased head count for the same cost.  In the case of an original local team of 10 people, you can either reduce your costs by 30% or keep your spending the same and increase your headcount to 16 people.  At the other extreme, if you are starting with a local team of 90 as your “before” state, then you can either reduce your cost by 40% or increase your headcount to 160 people!  Of course, you are most likely going to choose some compromise between cost savings and increased headcount, but either way the business case is compelling.

I am assuming the use of an outside contractor organization providing the resources – part of the efficiency comes from the fact that they are responsible for all aspects of compensation, performance, and benefits.  As a result, your much leaner local organization is focused almost exclusively on determining what will be built and architecting, accepting, distributing, and supporting the final work product.  One final note – the team that is “local” only needs to be local from the point of view of the customer base that is served.  If your product is going to be sold into a different market, then it may make sense to put the entire development organization into that geography.

I was asked at breakfast this morning how I would handle a situation where resources were not committed to my feature teams because they have ongoing responsibilities for supporting and maintaining other products.  My answer?  I would probably choose not to play.  Simply put, if there is ANY prerequisite to establishing rhythm in the market driven, planned release arena, it is to start by isolating those resources from the other less predictable (and likewise more difficult to control) sources of interruption.  The good news is that once this is done and once the system or product is stabilized and control is established over the more reactive sources of work, these too can be corralled into something that resembles a predictable system.

Here’s a view of the model workflow as work for the product development team originates from the many sources that exist in a typical software company.  The names of the departments/individuals that source the work may be different in an IT shop situation, but the important part is that you sort out these sources into three different categories based on the time horizon in which a response must be generated. 

Model flow of product work in a software company

Immediate Reaction

This kind of work is clearly the most time-critical; in a SAAS shop, this is “production down” for either some or all of your customers and for on-premise products this is a “customer down” that may involve some combination of immediate phone support combined with travel to the site to resolve the issue.  Because of the severity of the situation, everyone needs to stop and react immediately.  For this to be effective, someone needs to have the responsibility of triaging the situation and determine who can help.  If the process for this to happen is not known, then everyone stops, and because many situations can be solved quickly with minimal effort, people get conditioned to ignore these as false alarms.  You need to have clear accountability for the triage and resolution or the result is ineffective communication, long resolution times, and disappointed customers.  With time and a clear focus on root cause analysis leading to robust solutions to the event, you can bring this type of work to near zero.  Reaction times expected are measured in minutes to hours and product delivery of a hotfix is ASAP.

Customer Driven

All healthy companies have customers!  Some are customers you want to keep and others are new customers you want to close.  In either case, the support or sales teams in your organization will be a constant source of requests that tie directly to the well being of a current or prospective customer.  Time lines will be tight, specific commitments will need to be made that are inevitably outside of your current release plans, and without a method for handling this work through a dedicated team, you will instead find your product roadmap and release plans constantly hijacked by customer driven priorities.  There are times when it is appropriate to interrupt your planned activities and to expand the resource pool to include more of the team (I’ve done this twice in the last seven years), but when this happens, I have always timeboxed the activity to a specific collection of issues and been very carefully in managing the stopping and starting of the usual rhythm.  Reaction times expected are measured in days to weeks and a monthly product delivery in the form of a maintenance release is usually acceptable.

Market Driven

The final and most strategic category of work for your team are the new features on your product roadmap.  If your company has a clear product vision and active product management driving it, then there will be no shortage of work in this area, and very frustrated product owners if you do not figure out how to allocate enough resources to satisfy a reasonable part of the need and provide a predictable outcome.  Promises will be made here too, but these promises will be in the form of marketing campaigns and other commitments to your largest customers to future features on that roadmap.  Reaction times expected are measured in months – I find the most effective rhythm for this type of work is a product release every 4-6 months.

Now that you understand the categories and expectations in each area (as well as the ship vehicle and rhythm that makes sense), we can focus on how you organize in order to deal with these differences.  As you can see, I’m proposing two distinct teams to handle this work.  There is overlap for customer driven work, but the primary responsibility for reacting to the request, prioritizing the work, and delivering the solution lies with the Customer Reponse team (or CRT).  The reason I show the overlap is that there are times when it makes sense to have the work done initially by a feature team in your main branch, but the responsibility for backporting to your released branch and shipping the product stays with CRT.  These situations require agreement from the product owner to buy the story in the current iteration and a timeline that allows for everyone to wait until the start of the next iteration for the work to happen, but as long as these conditions are true then it is not particularly disruptive to the rhythm of the feature teams – after all, we are Agile, right?

Saturn V Blast Cone, Air and Space Museum, Washington, D.C.

Let’s dwell on that for a moment – if we are Agile, then why do we need different processes for dealing with this work?  Agility still requires that we contain the periods of change to the transitions between iterations – within the iteration itself, the individual features teams need the latitude to focus on their assigned stories without interruption.  “Agility” is a relative term – if your goal is to ship every 4-6 months, then changing your priorities every 2 weeks is “agile”.  If you are responsible for maintenance releases that ship monthly, then you are probably changing your priorities weekly.  And if you are are “production down”, then all of your priorities change immediately.

The Customer Response team has a difficult job, but one of the best ways to bring order to the chaos is through a prioritized list.  Given that CRT serves multiple constituents, there is a tendency to have multiple lists with one for each internal customer group.  However, unless you have put a significant number of people on the team, you may not have the luxury of working on three “number one” priorities at the same time.  Instead, our process is to meet weekly with all three constituencies involved and to merge the separate priorities into one list we call “The Dirty Dozen”.  The merging of the priorities is done publicly with everyone involved, and we take 30 minutes a week to review the list and adjust as needed for changes or new issues.

The net effect of operating CRT is that the challenges of managing releases on multiple code branches and of performing forward and back port efforts requires configuration management expertise.  You want to look for someone that has this knowledge, has the leadership presence to deal with multiple internal constituents, and who is calm under fire.  Our current CRT lead has a couple of favorite sayings – “Go slower to go fast” (he’s a NASCAR fan) and “Act quickly, think slowly”.  Both capture the fact that reaction time is important, but this team often operates without a safety net.  You need experienced, careful engineers in the role that understand how to accomplish a goal in the most surgical way and yet can live with the pressure of knowing that their changes will likely be deployed into production on their blessing.  As our automated regression capability has improved, we have begun to rely more heavily on automation to help us confirm that a fix has had no unexpected impacts, but until you get to that level of capability, you are completely dependent on the skills and clarity of thinking in the engineers that do the work, so choose them carefully.

What proportion of the team needs to be dedicated to CRT?  I have seen it as high as 25% of my resources in the past, but with improvements in product quality and process capability, it can get lower than 10%.  If you are using offshore resources, you usually can not depend on them for the immediate response work, so CRT tends to be an expensive team because it is usually all local resources.  There are certainly exceptions to this, and it is possible to use offshore resources to fulfill the Customer Driven work.

One last note – if you are curious about how this fits into the organization chart for the the development team, check out:  http://craigkn.wordpress.com/2009/09/10/scaling-the-agile-development-organization/

I was humbled today to have lunch with a local venture fund manager that I have rubbed elbows with over the years.  He asked my about my new plans, so I told him about Marcato, and from there opened a floodgate of interesting insights into both the state of the market we hope to serve as well as how we should go about it.  I figured I would record a few of the pointed insights for posterity as well as to make sure I processed them for myself.  In no particular order…

Look into other examples of people building offshore consulting practices in the area; there are examples of this not working well and we need to make sure there is a big enough market and that we are differentiated.

I’m not sure yet if what we are trying to do has been done, as I think it’s easy to assume that we intend to build the business around selling offshore contractors.  Instead, our interest is to work with the central team to change their processes and structure so that they make better use of existing or new distributed development teams.  We may take a cut of the action of work that we source, but that’s not really our interest.

Be careful not to imply that offshoring is a new phenomena – it has been around long enough that I’m likely to just sound uninformed.

Don’t focus the message too much on new adopters; most organizations are already doing offshore and there are enough people with practical experience at it that the current generation of engineering leaders would likely choose to start a new company with offshore as part of their strategy on day one.  Figure out how to make the message resonate with more experienced shops as well.

Good advice – I think we have a tendency to emphasize the scenario of helping a company new to offshore introduce it with Agile at the same time, where I’m just as confident of the benefit to an existing distributed team that is using other methods.

The blog is more important than the book.

Makes sense – blog readers are relevant now and will follow you as you update your information whereas a book is anonymous and static.  Still want to publish, though!

Fireworks

Be ready to round out my knowledge so that I can act as a complete advisor on the topic; be able to show not only my particular area of expertise but a comprehensive understanding of the marketplace for offshore services so that our client is comfortable that they are getting good advice.

A good idea to be aware of my limitations and what I don’t currently know – part of the value is in providing advice, and if our experience is too narrow then it seems unlikely we become an independent and trusted advisor.  Need to be able to compare the pros and cons of different regions, processes, technologies, and the interplay between them.

If you want to build a national brand, then test your ideas with people outside the midwest.  Get involved with a CTO roundtable in Silicon Valley and see how these ideas hold up in a more competitive and volatile environment.  Be prepared for the attitude that being a big deal in Dubuque, Iowa doesn’t prove that you are ready for the big leagues.

Get out to present at national conferences.  Be provocative but follow it up with credible insight into your ideas and value proposition to other organizations.  Again, to build a national brand and to position ourselves as credible, we have to do more than what has led to our current success.

Ouch – I definitely resemble these remarks.  It’s easy to become used to being a big fish in a small pond.  While we don’t really aspire (yet) to national reach, we do want to build national reputation.  We need to get out there and test the quality of the ideas and the message against the best of breed.

Get copyrights in place to protect the core “nuggets” on which you are going to build the practice.

It appears that internet content published since 1989 is inherently copyrighted even if no legal notice is present.  (see http://www.templetons.com/brad/copymyths.html for more information).  Given this, there would be some recourse if a competitor takes your content and uses it to damage the economic value of the original work, but difficult to show and harder to pursue.  Better to figure out how to keep some of the valuable content out of the public domain, although the reality is that the written content alone is not as valuable as having it applied by someone practiced in the art.

While investments in offshore have been led by the board of directors in the past, these directors are looking for their management teams to be more aggressive in figuring out how to get more leverage out of their software development spending.  Success is more likely if we target the engineering leadership with our message and work with them to take the proposal to their board instead of having it come top down.

This is tricky – deciding the change process or to reduce cost using low-cost outsourcing is just not a natural phenomena for most technical leaders.  However, I think that it is possible to show them how to manage through the change, and with this increased confidence that they can deliver and be successful, this could easily become more common.

One of the advantages of being around a long time is that you get the chance to try a lot of things that don’t work.  If I’m being generous, I call that “wisdom”; if it’s a half full kind of day, then better to call it “perseverance”.  Either way, I’ve had the benefit of trying many different variations on a theme for how to organize a software product development department.  Given these refinements, I’ve narrowed down to a pattern that seems to work pretty well in a variety of different situations and at a wide range of sizes, so I thought I would lay it all out for you and explain the system that it enables.

First, let’s start with the picture itself – I’ve included it here as a PDF attachment for portability sake:  Model Agile Development Organization

Assuming you now have the picture in front of you, now let me explain it.

There are many rituals in the Agile methodology, but probably none more important than the Iteration Review.  Why is it important?  Just ask my boss (our CEO) – not long ago he told me that ”Coming to these reviews is the most energizing part of my job.”  That’s a pretty strong endorsement!  This doesn’t just happen by chance – it takes up front effort, preparation for the event itself, and good moderating by the leader of the meeting to make it work, but when it does the end effect is that your customers are engaged and excited by the work you have done and feel part of the process for making sure that we all produce the best product possible.

Over time each team has figured this out and their leads have learned to coach and walkthrough these demos before the event itself.  The hardest thing to teach is to make sure the engineers avoid using too much jargon or assuming that the audience is an informed about the feature as they are.  They need to be coached to explain why it is important, what we are going to see, then show it and summarize what was shown.  It can be awkward at first, but over time everyone will become comfortable with it and share in the enjoyment of the work and pride of accomplishment.

One last suggestion – we did find it a good idea to freeze the build in the TEST environment a couple of hours before the start of the meeting (this is necessary because most of our team starts working at 3 a.m. our time); the worst thing that can happen is to have last minute changes made by one team break the demos of another (it has happened once or twice).  Freezing TEST ensures that everyone has time for one last runthrough before the show goes on!

We think we found it!  It’s funny how it clicks into place and how bizarre the path can be to get there.  Scott and I were doing name-storming in a shared spreadsheet using Google Apps (I’m sold – this is a cool way to do structured IM) around basic concepts such as Agile, offshore, rhythm, tempo, change, etc and we were stuck on two word mashups that tried to blend these.

My favorite from that group was SharedRhythm, but this sounded more like a product brand than a company name.  Then Scott followed up on looking for word associations on “tempo” and pointed me to a Wikipedia article on the topic.

There it was – we both saw it at about the same time: “Marcato – marching tempo, marked with emphasis”

Why is this the perfect name?  We will use Agile management techniques to create a rhythm that spans distributed development teams.  With our coaching services we set that rhythm – the “marching pace” – and teach others how to sustain it once we are gone.

Next came a little help from Joel, our resident creative guy.  We had considered going outside for help on establishing the logo, brand, and overall design elements for our website, but then we saw the quote and decided we would take a stab at this on our own.  I’m not sure I’m really getting the better end of the deal, as in exchange for free labor all I had to do was agree to cover the cost of an Ivy League tuition

Our New Logo!

The logo has several design elements I find appealing because they resonate.  The capital M could be used by itself.  The three dots represent both staccato marks in music used to punctuate the rhythm – the result is sharp, crisp emphasis on the beat.  They also represent the three partners that are coming together to form this new company.  Finally, three dots together also form an ellipsis – the punctuation used to indicate that there is more to come.  I even find the line underneath vaguely reminiscent of staff lines in music, again appealing to the music theme.

Formally we will be known as “Marcato Partners, LLC” doing business as “Marcato”.  Legal registration and such are underway!

Hmm – I wonder what will happen next…