The project that has been 90% done for six months. The program that is 5 years late. The company division that continually loses money, but somehow, survives, getting more good money thrown after bad. The larger the company you work for, the more likely you have seen this phenomena in action.

My term for this is a concept called Egospend. Egospend is what happens when you combine:

• a large sum of financial and/or political capital
• little or no discipline around relevant business metrics, measured frequently
• a culture with a strong sense of loss aversion / high penalties for perceived failure
• decision making by feel and relationship versus results

The degree of Egospend in an organization tends to be the product of those four factors.

Why Traditional PMOs Are Ineffective Against Egospend

Most organizations recognize and want to combat Egospend. Combating Egospend is one of the reasons PMOs came to be, as well as various other forms of governance that occur at various levels of an enterprise. Intentions are always quite good, as nobody enjoys taking multi-million dollar writeoffs after failed projects.

What occurs, unfortunately, as it does in all political systems, is some form of regulatory capture. On the X axis, we have political support for an idea…. let’s call this CSAPS, “Combined Salaries of All Project Sponsors”. On the Y axis, we have HCI, “Historical Costs of Initiative”.

What does “regulatory capture” mean in this context? It admits to the reality that political power can defeat governance functions. In nearly all companies, if the CEO decides to continue funding an initiative that should have died, it will continue to get funding, despite the opinions of the PMO. This is true for traditional PMOs, Lean PMOs, or any other kind that exists in any structure where political power is centralized, such as nearly all modern enterprises.

This effect, of course, is accelerated under corporate cultures that are prone to loss aversion. All it takes are a few executives who have had careers ended over high profile failures – something that isn’t atypical – in order to lock loss aversion into the corporate culture for a very long time.

Where Traditional PMOs Go Wrong

The issue with traditional PMO isn’t the intent. They are often very good at making sure projects are delivered (of course, this isn’t always true either). The issue is deeper – do the projects achieve the business results they were designed to achieve. A key tenent of the Lean Startup movement is that you don’t claim done upon product creation. Rather, you orient around building a product or service where you create a virtuous learning cycle. A learning cycle that works in a manner where you end up with a product that delivers continuous improvement of business results.

Where does this differ from traditional PMOs? Most PMOs try to control change (see, Change Control Board), where Lean PMOs expressly enable and expect change. Successful outcome for a traditional PMO is project delivery, successful outcome for a Lean PMO is results delivery. Traditional PMOs expect projects to finish and move into “maintenance”, Lean PMOs expect products to continually evolve and pivot in order to meet new and evolving customer needs.

By focusing on delivery of projects, with the key metric being project completeness and delivery status, i.e. “did we deliver software – regardless of whether it is the software that a customer actually wants”, the Traditional PMO is blind to actual business results.

Combating This with Lean Enterprise

The idea of Lean Enterprise is to take the lessons from Lean Startup and apply them to the enterprise. How do you take the discipline a startup must have to survive – laser focus on customers, early feedback, real, non-vanity metrics, obsessive focus on your product – and make that work in multi-billion dollar organizations? Surely, there are adaptations – there are regulatory constraints, audit committees, and sheer size that changes how you approach the problem. There are also technical constraints – protection of data is a much bigger deal for a financial services behemoth than it is, say, for a social media startup. You can’t just walk into a Fortune 50 company with Lean Startup as your playbook and be successful.

However, in order to avoid the projects that have both high CSAPS and HCI – the kinds of projects that kill companies, something has to be done. Since CEOs will continue to have ideas, the only real way to combat the perils of Egospend is to lower HCI for initiatives that are doomed to failure. Failure defined by poor business results, not just mere poor project delivery.

How do you do this? We start with Continuous Delivery – the idea that instead of delivering things in large chunks, you deliver incrementally, so you can measure what each change does. You deliver an MVP early, so you can start to get feedback as soon as possible and know whether you need to pivot. You change the way funding works, moving away from annual budgets with fixed scope, and towards contingent budgets based on meeting business objectives.

As you evolve, you start to build a culture that embraces early failure – and learning from same as part of the path towards success. At some point, even the CEO becomes someone who can admit, in a company-wide meeting, that his or her pet idea did not work. By setting such an example, the organization becomes one where hubris and bravado are seen as negative traits, not forms of faux leadership.

Enterprises Need Lean More Than Startups

The irony, of course, is it is the large enterprises of the world that need these ideas the most, since they tend to be where most of the large amounts of money are spent on technology. I have personally seen initiatives in single companies, doomed to failure, that ate up budgets equal to the entire GDP of a developing world country. Initiatives for whom admitting failure would mean the CEO would lose his job (and, thus, more continued investment). Imagine the capital that could be put to better use if we could put an end to this kind of wasteful Egospend.

If you are interested in reading more about this, you can get four chapters of the book, Lean Enterprise, for free, authored by my colleagues Barry O’Reilly and Joanne Molesky, as well as ThoughtWorks Alum Jez Humble.

In ThoughtWorks, one of the most poignant insults one can throw at you is “so-and-so has gone post-technical”. This usually means one has entered the land of management, that place where you give back your brain in exchange for money (or prestige.. or nothing, as it turns out).

Lately, as I have taken on additional roles at ThoughtWorks, the temptation to go “post technical” has put itself forward. Imagine not having to think anymore. Imagine being able to just focus on “strategy” and “people issues”, without all that hard technology stuff.

I could take that path, but I’d rather not…

I remain technical. My day-to-day job may involve things like Statements of Work and such, and I do not write code 100% of the time, but I am making a decision to at least remain somewhat involved in the technical communities in which I have interest.

Of course, my time is more limited, given I have taken on some management responsibility lately. So I can’t pursue everything. And I do have to admit that with my reduced time, I am likely never to be the most “technical person” in any given group of TWers. In fact, given that TWers are all generally really good at their jobs, it would be utter arrogance for me to assume I could keep up with them when I only act in a technical role for 40% of my time. So my bar isn’t TWers – they will most likely all be more technical than I am. But it is remaining competent enough to understand at least 40% of what they talk about, and more importantly, remain excited about technology.

So what am I excited about these days, here is my own, personal, “tech radar” (no fancy graphics required):

• Functional Languages and Big Data

Someday, the world will catch up to where the F#/Clojure people are now. I think the tie between FP and Big Data is strong, and given that is where much of the value will be created in the next 5 years with corporate IT spend, the use of FP will only increase.

• IaaS (note, I don’t say cloud… too overloaded)

I got the cloud bug this year, and I will admit, I am a terminal case. I saw an app where someone deployed a load balancer with an http request. And not an http request that converts into an email that goes to a tech that puts a physical one on a rack. Infrastructure as code is changing this business. Imagine the ability to specify, in human readable code, an organization’s entire server configuration. And realize that configuration by executing the DSL it is written in. That day is approaching, fast. Imagine the possibilities – from everything to devops to disaster recovery.

Why don’t I say cloud? The term is so overloaded that it is meaningless. Anything that runs on the internet is putting “cloud” in front of it’s name, which is why I have stopped using the term and do everything I can to use more descriptive terms.

• Lean Startup

Though not a technology, it is the first thing from a project management standpoint I have been truly excited about in years. At least since Agile, maybe more so. Why? It finally closes the loop, bringing in the entire scientific method into the business of software development. It seems so obvious now, it never ceases to surprise me that it took our industry 50 years to adopt it. Lean Startup, to me, is the application of the scientific method to how you run business. I recently did a webinar that nicely encapsulates how I feel about it in much more detail, but my general sense is that this builds on CD and gives organizations that embrace it a much more repeatable, sustainable path to successfully delivering business results with software.

The three things above are the tools I believe will create most of the value in corporate software over the next 5 years. And I fully intend to remain competent enough to discuss these topics with both technical and business audiences, even if I don’t write code every single day anymore. The trick, not being a full time software developer anymore, will be to:

• Make sure I don’t stop doing some technical work – I still intend to pair program with the team when I can, as well as keep up with a selection of OSS projects I am involved with.
• Continue to read new technical material – I am on planes a lot, should not be too hard. For example, I am learning Python now, despite that I don’t have a good reason to personally code in python.
• Be aware – ultra-aware – that I am not the most technical person in the room. My team-mates will likely know more than me, and I will defer to them on technical arguments more often than not, especially if they have decent data on why a given technical decision needs to be one way or another.

Will this work? We will see. I am only in the starting stages of this journey – will be interesting to see the degree to which my technical skills atrophy from not being a full time developer anymore!

Now that Agile has passed the 10-year mark, many people are starting to wonder what the next step should be in the evolution of Agile. As we start to think about what’s next, it doesn’t hurt to think for a moment about how we got here in the first place. As the saying goes, it’s hard to know where you’re going if you don’t know where you’ve been!

So let’s turn back the clock through the mists of time in the years leading to the Agile Manifesto in 2001. Back when this movement started, many of the “reasons for Agile” just seemed very intuitive. People over process? Sure. Responding to change versus following a predefined plan? Common sense. On the surface, few people would disagree with the assertions made in the Agile Manifesto. But is that enough? Can you following the Manifesto—do it all by the book—and be guaranteed to create software that delivers economic benefit? No. By itself, Agile doesn’t lead to business value!

How Can By-the-Book-Agile Fail?

Let’s be clear. With its increased collaboration with the customer, more frequent releases, and increased engineering and testing discipline, Agile makes delivering value more likely. It’s certainly a vast improvement over multi-year “too big to fail” Waterfall software projects. But even if you do everything right, even if you have the best practitioners in the world building your product, you can still create a product that fails to make money.

Agile—and here we mean the kind that includes the right engineering practices, such as test-driven development (TDD), pairing, SOLID principles, automated acceptance testing, and continuous integration—will ensure that you create a product that works…in the lab, at least. However, despite your best efforts, you might build a very functional eCommerce site that tries to sell something that nobody really wants. Or you might build an internal application that can’t go beyond the lab because the operations people can’t support it in production. These issues—and many other things outside direct control of the team practicing Agile—can thwart even your best efforts.

Article continues here

Have you gone Agile? What are you doing this year to become Agile? We must become Agile in the next three months! These days, it is not unusual to hear about executives wanting to do an “Agile Transformation” on the entire company. Who knew that a bunch of relatively obscure techies would create a movement that is now the lingua franca of executives who are attempting to turn around companies! Agile really has “come a long way, baby.”

It’s amazing how things change in ten years. Once considered a methodology preferred by software developers because it “helped them avoid having to do status reports,” Agile has now gone beyond its original remit as a software development method. The word Agile, in many places, has become nearly synonymous with the word Good. As flattering this must be to the original founders, it probably means it would be wise to think, very candidly, whether Agile—as in Agile Software Development, or a broader Agile Enterprise—is really something that your company can achieve.

Read the rest of this article at InformIT here.

Many of you will remember Revenge of The Nerds, that fine classic movie where a bunch of, well, nerds take over the campus of Adams college by outsmarting and outwitting the jocks. For people who work in computers of a certain age and disposition – say, a late 30s geek from a western culture like myself who might have fit the nerd stereotype at various points in his early upbringing – the movie was somewhat influential. It told a story that, translated into economist-speak, equates to “intellectual capital may someday trump other kinds in terms of economic value creation.”

As it seems to have turned out, we are now in the Revenge of The Nerds economy. Despite 9%+ unemployment in the general economy, overall unemployment for software engineers is a tad below 5%. But this data, which is compelling enough, does not tell the entire story.

The bigger story is around what kinds of things are seeing investment. There is talk of another bubble right now in technical startups. If you are a technology based startup that has reached “Ramen Profitability”, you will almost certainly attract capital. Things are now even getting to the point where we are seeing companies that lack profits going to the IPO market (think Pandora and Groupon) – something that has been out of vogue since at least 2001. One could make the case that we will soon cross the line where it is easier to get a startup funded than it is to get a jumbo mortgage.

If you work in tech, there is a good chance you are feeling this, at least if you are currently employed and working for an employer that has some level of visibility. If you work for Google, Facebook, or some other high tech company, you likely do not have to work that hard to get a new job offer. Notwithstanding the cruel irony that people who are unemployed are often being systemically discriminated against, the job market for really good, currently employed software developers is as robust has it has been in 10 years.

So if the nerds are all right, mostly, what about the jocks? What occupations did they end up in? While some of them may have made it to the NFL as professional football players, most others end up in spilling into the general job market. While the stereotype is that jocks end up in menial jobs, construction, or manufacturing; research being hard to find, my own experience of knowing several such folk points to careers tending to be sales, low-end finance (think mortgages), real estate, and personal training. Given, a sample size of a couple dozen doesn’t really prove anything. However, if one did extrapolate, one could come to a conjecture that while “jocks” for lack of a better word, do not do worse then average now, the nerd/jock investment and employment dynamic has changed.

Why the change? Now that simply taking big leveraged risks with a big pile of money isn’t in fashion (i.e., as it was before the global financial crisis), you need advantages from superior intellectual capital in order to sustain a higher than mean return on investment. Why not in fashion? From 2003-2008, it was accepted that financial engineering was the way to riches. If you only structured your collateralized debt obligation in the correct way, you could invest at 40x leverage and still retain a AAA rating on your debt. Financial engineering gave you higher profits under such a regime than traditional “engineering engineering” could provide. So money flowed into CDS structures and away from the nerdy parts of the economy that invents things.

So now we find ourselves in an economy where capital flocks to things like Pandora, Groupon, Facebook, Linkedin, and other things that, at their core, have interesting algorithms inside them. And we have a situation where if you are a developer capable of writing an interesting and valuable algorithm – or helping a company scale out a system that leverages one of these inventions, you are in high demand.

Good thing for the nerds. What this means for everyone else remains to be seen.