I had the pleasure of catching up with Jim Highsmith recently and we had an interesting discussion on the topic of technical debt.  We were talking about the non obvious consequences to high technical debt loads.  One particular insight that rang true from my own experience was the effect of high technical debt loads on the psychology and mind set of an organization and in particular, the tendency for an organization to actually underperform beyond the level that might, on the surface, be dictated by the technical debt load.

After an organization experiences extended periods of high technical debt, the decision making processes of the software’s stakeholders often begins to change.  Faced with repeated instances where the inflexibility, fragility, or speed to augment or change the software has caused the organization to fail to capitalize on a new opportunity or respond to urgent change, stakeholders slowly start to form a mental model of the software’s limitations.  Typically, this model is a darker, more pessimistic view than reality.  Also, they typically has an inaccurate view of the actual limitations imposed by the debt load.  These inaccuracies get anchored more to circumstances where failure has occured more than they are informed by architectural of quality limitations of the code base (though there is, of course, a strong enough correlation to reinforce this model in the stakeholder’s mind).  

Unfortunately, as the mental model solidifies, stakeholders consciously (or subconsciously) begin relying on their internal model of the softwares limitations and the organization’s ability to respond instead of soliciting the development team’s opinion or engaging the organization’s formal product management process.  Often, the product managers fall into the same pattern, no longer consulting the developers or architects for estimations.

The consequence of this behavior is a systematic underperformance of the organization.  Opportunities are overlooked or passed on, even when a percentage may have been achievable by the organization despite the technical debt level of the software.  This leads to an interesting dysfunction in the organization where the perception gap where the organization underperforms the current state of the software and development teams begin to defend their code base, objecting to the characterization by the business.  This incentivizes both sides not to invest in technical debt reduction as the development team loses credibility defending the perception gap and the business refuses to support or fund technical debt reduction because of lack of confidence in the organization’s ability to execute.

I had the honor and great privilege to be one of the 33 attendees at the 10 Years Agile gathering at Snowbird, Utah.  The gathering’s goal was to celebrate our accomplishments in the Agile Community, reflect on what has transpired since the Manifesto’s signing, and dialog on what remains undone.  Agile has, over the last 10 years, grown to be the dominant development methodology.  It has tapped into a number of fundamental best practices for productivity and efficient, flexible value creation.  It has matured and mainstreamed.

In the closing hours of the gathering, the team distilled the amazing dialog of the weekend into four areas of focus for the agile community going forward.  Out of those, three dealt with the maturation of agile.  Education, technical excellence, and leadership all focus on maximizing the value of the last ten years.  The fourth stood out to me as the essence, and inevitable impact, of Agile on the future of the world of technology.

“Maximize Value Creation Across the Entire Process”

We are seeing agile principles move upsteam and downstream in the value creation process to spawn or heavily influence entire movements like DevOps and Customer Development.  The next frontier of value delivery for Agile will be on the linkages and support of holistic views of value creation.  I’ll be interested to see how the community responds to this challenge.

I’ve wrestled with some hairy large scale agile problems.  I’ve found that the coordination, temporal synchronization, and management overhead represented dramatic waste.  While many argue that this is part of the nature of scaling up, I have a hypothesis.  I believe that a shift from a team oriented organizational structure to a community oriented organizational paradigm will result significant efficiently improvements over highly synchronized, coordinated, and regimented teams.  One of the many problems that large scale organizations face in this regard is release planning.  

Let’s unpack this practice to understand the challenges it represents, in practice, for most organizations.

Coordination: As the number of teams increase, it becomes challenging to coordinate work allocation between groups.  Historically, I have created elaborate structures, tools, and rituals to try to make this more efficient.  Traditional release planning activities creates an unhealthy cycle of “point in time” moments of clarity and focus that then degrade over time until the tactical decisions made on a daily basis by the teams drop to a sufficiently low quality as to act as a forcing function for replanning.  The productivity and budgetary cost implications of large scale release planning act as a counter balancing force that actively encourages extending the use of poor information longer.  This leads most organizations to reach equilibrium with quarterly (or annual!!) release planning.  

Because even a quarterly planning function is challenging to coordinate at large scale, most organizations will further compromise on other axes to work around the budgetary and logistical constraints.  Typical suspects are:

Time boxing of the event, regardless of actual time required for the complexity and scope of the organization’s mandate

Participant constraints, where delegates, meant to represent all the knowledge and experience of a team or stakeholder, are selected to participate which creates another source of imperfect information into the planning process (further eroding the half life of the plan’s usefulness) or leads to significant time delays, cutting into the already limited time allotted to the planning process.

Scope constraints, where topics discussed are unnaturally limited to a list of predefined priorities or “strategic” initiatives, which often flies in the face of the organic interdependencies between otherwise tactical concerns and the topics of import.  This leads to polite fictions where planning for significant work gets deferred under the banner of dependancies (or high brow euphemisms like Architectural Runway and Technical Debt reduction).  This directly and proportionally builds inaccuracies into the plan which further reduces the useful tenure of the plan.

What should be done?

Organizations need to rearchitect their planning processes.  Two key focus areas of a more organic and natural process are:

Align planning to areas of focus.  Any product has a natural set of key drivers for change.  Sometimes this is the implementation of a single business model (think Lean Startup MVP).  Other times it has a natural set of key constituents that can be effectively segmented into a portfolio. Additionally, there are a set of concerns such as technical debt levels relative to the expected longevity and activity of the code base or operational and support concerns.  By segmenting planning, the activities can be aligned to more natural events and cadences in the business (such as industry cycles and events, line of business calendars, etc).  Planning can then be smoothed out into a finer grain process that more closely resembles a continual planning model (with budgetary alignment based on priority).

Move to a more fluid and fungible resource model.  One of the biggest sources of impedance between stakeholder priorities and development capacity is over specialization of resources and teams.  

There is a natural tendency for organization stakeholders to want to codify priorities and portfolio allocation into the organizational structure.  While it makes sense on the surface and it is easy to align budget and consensus around the practice, it immediately cements a point in time set of priorities and organizational concerns into an org chart.  This makes it incredibly hard to react to changes in stakeholder priories and react to changes in the business.  It also creates an unnecessary and destructive tendency to shrink and grow teams not based on the merits of the personnel but on team alignment to priorities.  

There is a natural tendency for technical leaders and contributors to want to codify technology decisions and code bases into organizational structures.  ”This is the RoR team.”  ”This is the platform team.”  ”This is the blue widget team.”  All of these represent technologists natural desire for efficiency.  Because a team (or location) has a history with a particular code base or technology, most technologists will want to funnel all requirements involving a the specialization through that team.  This creates significant bottlenecks that are not well appreciated by stakeholders.  Being told that they cannot have the thing that will deliver the most business value because it requires a specific team that is working on something else is not easy to swallow.  Organizations should create development communities that transcend team affiliation so that work can more efficiently align to business value return instead of technical resource availability.  While strengths and weaknesses will always exist, codifying cross training into process and ensuring the model promotes wide geographic exposure maximizes return on development cost centers.

Development teams are becoming more virtual, transient, and distributed. The lack of colocation makes it challenging to experience much of the cohesion benefits that come from positive reinforcement in intrateam interactions. The increasing instability in team membership makes it difficult to establish and maintain a team culture, shared identity, and the expectations for individual practices and habits that make up the less talked about, but vitally important component of a development process. Trends like Kanban, Continuous Deployment, and DevOps are driving an intense focus on cycle time and are driving out traditional cushions in schedules and team performance variability. All of this makes it very challenging for team leaders and stakeholders to keep a pulse on how a project is progressing qualitatively.

Game Mechanics, while not a panacea, is a strong contender for filling the void being created by the structural changes taking place in development organizations. Let’s examine the applicability of some of the more common game mechanic constructs:

• Badges allow for both feedback on behavior mastery and reenforces team culture and shared values. 
• Voting with titles creates a durable system of record for accomplishments and contribution and externalizes inter team dynamics. 
• Leaderboards provide a consistent level of intensity and motivation and focuses team members by personalizing their contributions to shared team goals and key metrics. 
• Game results become an interesting form of project reporting that provides unique quantitative insight into a range of qualitative questions. Savvy development managers often glean great insight from simply walking around and observing her team. Energy levels, momentum, engagement, and confidence in deliverables and dates are just a few of the qualitative insights this can yield. When your team is distributed, this key source of knowledge is gone. Game results and trends provide an interesting surrogate. 
• Game results operate as a form of institutional memory providing consistency in the face of changing personalities on an unstable team. At a team level, they provide new members with a quick (but deep) understanding of acceptable performance levels and team values. It also acts as a form of personal reputation, allowing a new team member to quickly understand the strengths of her new coworkers. 
• Game results provide a rapid feedback loop for an individual to understand how their recent performance and individual behaviors align to the ideal. This is perhaps the most powerful aspect of game mechanics. Reviews and other HR concepts rarely create desired changes because they occur to infrequently to be used in habit creation or behavior modification and have too much overloaded importance for honest discourse (read compensation and promotion). Code reviews and peer feedback, while valuable is focused in the result of individual behavior (the code, defects, functional issues, etc) not the actual behaviors, actions, and practices of the individuals themselves. 

While game mechanics can provide some interesting benefits to agile teams, there are significant potential pitfalls. The value of game mechanics increases as a function of the quality of the specific defined mechanics. Poorly thought out game mechanics can have dramatically negative effects. There is a temptation to tie extrinsic rewards to game results. Anyone who thinks this is a good idea, should read the great research and arguments in Dan Pink’s book Drive (in fact, anyone thinking of embarking in a game mechanics experiment should read this book). In this same vein, while e competitive effects of game mechanics can boost team performance for short periods, game mechanics should be positioned and nurtured as a mirror for intrinsic motivation and provide a rapid feedback loop for an individual to assess their behaviors and performance against team culture and goals.

A fascinating trend that I have noticed accelerating of late is the socialization of the development process. One of the more innovative corners of this trend is the introduction of social objects into the development world. A social object is a domain object in a business process which has been surfaced to interested parties independent of the normal process workflow and wrapped in social functionality to form a community and provide a system of record for the body of ad hoc processes that generally execute in parallel to the structured business process execution. An example of this is the work salesforce.com has done around sales processes with Chatter. Any opportunity, lead, contact, or other domain object has a full set of social/collaborative capabilities.

The typical set of features that make up a social object are the ability follow and receive updates to the social experience around the specific social object, express affiliation or interest to others, the ability to comment or otherwise carry on a conversation around the object, and a nexus of information in the form of a profile page. Often the ability to create relationships to other social objects orthogonally to the application data model is also supported. Likewise, you also often see collaborative content management around the social object. Examples of collaborative content management might include wiki like content creation, photos, documents, or other rich media.

In development organizations, we are seeing some very interesting social objects emerge.

The most common social object in development organizations is the requirement/story/feature. Most ALM tools are creating social experiences that allow an idea to form a community of stakeholders (customers, public, internal) and have that idea evolve into a fully fleshed out requirement or feature through dialog and social prioritization (idea networks and voting/ranking). Many organizations are extending this idea inside the feature implementation lifecycle with product managers, QA, developers, professional services, operations, and other constituents involved in the delivery of the feature to users. Less rework, better implementations, and shorter commercialization cycles are common benefits.

Beyond requirements, the code itself is becoming social objects. Historically, comments in code served as the primary repository of conversation between developers. Starting with the open source code repositories and extending to the commercial software tools vendors, code visualization systems layered on top of the source code repository are starting to provide conduits for conversation and communication. Wiki like rich annotation as well as threaded conversations and commenting are becoming a prevalent in tools like Github, Bitbucket, and Fisheye. Additionally, as code is getting created, the interpersonal feedback processes between developers is getting social as well. From change set comments to full blown collaborative code review tools, the conversations that used to take place in casual conversation and formal documents or meetings is moving into a free form, continuous conversation. The implications for knowledge capture and decision documentation are significant with the barriers to many objectives historically requiring onerous process becoming a by product of authentic and productivity enhancing collaboration.

While discussion forums and public bug tracking databases are the elder statesmen of the social object world in development, these tools are starting to provide more accessible tools for creating internal collaborative conversations between support, QA, developers, and product managers to streamline the effect resolution process. While few fundamental changes are taking place, the paradigm shift in design is making otherwise little used features more interesting with follow capabilities and links to actionable data like change sets for patches and links to test case repos.

Visionary social development practitioners are also extending the social object strategy to more interesting and less obvious domain objects. For examples, many are turning software builds into social objects so developers and QA professionals can collaborate on data and configuration dependancies required to test new versions of their software. These are replacing a high friction component of many development organizations with a natural collaborative alternative. Likewise, operations staff are exploring build based social objects an effective tool for satisfying ITIL and SAS70 requirements without elaborate handover documents and forms. Additionally, DevOps organizations can enhance the development and operations communication process based on the build based social collaboration.

It is still early and vendors are still have uneven support for the social object paradigm. However the derivative benefits are profound. It will be an interesting few years for tool vendors as they ride a renaissance in their market fueled by social innovations.

Background and the Three Core Inputs

I’ve watched e lean startup movement gain momentum with great interest over the last few years. While I was no longer in a start up environment, I found that Steve Blank’s Customer Development Process worked well for any new venture (new product, new market, or other significant shift of expansion of a component of your business model). While the MVP concept was well documented, I found an alarming lack of focus in the nuts and bolts of product management in this environment. Most descriptions of the customer development process juxtapose it to agile development, so it is interesting to me that more attention is not paid to the meshing of the gears between the two. While not a thorough treatment, I thought I would document the inputs into my backlog.

The Customer Development Process

The customer development process is, of course, the primary (almost exclusive) driver for functional requirements into my backlog. The lion’s share comes from MVP definition, where the business case is driven by the implementation of my business model. I have been heavily influenced by Dean Leffingwell’s excellent work on his Big Picture Agile work. As such, I use a three tier model for requirements tracking (epics, features, and stories). My epics correspond, generally, to the large scale solution assumptions in my business model. I also have epics for major funnels that I am building (activation, revenue, and referral especially). Each epic has a few features which represent the course grain features required. The features are typically sized at a granularity where anyone can understand them and their value. Each feature will have a number of stories, each one at the smallest granularity that delivers business value. While that sounds like a lot of complexity, I will add to the “lean doesn’t mean ” meme with: “Lean doesn’t meant small scale”. When you get more than a couple dozen people working in your project, the three tier requirements model feels just right. I will insert the obligatory, “smaller teams do just fine with two tiers.”

The second source of backlog stories comes from testing and refinement. Every day reveals more A/B test results, validated learnings, and assumptions disproven. With each of these, stories get added to make small tweaks and implement new tests to quickly iterate towards product/market fit. Occasionally, a new epic gets injected to represent a pivot in business model.

Organic Architecture

Many seem to gloss over architecture in their quest for simplicity and speed. I’ve found three critical areas that require explicit management of your architecture. The first source of stories is architectural spikes. When delving into the unknown, your technical team will still often need to try something out in order to find the right technical path. The second is architectural runway. Even in the leanest of organizations, there is often a need to set up a database, incorporate a new open source package, or otherwise fortify the underpinnings of the application. I have found that more spikes occur early, and more runway stories occur after some traction has been secured. Lastly, and most overlooked is technical debt reduction. While beyond the scope of this discussion, it is critical that the amount of technical debt that in incurred be managed explicitly. When it gets too high, it needs to get paid down.

DevOps

The guys in operations always draw the short stick when it comes to having a voice in product. Running a DevOps process keeps operations close to the product, and more importantly keeps product management cognizant of the issues that need to be resolved. There are two DevOps inputs that stand out. The first is the output of monitoring (logs, environment, user behavior, and funnels) that indicate an operational issue is occurring. The second is the output of DevOps retrospectives (five why meetings or equivalent). One of the most insidious forms of technical debt is Operational Debt and is characterized by manual processes in operations that lead to outages, execution/scale constraints, and budget overruns.

Putting it all Together

A good product owner or team can take these inputs, weave them together and avoid many of the classic pitfalls of a new product.

When I first heard the story of John Henry as a very young child, I found it puzzling. I couldn’t understand how anyone could honestly believe that somehow the human spirit could triumph over machinery at manual repetitive tasks. Later, I came to understand that this story was an allegory for society’s struggle to accept marginalization in value of human labor as a result of the modernization of the industrial age. I didn’t understand the story as a child, because the superiority of mechanized labor over human labor was well accepted and sewn into the collective consciousness. Today, we are reliving the John Henry story. The new battleground? AI (primarily Machine Learning Algorithms) vs Crowdsourcing. The buzz around the Human Cloud is that we can harness the intuitive pattern recognition and judgement abilities of people that machines just cant effectively replicate. Sadly, I think in large part, this is simply reliving the seductive, but ultimately hopeless story of John Henry. We are already starting to see quantitative studies to show how this movie ends. That said, I’ve found some compelling niches for crowd sourcing that complement the use of AI:

• Crowd sourcing is very effective for ad hoc jobs where the cost to automate dramatically outweighs the cost of acquisition and QA on the crowd sourced model.   
• Likewise, it is well suited where the domain contains a graduated value return as a function of quality. 
• Crowd sourcing can also be effectively used as an audit function to discover holes and exploits of your automated algorithm (eg to discover that people are gaming your moderation system using #u€&!ng symbols….). 
• Crowd sourcing is a great training source for machine learning algorithm based solutions.  If you can’t beat the machines, at least you can work for them….

It is New Years Day. Time for New Years resolutions. Almost everyone puts weight loss, health, and fitness on there list. I thought I would make a quick top five list of my favorite technologies in the area. As you might guess, it is full of gadgets, social analytics, and human cloud components.

Dailyburn

First on my list is Daily Burn. While not perfect, Daily Burn represents the best system of record for personal health and fitness information.

First it has the integrated tracking of The Big Four: Food, Exercise, Weight, and Sleep. It is weaker on vital and medical information and its sleep tracking is brand new.

The most important component of a health app is data entry. Daily Burn does a good job here. The iPhone app is excellent with fast intuitive entry. It has integrated with Withings for automating weight and body fat data entry. It has integrated with Zeo for sleep data entry. It has a great crowd sourcing integration for ensuring the food and exercise databases are robust (key for fast data entry). It has a good barcode scanner as well, now a requirement for food trackers.

It has solid social features, with a friend system for peer support and a trainer community for expert advice.

The biggest drawback is data access and reporting. There is no API, so getting your data out or creating outbound integrations isn’t possible. It reminds me of the Facebook google contacts controversy….easy in, but no way out. Worse than the lack of API is the clumsy reporting. It is hard to do analysis and aggregate reporting. The options are poor and you can answer only the most basic questions.

Next to reporting, the next biggest issue is the challenge to accurate caloric burn tracking. Simply put, they need a fitbit integration.

Despite the drawbacks, dailyburn is an app I use multiple times a day, every day of the week.

Fitbit

The fitbit is s pedometer with style. I waiting for months for my fit bit to ship, but it was worth it. The fitbit provides me with a critical piece of missing data: how many calories I burn outside of workouts. Most apps just baseline your daily burn, but in reality, it varies dramatically (at least for me). Without the fitbit, I would have to be content with that blind spot. The fitbit uses a wii like accelerometer. The display is super cool (though mine went out a few days after I got the unit). Data entry isn’t too bad. Whenever I come close to my computer, the data is sucked out of the fitbit and into a web application. There isn’t an API or an iPhone app, but these guys are sharp, so I expect them to create a great experience outside of core caloric burn tracking.

The fitbit website has great usability, fantastic data analysis, including community benchmarking. On the social side, skillful weaving of game mechanics into the reporting is great for motivation and positive behavior reinforcement.

I desperately wish i had an automated solution for getting the fitbit data into daily burn, where my workout data is, but that isn’t too bad as a manual process.

Withings Scale

The Withings wifi scale is one of the coolest toys I have ever bought. The scale is super high quality. The wifi support means that logging headaches are completely eliminated. The iPad app has perhaps the best weight visualization reporting of any app I have used. It does great trending and normalization. It allows me to see my weight and my lean muscle mass at the same time, side by side. It also does intelligent scaling on both the weight and time axes with pinch/zoom. Of course, the dailyburn integration seals the deal.

My Zeo

I didn’t get a Zeo until December, so my experience is limited. However, the Zeo has already earned a spot in my top five list. I’ve spent months with demotivating trial and error on environmental, diet, and scheduling tweaks to my sleep, trying to maximize physical and mental restoration while minimizing the time requirement. I had pretty much written off making meaningful improvements because my “data” was too subject. The Zeo provides great information and has allowed me to make more progress in a couple weeks than the entire rest of the year. For a few weeks prior to the Zeo, I had made some progress with my fitbit, but there isn’t a comparison in terms of the data collected or the accuracy between the two.

The Zeo syncs to dailyburn, which is great, but the lack of wifi, greatly increase the friction in the process.

GetFriday

Yes. Technically GetFriday isn’t a technology. That said, it is the human cloud equivalent of e Swiss army knife for personal health and fitness. GetFriday is one of the more progressive offshore personal assistant services. You buy subscriptions to a set number of hours of their team’s time. You have a point of contact, which operates as your institutional memory, but they can scale up with many people to complete tasks faster, or to complete them when your primary assistant is not available. Here are some of the ways I use GetFriday for health and fitness:

No fitbit integration to dailyburn? No problem. GetFriday and enter all the calorie burn deltas by reviewing the fitbit website and hand keying the data into dailyburn.

My food not in dailyburn’s impressive food database? Snap a picture of the nutrition label and email it to GetFriday to enter for you (also works great in conjunction with my personal chef service).

Not motivated enough to enter a complicated meal? Take a picture and have GetFriday figure it out.

Want to test drive a competing solution (like fitbit’s beautiful web UI)? GetFriday can keep the two in sync while you evaluate.

GetFriday researches health issues, finds and registers me for races, orders food, supplements, and other consumables.

Honorable Mention: The Four Hour Body

Fantastic book that mentioned almost every one of my five items.

@careerisover made an interesting case for why the tablet (read: iPad) is the odd man odd for executive use. In the very short term, I think he is right. However, despite my fear of sounding like a me too fanboy, I wanted to lay out my case for why it is early, but the fight is already over between netbooks, laptops, and tablets (spoiler: tablets win in the end).

First, my credentials/bias. I have been an ultraportable notebook user for years. I travel hundreds of thousands of miles a year. I have run medium sized orgs with 10-30 directs and a few hundred people total. I am a technology executive, so my computing demands are heavy. Lots of data analysis, content creation, presentations, meetings, and collaboration. I bought the iPad on the first day and switched to the 3G model on the first day it was available. I progressed through an evolution of carrying three devices (MacBook Air, iPad, iPhone) to discontinuing traveling with a laptop. I have achieved almost full productivity on the iPad.

The basic netbook-over-tablet premise is that the smart choice is to carry a netbook and a smartphone with the later subsuming all functionality of the tablet. (Implied is the idea that the alternative is that the tablet would be the ONLY device carried.) This would fall short for several reasons. First, the virtual keyboard is too limiting for data manipulation and content creation. Second, voice applications (read: phone calls) are too awkward. Third, as smartphones evolve, they’ll take over any gaps between the net book and phone.

I agree with all the points made, and disagree with the conclusion. Let’s break it down:

It’s a paradigm shift

The android and iOS platforms represent a trend line towards the consumerization of the computer. Their are more fundamental reasons apple dropped the “computer company” from it’s name. The new breed of “mobile” OSes represent an easier to use, more productive, fit to purpose experience than windows, macos, or the attempts at desktop Linux. They are very early and immature, but the trend line is clear. As they mature, they will replace most knowledge workers’ computer use cases. Executives, in particular, will be the among the first to be self sufficient in this new world.

The first generation iPad is barely usable for industrial strength knowledge work, and the android offerings lag behind that. That said, the rate of evolution is extreme. Some rewiring of habits is required, and executives should get in on this early to ensure they ride the productivity wave (and associated competitive advantage) from the beginning.

It’s close enough

If your job is primarily of some combination of email, content consumption, task management and tracking, collaboration, research, or capture, the iPad and tablet are superior to the net book experience. The always on, instant boot, and push notifications change the way you work. It allows for the higher productivity of the larger form factor to take place as easily and in all the same places as the smartphone. This allows the executive to sprinkle in meatier tasks in small amounts of downtime that would otherwise be filled with email only. The tablet has a social context closer to phone or pad of paper than computer. That means it is socially acceptable to take it with you everywhere. A net book is closer to a laptop. Whipping a netbook out in a nice restaurant will draw the same set of uncomfortable stares as if you hauled a 30 inch monitor and an external keyboard in.

For other tasks, like content creation, you can get by. I’ve build graphics and diagram intensive presentations entirely on my iPad. For general purpose word processing documents, it is more than serviceable. It will get better…fast. For some content creation tasks, it will surpass the equivalent desktop experience, which leads us to…

What about that touch interface, anyway?

The touch interface is the next evolution in interaction patterns. It allows for two powerful innovations that will outpace the windows and macos world.

First, for a large class of executive focused content creation tasks, the touch interface dramatically outstrips the mouse equivalent. In particular, tasks that involve manipulating content objects will benefit. The ability to “reach out” and interact with the objects is more natural. It also lowers the bar for many tasks. I can already create diagrams more quickly on my iPad than in visio on my laptop. Anyone wanting to see how is will play out should look at Omnigraffle for the iPad (send me a message if I am missing an app that better exemplifies this).

Second, the virtualization of the keyboard is an inevitability. Once proficiency issues are overcome via a successful approach to feedback loops, this innovation will open up many productivity enhancements with very specialized input metaphors. The querty keyboard, designed to slow input down, will be relegated to long form writing only. While freeform input examples abound, a great specialized keyboard example comes in Apple’s Numbers application for the iPad.

What about voice?

Carry a smartphone.

Don’t like that answer? Buy a Bluetooth headset. The practice of holding the device to your face is dying. Augmented conversation context like Voice + data, chat backchannels, and video is killing that as an option.

Conclusion: The writing is on the wall

The sales of iPads is already foreshadowing the future. Netbook sales are getting pounded by the tablet. Executives are leading the charge. If you are stuck in the net book world for too much longer, maybe your career IS over. :-)

Friends and Family, we are gathered together here today to morn the passing of an old friend.  She lived a long full life and was a true hero.  We will never forget the contribution that our friend, the Iteration, made to our lives.

Blasphemy

In casual conversation over the last 18 months, I’ve had many chats with practitioners, vendors, and agile/lean strategists about the work that I was doing around large scale agile rollouts and product portfolio management  and lately around large scale distributed agile, social’s impact on development, and the human cloud.  A topic that always came up was how I would have done things different in retrospect.  One point that would always generate discussion or controversy was my statement that I would have done away with iterations.  In late 2008, that was met with derisive responses which typically caused the conversation to shift to sports or the weather.  In 2009, those conversations spawned healthy dialogs about the value of iterations and pitfalls of their removal.  In 2010, particularly with the most innovative development teams, the response has been, “Yeah, we did that too.”

Why did we adopt the iteration?

The value of iterations have been very well documented (exhaustively actually) in book after book.  However, there are three particularly compelling drivers.

Cadence

Iterations represent a rhythm to the development process.  Rhythm through repeated routine is a critical driver of productivity and consistency of output in any repetitive task.  This was a core tenant of the industrial revolution.  The assembly line is put in motion, each step is measured, cookie cutter.  Inconsistency in the cadence of fabrication is investigated and remediated.   More importantly, cadence is hard wired in our brain and is fundamental to human performance.

Forcing Function

The iteration, with its short duration of typically a week to a month, serves as a forcing function to drive features to conclusion.  This forcing function also ensures that features are small and implementable in a reasonable amount of time.  That further leads to small enough increments of complexity that the average developer can have a sufficiently reasonable chance of creating an acceptable implementation and design.

Synchronization

Most importantly, iterations form a natural synchronization point for stakeholders both upstream and downstream to the development process.  The predominance of development issues are requirements issues.  The iteration ensures that those with the knowledge of what needs to be built actually look at and comment on what HAS been built at a regular interval.  Waste is reduced and organizational value is increased.  Likewise, small iterations reduce the risk of defects and environmental instability and shrink remediation times for defects by shortening the time that between when a change is introduced and when it can be put into a production or simulated production environment.

All goodness….

So why are iterations going away?

Iterations are an unnatural concept

As the name implies, iterations are an arbitrary time slice…a line in the sand.  This leads to all sorts of technical and logistical gymnastics, that often have more drawbacks than benefits.  While the drive to relentlessly divide features into their smallest possible unit of deliverable business value is important and valuable, artificial iteration boundaries tend to encourage bad habits like layer cake division.  More insidious, developers almost always make the division decision.  The more often that decision is not aligned to true business value, the less relevance stories have to business stakeholders.  In my experience, as little as 10% “noise” in story value can cause a non product management stakeholder to tune out of the story flow of a team.

Iterations encourage the introduction of Technical Debt

The “unnatural” and arbitrary sprint end deadline creates a few interesting behaviors in developers.  While the forcing function nature is great, it puts enormous pressure on developers to cut corners to meet the team commitment.  While mature teams can often make the decision to push stories out, the predominant behavior is to compromise on quality.  When “end of release” quality pressure occurs every week or two, technical debt, particularly tougher to detect varieties increase quickly.

Iterations hurt your developers self esteem

The sustainability goals of Agile are well known and critical to long term productivity of an development organization.  While the velocity metric provides a defense to burnout, the iteration introduces a couple of critical cancers to development health.  

First, the tyranny of iteration end (which, for reasons that are baffling to me, most people put on a Friday) leads to Second Weekend Syndrome (SWS).  Second Weekend Syndrome refers to the common practice of developers getting behind in burndown of stories in a sprint and either because of internal pressure (self worth, sense of commitment) or social pressure

use the second weekend of the now ubiquitous two week sprint to “catch up”.  As Second Weekend Syndrome progresses, its effects are debilitating.  Even personally, I have had a few developers burn out because they were secretly or silently suffering from Second Weekend Syndrome.  The cultural impact of even one developer on the team suffering from SWS is infectious, reducing productivity and morale of an entire team.  

Second, Iterations create a tension between stakeholders and development around prioritization.  Requirements priority is a reflection of changes in understanding or circumstance in the business context of the product.  Other than the cybernetic interplay between release and requirements understanding (seeing a working solution to a requirement), these changes in priority have little to do with development cadence (the iteration).  The likelihood of a requirements change corresponding to the beginning of a sprint planning cycle is less likely than not.  While historically, requirements were boxed up into MRDs and put in storage for a few months, this was an artificial function of the product delivery process, not a natural reflection of requirements capture and understanding.  This is poorly understood by the typical developer.  Where this comes into conflict is when stakeholders begin to reduce the feedback loop in response to the consistent delivery of solutions to their problems.  Eventually, the expectation of lead time between a realization of requirements change or priority change falls to zero based on the historical success of agile delivery (call it Erik’s Law of Lead Time).  Unfortunately, because the iteration sets an arbitrary lower limit on lead time, conflict occurs when lead time expectation becomes smaller than iteration length.  The very common byproduct is bitter developers who can’t understand why irrational stakeholders “can’t even wait two weeks for a change”.  Developers dig in with a war against requirements instability which starts a negative downward spiral.

Iterations increase cycle time and decrease predictability

There is an interesting cognitive dissidence that occurs between the unnatural and arbitrary length of a sprint, the “boxcaring” (delivery coupling) of often to usually unrelated requirements, and the nature of requirements prioritization “in the real world.”  (Erik’s Law of Lead Time for requirements discussed earlier) Because multiple developers capacity is pooled into a unit of productivity (the iteration) and then that more course grain pool is “filled up” with a set of high priority requirements, there is, by definition, a coupling of less important features to more important.  Also by convention and best practice, those features are smaller than the unit of capacity.  In other words, you put smaller items (a story that takes a few hours or days) into a larger iteration (that is some multiple greater than one of the length of the most important story).  As discussed earlier with regards to technical debt, any volatility in estimation accuracy leads to end of sprint execution challenges.  While the introduction of technical debt is probably the most common strategy used in practice, a close follower (and best practice) is to jettison the lowest priority stories from the sprint.  This jettisoning of stories decreases the predictability of story delivery, with lower priority stories in a sprint suffering from increased cycle time as well.  Worse, while the best practice is the jettisoning of low priority stories, in practice, the more common practice is larger stories, which are at increased risk of “slipping” as they are the most common things left undone as a sprint end approaches due to team interdependencies and the closeness in time of velocity inferred production time of a large story and the iteration length (ever heard, “it’s done but it isn’t tested yet.” in your last stand up of an iteration?).  The consequence of large stories more commonly suffering sprint decommit is that most teams organize their sprints around one or two important stories and then “filler”.  The important stories, sadly, are usually the largest.  This leads to cycle time volatility IN PRACTICE correlated to the MOST IMPORTANT functionality in the iteration based development team.

Benefits of Iterationless Development

While extolling the virtues of iterationless development are beyond the scope of this discussion, here is an overview of a few value points.

Iterationless development gets rid of the tyranny of the iteration end.  This opens the door for developers (and the organization) to execute at the optimal sustainable cycle time.

Cycle time has the opportunity to be reduced by removing the cycle time tax incurred by the timeboxed “boxcar” of requirements.

Requirements and prioritization changes can take place at any time, without causing consternation with development.  WIP is much smaller, limiting the likelihood of a requirement change impacting an active development activity.

It opens up opportunities for more diverse team organization functions like place shifted (remote) and time shifted (multiple time zones or work schedules) development.

What about cadence?

Cadance can (and should) be moved to a more natural concept.  Some popular cadences are around builds and features.

What about forcing functions?

Dramatic advances in practitioner adoption of continuous integration and deployment, DevOps, and configuration management now allow the forcing function to occur more frequently and at a finer grain level.

What about stakeholder synchronization?

The more frequent forcing functions provide greater upstream and downstream visibility and tighter feedback loops.  WIP limits, dynamic portfolio allocation, and QoS schemes feed stakeholders only as much as they can readily consume, maximizing efficiency and organizational value delivery.

It’s a brave new world for development and I look forward to exploring it with everyone.