In Jim Collins’ “Good to Great” he touched on great leaders taking steps to ensure that the wrong people were off the bus and that the right people were in the right seats on the bus.

In his follow up, “How the Mighty Fall”, Collins explores how once-great companies disappear into oblivion and how some manage to turn their decline around.  Once again, the first step that leaders take in trying to resurrect a company involves the concept of ‘the bus’.  Here’s how you know whether the right people are on the bus:

• The right people fit with the company’s core values.
  • You don’t figure out how to get people to share your values … you HIRE them based on your shared values.
• The right people don’t need to be tightly managed.
  • The right people are self-motivated and self-disciplined.
• The right people understand that they don’t have ‘jobs’; they have responsibilities
  • These people can articulate that “I am ultimately responsible for …”.
• The right people fulfill their commitments.
  • They take commitments seriously and thus are careful not to over-commit.
• The right people are passionate about the company and their work.
  • Nothing great happens without passion.
• The right people display ‘window’ and ‘mirror’ maturity
  • When things go well they point out the window to others, when thinks don’t go well they point to the mirror.

My experience has shown me that having the right people on the bus is the most critical part of creating and maintaining a successful software development organization.  Keeping the wrong people on the bus has enormous risks associated with and it is always more cost effective to remove people from the bus as soon as possible rather than keep them around for perceived short term gains.

Leo Laporte (@LeoLaporte) and Jason Calacanis (@JasonCalacanis) recently hosted an interesting podcast (#TWIT Episode 206) wherein Jason asserted that Apple should be vilified for having a business model based on its closed platform and anti-competitive nature.  He encouraged people to give up use of their iPhones in order to protest what he saw as an abuse of power on Apple’s part.  Jason followed that up with an article entitled ‘The Case Against Apple’ where he essentially describes his evidence of the anti-competitive nature of Apple.  He finishes the article with:

Apple will face a user revolt in the coming years based upon Microsoft, Google and other yet-to-be-formed companies, undercutting their core markets with cheap, stable and open devices. Apple’s legendary comeback ability will be for naught if they don’t deeply examine their anti-competitive nature.

What I think Jason is missing here is that Apple ‘fanboys’ (I am admittedly one of them) have been prepared to pay a premium for a good user experience and we’re prepared to live in a closed environment in order to preserve (for now) that good user experience.  The problem here is that we don’t seem to be able to get that same level of user experience elsewhere.  Is that anti-competitive?  Windows has, in the past, been a miserable experience.  There are some technical reasons for this but there is also the primary reason that Apple appears to place more of a premium on producing products that WORK.  Do they work 100% of the time?  No, but they do a damn sight better than most of their competitors.  Is that anti-competitive?  I understand, for now, that part of the price for this is a closed platform.  I wish that wasn’t the case, but currently I value gear that works over open platforms.  If that’s part of the kool-aid then so be it.  That situation will change when a good user experience becomes a commodity.

I look forward to the day when ‘Microsoft and Google undercut Apple with cheap, stable and open devices’ WITH GREAT USER EXPERIENCES.  Until then I will continue to reward the company who apparently has realized how much I value the fact that my IT gear works the way I want and need it to work.  Isn’t that what competition’s all about?

When I started working full-time with Agile development techniques in 2004 I also had the good fortune to start working with the concepts of Pragmatic product management.  What quickly became apparent to me is that the two approaches in their respective fields were beautifully suited to one another.

By articulating the market problems, the nature of the people who have them, and the circumstances under which they experience those problems, Pragmatic product managers communicate to development teams what is really necessary to build great solutions; context.  We’ve all heard the stories of how the software industry’s predilection for waterfall methodologies from the 1970’s through the 1990’s led to an inordinate amount of ‘failed’ projects.  Early proponents of agile development techniques ascribed those failures to the waterfall process itself, rightly arguing that performing development tasks (specifically testing) in phases and a lack of iterative feedback were the biggest causes of these ‘failures’.  However, I would contend that just as large a reason for those ‘failures’ was product management’s inability to communicate what was actually required for those projects to be successful.  Too much emphasis was placed on building to a specification which had often been created and disseminated without providing sufficient context to the people responsible for providing solutions.  Because of this lack of context there was no framework for negotiation with a customer or stakeholders and therefore much of what was built was not actually required to meet the customer’s needs.  This resulted in unnecessary delays and cost overruns at a minimum and often the creation of ineffective solutions which quite rightly were considered ‘failures’ regardless of whether they met the specification.  Even if the solutions were built iteratively, the focus on the specification, rather than the problems in context, might very well have led to the same ineffective solutions.

Many software development companies do not have the luxury of having real-time access to actual customers.  Nor is the concept of building a product based on a single customer’s requirements necessarily attractive.  Instead these companies rely on their product management organizations to represent the needs of customers within a market.  There is a hierarchy of proxy which is created as a result.  The customer is a proxy for the market and the product manager is a proxy for the market.  If the product manager is too busy performing strategic tasks and does not have time to fulfill his product ownership duties for the team then a proxy of a proxy is incurred with all the risk that entails.

All too often, agile projects rely on an internal ‘product expert’ to act as the team’s Product Owner.  The danger of this is that the product expert understands the existing incarnation of the product very well but may not have the viewpoint of a customer who has issues with the product.  Properly implemented agile development techniques usually provide the transparent and tangible progress necessary to make informed business decisions.  However, without a clear sense of the relative value of the problems to be solved it is difficult for the team to understand and embrace those business decisions.  This is where the value of the MRD resides; providing the context necessary for a Product Owner to make sound decisions throughout the development process on behalf of the product manager.

In the end agile product ownership is a subset of all that a product manager is responsible for.  From a Pragmatic perspective, product ownership entails the ‘Product Planning’ tasks of the product manager: Market Requirements, Road Mapping, User Personae, User Scenarios, and Release Milestones.

The Pragmatic Market Requirements Document (MRD) focuses on market problems, the people who have them, and the situations under which they experience them (scenarios).  It also focuses on valuing/prioritizing those problems, people, and scenarios.  Hmmmm … sounds suspiciously like a good start on a backlog of stories!  A story used in an Agile project usually takes the form of: A <type of user> needs to be able to <perform some action> in order to <get some value>.  This is essentially a statement of the circumstances under which a user experiences a problem.  I suppose technically it is an anti-problem as the real problem is the users inability to get the required value by performing the desired action.  Nonetheless there is a direct correlation between the primary elements of a Pragmatic MRD and a product backlog used in an Agile project.  Each scenario is prioritized using the following additional context: impact, frequency, and criteria.  The value to the persona of solving the scenario, the frequency with which the persona experiences the scenario, and the value to the to the Product Manager /Business of solving the scenario, all provide valuable context necessary for establishing business priority.  Once these scenarios have been prioritized, the product manager has a solid starting point for a product backlog.  Further, the entire team has a solid understanding of what problems they are trying to solve and for whom, and what the relative value of those problems is to both the market and the business.  With this context, the team is much better equipped to be able to produce solutions appropriate for the target personae and any decisions around solution options/modifications can be made in the context of the user and the business value.

My wife and brother-in-law own and operate a French/Italian bistro in our little mountain town.  They’ve been in the restaurant industry for 2 decades and are in their 6th year at Quarry.  Naomi runs the front of the house and David runs the kitchen.  Over the years, I’ve picked up a lot of knowledge about what it takes to run a successful restaurant.  It is a labour of love and not an endeavour to be taken lightly or for dreams of huge monetary returns.  I have been fortunate enough to be on the periphery of this and, apart from the odd dish washing shift, have had the luxury of being the unofficial taster of countless culinary gems paired with just enough wine.

During the peak season, when Quarry is busy and tables are turning quickly and constantly throughout the evening, Naomi has often said that the reason is that the team has an innate ability to do two things: prioritize their work and look out for each other.

In the dining room, the staff need to execute on priorities as inputs continue to change: new customers at the door, food ready to be served, tables in need of resetting, patrons ready to order, patrons telephoning for reservations, patrons finishing their first or second course, tables need to be cleared, patrons ready to pay.  All this has to be looked after in a timely manner while keeping the ambiance of the room relaxed and enjoyable.  While there are specialists on the team, each team member must be able to look after any of these tasks.  Further everyone has to be on the look-out for gaps in service which have occurred simply because at any given moment, only the top priorities are being looked after.  Upon noticing a gap, what separates the great team members from the ordinary team members is their ability to seamlessly pick up small tasks in the seconds in between their own top priorities.  There is an understanding that the overall room efficiency and success is everyone’s responsibility.

Similarly in the kitchen, cooks glide past each other in tight quarters, knowing what motions to expect from each other and trusting that each person will be where they need to be given the current state of upcoming orders.  The sense of timing necessary to serve up to 60 patrons with 3 cooks is astonishing.  It means that those cooks need to be constantly evaluating priorities, executing on those priorities (usually in terms of time at temperature and time between courses), and when necessary helping a specialist with too many high priorities while tending their own tasks which, for a short moment, are better spaced than their colleagues’.  David has stated that when this culinary ballet is on form, the adrenaline rush is the reward.

One of the reasons all of this works is the way the team is compensated.  Tips are pooled as the philosophy is that if the team is working well together, all patrons’ experiences will be improved and thus all will be more likely to tip more.  Further if the team feels one of its members is underperforming the team has a vested interest in either helping that team member or recommending that he/she be replaced.

A lot of what I’ve learned about great teams, I’ve learned while eating carbonara at the bar …

Asking ‘why’ is perhaps the most valuable of all questions both in life and software development / product management.  Being the father of two toddlers, I get asked ‘Why?’ a lot.  I only wish the team mates on some of the teams I coach were so inquisitive.  Knowing the ‘Why’ is often the difference between success and failure.  This is, of course why User Stories take the form they do: As a <type of user> I need to be able to <perform some function> so that I can <get some value>.

Both the type of user and the ’so that’ clause provide valuable information in the form of ‘Why’.  Without this information, a team could go horribly astray.  Asking ‘Why?’ helps provide valuable context.

Here’s a simple example:

The user needs to be able to enter surface positional data.  Why?

The directional drilling engineer needs to be able to enter surface positional data so that he/she can perform anti-collision analysis.  Why?

The directional drilling engineer needs to be able to enter surface positional data so that he/she can perform anti-collision analysis, avoid drillstring collisions with offset wells and therefore avoid tremendous expense and/or injury/death of drilling personnel.

Clearly knowing who needs to enter this data, and why, puts a different context in front of the team around the requirement of simply being able to enter surface positional data.

My sons make me answer this question a lot and software development teams could learn a great deal if they if they continually did the same!

The most overlooked of the 12 agile principles described alongside the agile manifesto is perhaps the hardest to come by – building teams around motivated individuals.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

There it is … that term four words in to the first sentence … ‘motivated’.

A very subjective word.  Some people are motivated by money, some people are motivated by the recognition of their peers, others by visions of climbing the corporate ladder.  What this term means in the context of agile principles though is something much more specific: ‘motivated’ by pride in their chosen profession and the desire to learn and improve.

All too often in large traditional organizations, software development team members simply have a job.  Occasionally they’ve simply been beaten into submission and can be resurrected by agile techniques.  Very often however, the people that survive for long periods in large organizations are those that are mediocre and are valued because they don’t rock the boat.   These are the people who will, at best, go through the motions of implementing agile techniques while giving no thought to the principles and philosophy behind them.  At worst these people will simply figure out ways to ‘game the system’.  Of course the ultimate responsibility for tolerating this behaviour lies with management.  Either way, having a motivated cast of characters is crucial to the success of an agile project.

It’s always amazed me the emphasis so many politicians put on ’staying the course’ and not ‘flip-flopping’.  Being able to ’stay the course’ (regardless of what presents itself) is viewed as a sign of strength and resolve … very macho and confidence inspiring.  Apparently, if you change your mind you must be weak and easily manipulated.  Yikes!

If only politicians (let alone the people who have the responsibility of voting them into office) realized that processing new information regularly, and changing course (or indeed ‘flip flopping’) based on that new information, may be EXACTLY what’s required in order to continually deliver value to constituents.

I suppose my naivete is showing …

But, Mousie, thou art no thy lane,
In proving foresight may be vain;
The best-laid schemes o’ mice an ‘men
Gang aft agley,
An’lea’e us nought but grief an’ pain,
For promis’d joy!

till thou art blest, compar’d wi’ me
The present only toucheth thee:
But, Och! I backward cast my e’e.
On prospects drear!
An’ forward, tho’ I canna see,
I guess an’ fear!

Robert Burns (1785)

The most successful implementations of offshore agile development are those where most of the team is co-located offshore.  As long as the developers and testers are co-located and have reasonably continuous access to the Product Owner/domain expert, there is a chance of success.  With that in mind there are still many factors which should be considered when contemplating utilizing off-shore development teams in a distributed agile environment.

COMMUNICATION BARRIERS

The time difference between your team and the offshore team is critical to establishing communication patterns.  If there is not sufficient overlap between the onshore and offshore working hours, at least one onshore team member may have to expand the overlap by working earlier in the morning or later in the evening.  Sometimes all that is required is someone moving their lunch hour 1-2 hrs.  Many employees of offshore companies rely on fixed-departure transportation to get to and from work (and travel great distances) and thus are not able to change their working hours.  Negotiate the possibilities with the offshore company upfront.

Many countries have statutory holidays which differ vastly from North America or Europe.  Further, some of these statutory holidays last for many days at a time rather than just the occasional Monday.  Of course some countries also have different work weeks.  This can either work in your favour or against you depending on the overlap.

Probably the largest barrier to success on a distributed agile project is the likelihood of language /cultural differences which adversely affect the flow of communication.  If you intend to use Scrum methods (daily stand-ups, sprint planning sessions etc) then it is important that you have confidence in the speaking/listening skills of both teams.  Working with offshore teams that emphasize ESL for their employees is a great advantage.

Video conferencing greatly enhances the communication experience for teams.  Being able to see faces and body language helps with the interpretation process that goes along with listening to team mates who do not speak your native tongue fluently.  Obviously the quality of the video conferencing makes a difference and to a large extent it is reliant on the network bandwidth on both ends.  Don’t forget to investigate network reliability and bandwidth in the country/city of the offshore company.

However good the verbal communication is, understand that you will be relying more on Email/IM than you would otherwise like to on a standard agile project.  The good news is that many employees of offshore companies have stronger written than verbal communication skills.  Also, because of the prevalence of Instant Messaging outside of the workplace, having the team connected this way means that both parties can take advantage of asking quick questions over IM on either parties’ off-work hours.  Being able to do this can save many hours for the project as there are fewer ‘15 hr’ delays in having questions answered.

Nothing can replace the value of face-to-face communication.  Given that the offshore team has a reasonable level of verbal communication skills, it will still be necessary to work in-situ with the team with some frequency.  This will mean at least traveling to the offshore team’s campus several times during the project.  Certainly early instances of release planning and iteration planning will benefit from having all parties co-located.  Further, having one or more members of the offshore team travel onshore periodically creates stronger relationships which are paramount to good communication when the team is separated.

While I routinely work with distributed teams where the Product Owner is geographically dispersed from the rest of the team, the domain knowledge of the team is highly critical to the project success.  Some offshore teams specialize in particular domain knowledge while others’ are open to developing that knowledge in-house.  In either case, you need to be aware that your Product Owner’s travel time and time dedicated to answering questions in a full and timely manner is inversely proportional to the domain knowledge of the off-shore team.  Ideally, offshore teams should have direct co-located access to their own domain expert.

AGILE MECHANICS

Practicing iterative/incremental development in a distributed environment requires modifications to some of the basic agile techniques.  Scrums, demonstrations, retrospectives, and planning sessions usually have to be altered to fit the situation.

In situations where the Product Owner is geographically separated from the rest of the team, but the time-zone overlap is sufficient, I’ve been able to hold daily scrums by speaker phone in front of a scrum wall.  The speaker phone in conjunction with a a webcam directed at the Scrum wall is sufficient for the Product Owner to follow and indeed participate in the Scrum.  In situations where the time-zone overlap is insufficient, the Product Owner has had to call in to the offshore Scrum on off hours and view a virtual Scrum board (e.g. Rally).  Both scenarios have proven successful.

In fully co-located projects, I like to perform Demos and Retrospectives on the same day as iteration planning.  Those activities generally take up most of a day.  As one has to factor in time zone differences in distributed agile projects, it becomes clear that these activities need to be split up over multiple days.  The demo is best done ‘live’ but certainly the iteration demo should not be the first time the offshore team receives feedback on functionality developed in the iteration.  Similarly the retrospective should be a chance to review feedback on the iteration already collected in the closing day or two of the iteration.  This way both the demo and the retrospective can be completed in under 2 hrs.  If the team can then be made aware of the subsequent priorities, they can work on the iteration planning in the onshore off-hours and the following day the team can reconvene for 2 hrs to review the iteration plan, review questions and answers for the Product Owner, and re-jig the plan if necessary.  During both of these sessions, Video Conferencing is invaluable.  Often the audio quality of a VC unit is superior to that of standard telephone audio due to the bandwidth dedicated to the VC unit.

In many cases, distributed agile teams cannot effectively use a standard Scrum wall covered in index cards.  A virtual scrum board (e.g. Rally, VersionOne, Team Foundation System) can prove to be almost as engaging for the distributed team.  Using a virtual scrum board, goes against many of the agile principles (mainly the fact that physical artifacts like the wall and the cards foster face-to-face discussion) but it is a necessary sacrifice once one embarks on distributed agile development.

In the end the most important aspect of any model for software development revolves around the ability to make appropriate business decisions based on the most current information at hand.  Companies should always be asking themselves ‘Why do we want to offshore our development?’  Clearly cost reduction is the chief reason, but it is a common mistake to grossly underestimate the real cost of implementing successful distributed offshore development.   There needs to be budget for a moderate amount of travel, virtual backlog/scrum wall tools and ideally video conferencing.  The good news is that once you have made the investment in the teams, tools and techniques the cost of delivering projects declines.

Many companies have dabbled in the practice of ‘off-shoring’ some of their software development.  More and more companies may be looking in that direction as resources become tighter and tighter in this currently shrinking world economy.  Many of the companies who’ve given it a try have made some pretty basic mistakes and others have found success.  Those that have made mistakes have generally missed the mark by NOT actually off-shoring development … just off-shoring some element of the development process; usually testing.  The problem with off-shoring just the testing can be that unless the offshore resources are presented with either the test cases, a detailed functional specification, continual access to a domain expert, or some other form of impossibly detailed acceptance criteria (in conjunction with the relevant domain knowledge), it is difficult for the off-shoring team to meet their customer’s expectations.  This is not to say that off-shoring testing cannot be successful, just that since meaningful testing relies on communicating the intent of the myriad of different usages of an application, any impediment to that communication degrades the delivery of meaningful testing; either in quality or timeliness.  Depending on the nature of the product development, if only one element of the SDLC is to be off-shored, the likely best candidate is test automation.  Having on-shore testers (working in conjunction with the Devs/Product Owner) producing test cases that can then be automated by others presents a situation where the reliance on off-shore domain expertise is diminished.

Agile Software Development as a hand of No Limit Texas Hold’em?

Ever since I started playing various forms of poker “seriously” about 5 years ago, it has struck me that there are definite similarities between these card games and agile software development.  For the past couple of years I’ve been mulling this over and trying to see if the analogy works.  If so, perhaps it would provide another mechanism to illustrate the value of iterative/incremental development.  Here’s what I’ve come up with:

In an agile software development project, the object of the exercise is to continuously deliver as much value as possible given the current conditions.  After every iteration, the Product Owner can see the value created and make decisions on whether to continue (and in what direction) or cancel the project.  In a hand of NLHE the object of the exercise is to continuously make decisions based upon incomplete information such that one can profit from the hand.  After every street, the rounder can see the value accrued, assess the risk, and decide to continue (and in what direction) or fold the hand.  All of these decisions are based on a myriad of inputs which affect the perceived value of proceeding.  As we shall see, Agile projects are analogous to individual hands of poker.

Pre-flop (Release Planning) Action

Prior to seeing any community cards (streets), one must make a decision based on several things: hole card value, position, chip stack, and opponent characteristics.  In order to proceed with the hand, one must wager at least the amount of the big blind.  Of course there are other possible actions:

Limp: This is equivalent to simply paying the ‘cost of doing business’.  Enough information is present to justify starting the project. Based on what is known, while there are still significant uncertainties, there is some undetermined likelihood of success.

Raise: Enough clarity is present to warrant raising management expectations regarding the level of success that‘s possible.

Call a raise: While significant risk is apparent, there is enough information (hand value, relative position, participant characteristics) in place to warrant accepting the increased risk.  On a project, the fact that we have a  seasoned team, known technology and a known domain might cause us to call a raise.

Re-raise: This would occur only when the team believes that their estimation accuracy is sufficient to overcome most likely risks and is a signal of significant confidence.

(Re)Raise All-in: This translates to risking the entire project success on incomplete information regarding the hands of the opponents and the community cards. Committing to a specific combination of schedule, scope and resources at this time is analogous to raising all-in pre-flop.  This is fairly common in ‘waterfall-based’ software development projects.  While this action does occur in poker, it occurs only in specific circumstances involving calculated risk/reward ratios.

Fold: The project is canceled because the likelihood of receiving enough value from the project based on the starting information is extremely low.  If you’re playing poker correctly, this event happens much more often than in software development although sometimes I think we should fold much more than we do in software development.

Flop, Turn, and River (Iteration Planning) Action

After the flop, the majority (3/5) of the common cards have now been exposed.  Some more information is now present for all to see and it is reasonably unambiguous.  Every exposure of a community card is analogous to an iteration planning session.  Whatever the plan was prior to the flop, turn or river, there may be need to adjust the plan based on the new information.  As with most things there is always some amount of risk (unless you’ve hit a royal flush … 20,000:1).  The amount of risk is relative to hand value, position and chip stacks.   Further, taking into account the information (bet amounts and other non-verbal inputs) gathered on prior streets complicates or simplifies the issue depending on your point of view.  The options here are to check or bet in the face of no overt threats, or to call, raise or fold in the face of overt risk.

Check: Based on the newly presented information we are unsure of where we stand and may not be willing to invest more in the project if more adversity arises.  We are certainly not bullish about our strength.

Bet: Based on the newly presented information we believe we are strong enough to invest more in the project given that no added adversity has arisen yet.

Call: Based on the newly presented information, and a new overt risk (someone else is representing strength)  the team believes that it is worthwhile investing more in the project in the face of the new risk.  In poker, this is actually usually deemed a sign of weakness.  To some extent it is viewed as ignoring reality … if you were really strong, wouldn’t you re-raise?

Raise: Based on the newly presented information, and an overt risk (the previous bet), the team believes they are strong (confident enough in their knowledge of the situation, skills and domain) enough to overcome the risk.

Fold: Based on the newly presented information the team realizes that the risks far outweigh the likelihood of success.

The Showdown (Retrospective)

At the end of the hand, if we’ve seen it through, we have a clear indication of success or failure.  In either case we are able to look back at the information taken in during the hand and learn something about people’s patterns and communication styles.  This can be very useful for future projects.

In the end, it’s the experienced teams and card players that are able to raise their stakes and their games as they are able to continually adjust their plans mid-play.