If You Had a Choice, Would You Buy Your Brand of IT?

People of a certain age might remember the Road Runner cartoons from their childhood. In each episode, Wile E. Coyote suffered numerous accidents attempting to snare the bird using products from Acme, Inc. Aside from the opportunities for a product liability lawsuit, I always wondered why he didn’t just quit buying from them.

Sometimes I wonder the same thing about IT organizations and the business units they serve. How many business units, given a choice, would choose their own in-house IT as their provider?

Recent research by Cisco (as reported on CIO.com) suggests that quite a few would not:

Consulting with CIOs and analyzing network traffic in a set of large enterprises in a variety of industries, Cisco determined that the typical firm has on the order of 15 to 22 times more cloud applications running in the workplace than have been authorized by the IT department.

…

And by Cisco’s tally, there is quite a bit that CIOs aren’t seeing. On average, CIOs surveyed estimated that there were 51 cloud services running within their organization. According to Cisco’s analysis, the actual number is 730.

…

And it cuts across sectors. Even in highly regulated industries such as healthcare and financial services, Cisco found between 17 and 20 times more cloud applications running than the IT department estimated.

What’s worse, many recommend heavy-handed tactics on the part of IT to deal with their “unruly” customers:

https://twitter.com/jetpack/status/600571844303921152

Now, note the potential benefits, “…can improve productivity and collaboration with little or no financial cost to the company…” versus the potential downside, “…corporate data may be put at risk or even lost if the employee leaves the company”. Given that both are valid, it would certainly make sense to evaluate the risks involved and whether they can be mitigated. Instead, a draconian knee-jerk is recommended.

The advice to tighten controls on users and consider replicating applications in-house where necessary is laughable. IT traditionally has a customer service problem to begin with, getting stricter probably won’t help. You would also think someone would have noticed that offering to replicate products in-house seems like an empty promise when the reason for going outside is that IT isn’t able to provide what’s needed. It seems like piling on to mention that replicating commercially available services probably won’t make a CIO seem very business-savvy.

Building trust in the process and trust in the product would be a good start to making the customer a partner rather than an antagonist. Or you can rely on their being forced to use you. Monopolies can be a sweet deal…while they last.

Would you buy what you’re selling?

Fixing IT – Too Big to Succeed?

Continuing our discussion that I mentioned in my last post, Greger Wikstrand tweeted the following:

BTW @GeneHughson, I think you'll enjoy our video on #serendipity https://t.co/zTlKIDp8kh with me and @woodyzuill

— Greger Wikstrand PhD (@GregerWikstrand) November 11, 2015

I encourage you to watch the video, it’s short (7:39) and makes some important points, which I’ll touch on below.

Serendipity, when it occurs, is a beautiful thing. Serendipity can occur when heads-down order taking is replaced with collaboration. Awareness of business concerns on the part of IT staff enhances their ability to work together with end users to create effective solutions. Awareness, however, is insufficient.

Woody Zuill‘s early remarks about the bureaucracy that gets in the way of that serendipity struck a nerve. Awareness of how to address a need does little good if the nature of the organization either prevents the need from being addressed. Equally bad is when a modest need must be bloated beyond recognition in order to become “significant” enough for IT intervention. Neither situation works well for the end users, IT, or the business as a whole.

So what’s needed to remedy this?

In “Project lead time”, John Cook asserted that project lead team was related to company size:

A plausible guess is that project lead time would be proportional to the logarithm of the company size. If a company with n employees has a hierarchy with every manager having m subordinates, the number of management layers would be around logm(n). If every project has to be approved by every layer of management, lead time should be logarithmic in the company size. This implies huge companies only take a little longer to start projects than medium-sized companies, and that doesn’t match my experience.

While I agree in principle, I suspect that the dominant factor is not raw size, but the number of management layers Cook refers to. In my experience, equally sized organizations can be more or less nimble depending on the number of approvals and the reporting structure of the approvers. Centralized, shared resources tend to move slower than those that are federated and dedicated. Ownership increases both customer satisfaction and their sense of responsibility for outcomes. Thus, embedding IT staff in business units as integral members of the team seems a better choice than attempting to “align” a shifting set of workers temporarily assigned to a particular project.

The nature of project work, when combined with a traditional shared resource organization, stands as a stumbling block to effective, customer-centric IT. IT’s customers (whether internal, external, or both) are interested in products, not projects. For them, the product isn’t “done” until they’re no longer using it. While I won’t go so far as to say #NoProjects, I share many of the same opinions. Using projects and project management to evolve a product is one thing, I’ve found project-centric IT to be detrimental to all involved.

Having previously led embedded teams (which worked as pseudo-contractors: employed by IT, with the goals and gold coming from the business unit), I can provide at least anecdotal support to the idea that bringing IT and its customers closer pays dividends. Where IT plays general contractor, providing some services and sub-contracting other under the direction of those paying the bills, IT can put its expertise to use meeting needs by adding value rather than just acting as order-takers. This not only allows for the small wins that Woody Zuill mentioned, but also for integrating those small wins into the overall operation of the business units, reducing the number of disconnected data islands.

Obviously there are some constraints around this strategy. Business units need to be able to support their IT costs out of their own budget (which sounds more like a feature than a bug). Likewise, some aspects of IT are more global than local. The answer there, is matching the scope of the IT provider unit with the scope of the customer unit’s responsibility. Federating and embedding allows decisions to be made closer to the point of impact by those with the best visibility into the costs and benefits. Centralization forces everything upwards and away from those points.

Operating as a monolithic parallel organization that needs to be “aligned” to the rest of the organization sounds like a system that’s neither effective nor efficient, certainly not both. When the subject is the distance between the decision and its outcome, bigger isn’t better.

Form Follows Function on SPaMCast 347

This week’s episode of Tom Cagley’s Software Process and Measurement (SPaMCast) podcast features Tom’s essay on project management in an Agile environment (aka “Project Management is Dead”) and a Software Sensei column on testing from Kim Pries in addition to a Form Follows Function installment on microservices, Devops and Conway’s Law.

In SPaMCast 347, Tom and I discuss my “Fixing IT – Microservices and DevOps to the Rescue?” post, specifically on how microservice architectures are not just a technical approach but an organizational one as well.

Fixing IT – Remembering What They’re Paying For

Dan Creswell‘s tweet said it well:

Software development isn't your business: It's just one of many tools for providing a service that satisfies (customer) needs.

— Dan Creswell (@dancres) June 20, 2014

Max Roser‘s tweet, however, illustrated it in unmistakable fashion:

https://twitter.com/jetpack/status/596604003527589890

Success looks like that.

Not everyone gets to create the kind of magic that lets a blind woman “see” her unborn child. Nearly everyone in IT, however, has the ability to influence customer satisfaction. Development, infrastructure, support, all play a part in making someone’s life better or worse. It’s not just what we produce, but also the process, management and governance that determines how we produce. The product is irrelevant, it’s the service that counts. The woman in the picture above isn’t happy about 3D printing, she’s overjoyed at the experience it enabled.

Customer service isn’t just a concern for software vendors. It’s remarkably easy to destroy a relationship and remarkably hard to repair one. The most important alignment is the alignment of concerns between those providing the service and those consuming it. Mistrust between the two is a common source of “Shadow IT” problems, and far from helping, cracking down may well make things worse.

Building trust by meeting needs creates a virtuous circle. Satisfaction breeds appreciation. Appreciation breeds motivation. Motivation, in turns, yields more satisfaction.

As the saying goes, you catch more flies with honey.

Fixing IT – Microservices and DevOps to the Rescue?

Eberhard Wolff‘s question set the stage.

If Conway's Law is so important - are #Microservices more an organizational approach than an architecture?

— Eberhard Wolff (@ewolff) February 18, 2015

Adrian CockCroft‘s reply tied everything together.

.@ewolff Agile, DevOps, Conways Law and Microservices all reinforce each other to speed up product development.

— Adrian Cockcroft - now @adrianco@mastodon.social (@adrianco) February 20, 2015

Conway’s Law is the common thread tying microservice architectures (MSAs) and DevOps together. Significantly, this common thread runs through the entire organization, not just the IT parts. As I noted in my previous post, paying attention to this principle allows you to work with, rather than against, the grain of an organization. Working with the grain of the organization is key, because DevOps, lovely as it is, is not an end, but a means. The desired end, as identified by Mike Kavis in “Is DevOps What Organizations Really Seek?” is to “become high-performing organizations”.

Of all the attributes of such an organization (as identified by Kavis): “Strong Leadership”, “Strong Culture”, “Sound Architecture”, etc., the most important is “High Customer Satisfaction”. For many organizations, high customer satisfaction is a problem area for IT. In a recent article on Business Insider, Red Hat’s CEO Jim Whitehurst noted an increased interest in DevOps on the part of CIOs to deal with what he terms IT’s “fight for its life”:

That’s because IT departments say they had better figure out how to be faster, cheaper, and better. If they don’t, the company’s employees will no longer depend on them. They bring their own PCs, tablets and phones to work and they buy whatever cloud services they want to do their jobs. And the CIO will find his budget increasingly shifted to other manager’s pockets.

IT has has a history of cycles of neglect or rejection of new/disruptive technologies followed by catch-up crises: PCs in the 80s, Web in the 90s, BYOD/Cloud/IOT/etc. now. What’s different this time is the increasing level of technical knowledge and access to solutions outside of IT. As Krishnan Subramanian has noted, playing catch-up may become less and less viable:

@GeneHughson This time impact will be orders of magnitude greater. Catching up in next refresh cycle might be too late

— Krish Subramanian (@krishnan) February 20, 2015

MSAs enable flexible applications via composing vertical slices of business functionality rather than horizontal layers of technical concerns. These same principles can apply to higher levels of abstraction up to the enterprise’s IT architecture. Likewise, DevOps incorporates the same viewpoint shift in terms of the IT organization. This architectural change (both technical and business) can allow for integration between IT and the business it enables. As Twila Day recently noted, this integration goes far beyond mere alignment into “active partnership between IT and your business units”:

Partnership means working together, side by side. It means that technology leaders are actively involved in strategic development at the highest levels of your organization. It means that all the way up and down your organization, any talented person can propose an innovative idea, tactic or strategy, regardless of where s/he works. The business might have an idea first, or IT might have it first. No matter. What’s important is that the two groups work side by side to accomplish the most important business objectives.

Transforming IT from an adversary into a partner is primarily a cultural shift that involves both parties if it’s to be successful. Organizational and technical architecture cannot be neglected, however, in that they can either help or hinder that transformation. DevOps can facilitate this via its focus on the product rather than any one project (which is a concern shared by the customers) and by having the flexibility to tailor its pace to that of the customer rather than forcing a one size fits all (aka one size fits none).

Form Follows Function on SPaMCAST 319

I’m back with another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast.

SPaMCast 319 features Tom’s “Why Are Requirements So Hard To Get Right?” segment, followed by Jo Ann Sweeny’s new column, “Explaining Change”. Tom and I close it out with a discussion of one of my previous posts, “Fixing IT – Credible or Cassandra?”.

Fixing IT – Credible or Cassandra?

In Greek mythology, Cassandra was a princess of Troy who possessed the gift of prophecy, but was cursed never to be believed. I was reminded of the story by a tweet from Peter Kretzman:

To the biz, IT folk are unfortunately often viewed as overstating impacts, overreacting, etc. The flip side: we're sometimes right. #cio

— Peter Kretzman (@PeterKretzman) October 17, 2014

Credibility is a precious commodity in the business world. It’s hard to earn and yet can be lost astonishingly easily. Poor customer service, regardless of whether it’s due to malice, apathy, or just plain ignorance, damages trust.

Likewise, commitment mismatches can leave customers (internal and/or external) disaffected. The project that will be “out of sight, out of mind” for IT is the product that they will be saddled with for years to come. IT’s perceived lack of commitment (justified or not) is a source of conflict and mistrust.

Lack of a business focus is a credibility killer as well. Things like indulging faddish practices, essentially engaging in one-sided experiments with the enterprise’s money, are seen as evidence of immaturity. A dictatorial attitude toward technology issues is typically resented (regardless of whether the opinion is correct). Failure to communicate business value, whether out of arrogance or ignorance, can lead to ill-advised decisions on the part of the business. When you’re asking for seven figures and “trust me” is your sole justification, you cannot complain when you get turned down.

Things that might seem purely technical can damage the relationship with the customer. Technology for technology’s sake, putting your vision ahead of the customer’s needs, ignoring user experience, and inadequate attention to quality can all lead to a loss of trust.

Quality and reliability can be particularly problematic. Stepping into the breach and heroically fixing issues can be perceived as admirable in some organizations. All a customer sees is an outage. When dial tone services go down, so too does credibility. As Matt Ballantine observed in his post “Firefighting”:

But if your world is one where you can only justify your own existence through the solving of problems that are of your own creation, you’re in trouble long term. That’s where IT has been – and why commodity services have become so pervasive so quickly. The IT team wins no points for fixing stuff that’s gone wrong when someone else can be providing that stuff without it failing all the time.

Working with the business, IT can serve as a powerful force multiplier. Opportunities can be seized and risks averted. For that to happen, however, IT has to be heard. The less we shoot ourselves in the foot, the better chance we have.

Fixing IT – IT as Concierge or General Contractor?

Last fall I had the pleasure of engaging Jeff Sussna, Christian Verstraete and Christian Reilly in a multi-day discussion on Twitter regarding IT’s relationship with cloud providers. As it developed, the conversation morphed into a discussion of potential metaphors for IT.

At the mention of “metaphor”, I’d imagine that eyes are glazing over, but bear with me while I establish its relevance to IT. Now Merriam-Webster tells us that “metaphor” is “a figure of speech in which a word or phrase literally denoting one kind of object or idea is used in place of another to suggest a likeness or analogy between them”. We find this same type of analogy used with patterns, the concept of which came out of Christopher Alexander’s A Pattern Language. In essence, these metaphors are patterns, communicating a potential solution to problems of enterprise IT architecture in the same way that “bridge” and “factory” communicate potential solutions to software design problems. As such, they provide a frame of reference to those of us within IT as well as those we serve. Their importance lies in the message they convey to both sides of the table.

Two candidate metaphors emerged from the discussion. Christian Reilly took the view that an IT department’s role should become like that of a concierge, a service aggregator. While agreeing in principle, I took the position that a better analogy was that of a general contractor. A general contractor works to meet the client’s needs, performing some services while subcontracting others out, in a manner similar to the concierge. The difference is that the contractor possesses a set of domain expertise useful for advising the client. The contractor is also bound by building codes that constrain him/her in delivering the customer’s requests. This describes what, in my opinion, the role of IT should be.

The dysfunctional situation described in the first post of this series, “Fixing IT – How to Make a Monster (Customer)”, defines the antithesis of an effective IT operation. “Fixing IT – Taming the (Customer) Beast”, the second post in the series, discusses some of the mindset changes needed to repair the relationship between IT and the business and why that relationship is so important. The third post, “Fixing IT – Products, Not Projects Revisited”, outlines the way delivery processes can affect IT’s relationship with the business. “Fixing IT – The Importance of Ownership”, the fourth post in the series, takes on how the issues of budget and ownership can affect the relationship. This post, will wrap up the series by bringing those issues together to outline my opinion on how IT can move forward in spite of the challenges it faces today.

The ZDNet post that inspired the discussion I mentioned above, “4 ways IT can rise above outside cloud competitors”, is an excellent example of how IT can turn things around by providing additional value to cloud services. This can be done by acting as a pseudo-VAR in place of acting as a competitor as the ZDNet article proposed. In either case, IT provides real value to the business via its specific knowledge of both the business domain and the in-house technical environment. This approach, advocated by Christian Verstraete in his HP Blogs post “Respond to Shadow-IT, source services from external providers”, is becoming more and more necessary because 7 out of 10 organizations are using unapproved cloud applications (according to a study from January, 2013).

IT has been in this position before. Thirty years ago the disruptive, security challenging technology that IT had no time and budget for was the PC. History teaches that that genie is not going back in the bottle. Instead, the winning approach is to enable the use of technology that furthers the goals of the business (which is all the business wants, anyway) in a safe manner.

The words “in a safe manner” above is what makes the general contractor metaphor appropriate. IT serves two sets of masters, the individual business units and the enterprise as a whole. Sometimes, the interests of a business unit can conflict with those of the organization as a whole. In these situations, IT has a valid reason to refuse to break the rules (although finding a way to achieve the desired outcome and stay within the rules is better than a flat refusal). What is important is that the rules, as such, are not owned by IT, but by the organization. IT is well placed to advise the enterprise about the technical capabilities and trade-offs around decisions regarding security, business processes, etc. It is inappropriate, however, for IT to attempt to dictate these decisions (this is actually an example of a business unit’s interests potentially conflicting with those of the enterprise). Steve Jones illustrated how counter-productive this usurpation can be in his post “Why your IT strategy failed or why the business hates IT”:

IT Guy: “The new systems have new processes and we need to tell you what they are so you can change.”

Business Guy: “Have you done an impact analysis against our current processes?”

IT Guy: “No we’ve just defined the Best Practice To-Be processes, you need to do the impact and change management. We need the meeting so we can tell you what the To-Be processes are”

Business Guy in a voice so dripping with sarcasm I thought we’d have a flood: “I look forward to our IT department telling the business what Best Practice is for our industry.”

IT Guy, completely failing to read the sarcasm: “Great we’ll get it organised”

Some take exception to referring to “the business”, observing that IT is part of the business. This, of course, is true. However, the best way to demonstrate that is not via the terms used in conversations, but via the support given to executing the enterprise’s strategy. Making things happen is the way show that support.

Fixing IT – The Importance of Ownership

Organizations that have a centralized budgeting and provision of IT services risk creating a disconnect between those that need technology services and those that provide those services. The first post in this series alluded to the problem – those needing the services have too little control over obtaining those services. If there is only a single provider with finite capacity and a finite budget, then there is the potential for consumers to be left out when demand exceeds supply. Governance processes set up to manage the allocation of services may be ineffective and can lead to dysfunctional behavior when business unit leaders attempt to game the system. Lastly, this situation creates a perverse incentive to gold plate projects in order to compensate for the uncertainty over when the business unit might next get the attention of IT.

The DevOps approach I suggested in my previous post only partially addresses the issues. Having a dedicated team means little if the size, composition, processes, and priorities of that team are outside your control. Much is heard about the concept of “alignment”, but mere alignment is insufficient. As Brenda Michelson noted in “Beware the “Alignment Trap””:

I started to use the term ‘business-IT integration’, because I’m thinking beyond traditional business-IT alignment. Alignment refers to the review and reconciliation of independent activities, in this context the reconciliation of business strategy and plans with IT strategy, architecture and plans.

For business to reap the true value of IT, business and IT must collaborate on the development of strategy, architecture and plans. This collaboration, which should continue through delivery and operations, is business-IT integration.

To achieve the integration Michelson referred to, one should bear in mind Conway’s law: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. The reason to do so is elegantly expressed in Ruth Malan’s paraphrase of it: ” if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”. She goes on to say:

The organizational divides are going to drive the true seams in the system.

The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition drives team ownership. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational distance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete–structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.

Enterprises are systems, social systems, but systems nonetheless. In the case of business units and IT, you have a social system creating, maintaining, and evolving digital systems. Assuming Conway’s law is true, simpler organizational structures should yield simplified systems (in both the technical and organizational realms). The opposite is also true, poor business architecture can actually reinforce dysfunction and prevent progress. Tom Graves post “Financial-architecture and enterprise-architecture” graphically illustrates just such a case where the accounting structure and approval processes conspired to prevent cost savings:

In fact, the business-case was obvious – or at least, obvious to anyone who’d actually looked at what we’d done. The potential savings in licence-fees alone ran into many millions of dollars a year – let alone the more subtle savings from re-using idle servers or freeing-up unneeded real-estate. By comparison, the costs were tiny: in some cases not much more than a few hours of paperwork, and overall perhaps a few staff-FTE for a few months at most.

But the sting in the tail was that requirement for proof, in terms of the organisation’s standard company-accounts. What we discovered, to our horror, was that the accounts themselves prevented us from doing so: the way those accounts were structured actually made it impossible to make almost any business-case at all for ever shutting anything down.

It should be clear that business structures and processes should be designed to facilitate the execution of business strategy. Part of this is putting technology decision-making into the hands of the business. IT is well positioned to inform those decisions in terms of technical trade-offs, but hardly qualified to decide from a business standpoint. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results by Peter Weill and Jeanne W. Ross (excerpted by David Consulting Group – see table 5) shows that business-driven governance optimizes for profit and growth.

When making decisions about how to use technology in furtherance of business goals is coupled with the responsibility for funding those decisions, customers have greater incentive to make more prudent decisions about their use of technology. Additionally, when those costs are borne by the business unit, both the unit and the enterprise have a clearer picture of its financial state than if those IT costs are accounted for in IT’s budget.

When IT is in the position of advising on and enabling, rather than controlling, use of technology, some benefits accrue. When there’s no need to hide “Shadow IT” from the IT department, business units can take advantage of advice re: security, what other units are doing, etc. The same applies to using outsourcing to augment in-house IT. By being aware of these external capabilities, IT is positioned as a partner to the business unit in attaining its goals, allowing IT to play to its strengths. IT departments that can support business goals as advisers and coordinators of technology in addition to being providers can extend their capabilities with external providers without fear of replacement.

Fixing IT – Products, Not Projects Revisited

Google “disconnect between IT and business” and you get 16.9 million hits in just under half a second. In the first page of results you’ll find names like Cutter, Forbes, Huffington Post, and Business Insider. These facts should make it clear that the problem is real and pervasive. Where did this disconnect come from and how do you remedy it?

In the first two posts of this series (“Fixing IT – How to Make a Monster (Customer)” and “Fixing IT – Taming the (Customer) Beast”), I discussed the systemic problem of customer service and how it might potentially be overcome. Another disconnect, one that I’ve touched on before, is IT’s focus on projects instead of products. Although this issue relates to customer service and customer-centricity, it has other impacts that cause it to warrant its own post.

Projects, a concept which seems to be the center of the universe for so many IT departments, are not priority for most stakeholders; the resulting product is. For IT, unless you’re running a pure flow process where the product’s lifetime is a continuous stream of changes and additions, projects are the events/activities that result in the creation or enhancement of the product. They are what happens to the thing, not the thing itself. That being said, I’m not a fan of the #NoProjects viewpoint. Just because they’re not the most important concept doesn’t mean they’re not an important concept; it’s just that perspective and priorities are needed.

How often do you think of the construction of your home? While it was a project that took time, effort and money, in the end, you probably don’t care. I’d be willing to bet that you derive more value and satisfaction from the use of it than its construction (which generally only comes to mind if a problem surfaces). Likewise, with IT’s customers, they care about the result. In fact, they start to care about that result at the same time that IT is traditionally considering it “done”.

IT Projects which are “done” represent a dangerous situation. In many cases, the project team moves on and the system is consigned to “support”, meaning that those best qualified to fix issues are most likely unavailable. This degraded level of support erodes trust, acting like the grenade in Tom Graves’ “Playing ‘pass the grenade’?”:

What’s the ‘grenade’? Well, it’s kinda like a hot-potato – except that you’ll know when you have a hot-potato, because it burns everyone’s fingers somewhat in passing, whereas a grenade feels perfectly safe and ordinary and unimportant until it blows up in your face…

One of the “grenades” Tom lists is “so-called ‘customer-service’ whose design, either by default or by intent, denies those who need that service from receiving it”. In other words, poor service due to ignorance of our customers needs and concerns can cause as big a rift as that due to outright malice. This is important because, as Seth Godin notes in “Thinking lifetime (don’t break the chain)”, only “The traveling salesman, the carnival barker and the old-time businessman can hit and run”. For all others, their benefit lies in the lifetime of their relationship with the customer. Think of this lifetime as a chain, each link representing an exchange of value between you and your customer:

Think of the interaction at the deli counter or the pump or the bursar’s office or the alumni office or on the website from the point of view of the customer and the chain. Where are the moments where you might lose her forever? What are the key places where you need to intervene and invest in the relationship instead of milk it, or drag it through the mud? Assuming that your competitors are just as selfish and metric-driven as you are isn’t a great strategy, because you’re still losing when you break the chain.

Support is not a cost center, it’s a profit center. Treating customers with urgency and clarity and respect (maintaining the chain) is more urgent than ever…

Think lifetime, all the time.

Having a product focus, rather than a project focus, affects the architectural design and the development of the system as well. A tweet from Rebecca Wirfs-Brock sums up the issue: “One tension that always exists (especially agile design) is when&how to support variability in the prob with a flexible design solution”. With a product focus, the product is not done until the day it’s taken out of service. As Brenda Michelson tweeted, “if software is never done, architecture must allow equally for structure and next transition; flex don’t break”. With a project focus, the team can “hit and run”, making it a tempting proposition to over-rely on YAGNI.

Evan Bottcher, in “Projects are evil and must be destroyed”, observed;

Projects deliver exactly what they promise. Project teams have little incentive to invest in the long term operation and maintenance of the systems that they create. I’m not saying that the team doesn’t care or are intentionally acting irresponsibly, but when delivery pressure is applied the first things to be dropped from the project schedule will be the cross-functional concerns that make the system reliable, monitorable, deployable, and maintainable ongoing.

The DevOps tenet of a team supporting what they build is an excellent example of product focus in action. Working under those conditions, the team has a powerful incentive to grow and evolve the system over its entire lifetime. In essence, the team develops an ownership interest in the product that helps to cement their relationship with the system’s stakeholders. Ownership, particularly in relation to those stakeholders, is a word that you will hear more about in the next installment of this series of posts.

[I have to give a shout-out to Tony DaSilva, his post “Thanks, But No Thanks” came out while I was still writing this one and in commenting on it re: #NoProjects, I realized that there was something more I needed to include in this post. Tony’s posts are always thought-provoking, literally in this case!]

[More serendipity – this exchange on Twitter between Lorri MacVittie, Dave Roberst, James Urquhart, and Brenda Michelson occurred after I finished the post but before I published – the money quote from Brenda: “you say “DOOM”, PMO says “Next”. Project centricity (funding, attention) dooms corporate codebase”]