My Social Links

I'm ready to semantically divorce from Agile?

10 years has gone by and the terms 'Agile' and 'Scrum' have risen, declined, and are presently plotting towards a cataclysmic fall. Perhaps without bloodletting, but i'm willing to bet that it will cost our industry far more money than it did the Roman Republic 2000 years ago (insert inflation math here).

I have personally grown weary of interview candidates who profess to understand Agile, but who only speak of it in terms of brochure level exposure.

Agile is iterative software delivery, scrum meetings, and talking to the customer

There are several issues with this blunt statement, or admission of enlightenment.


  1. Agile and Scrum are not quite the same thing. If you don't at least understand that Agile governs the whole approach across engineering and management practices, and that Scrum is strictly the latter, then you can't claim any enlightenment with respect to these topics. My biggest take-away from this statement is that the candidate practiced scrum, but paid no attention to XP engineering practices, which i now refer to as Agile Development Practices. Should i dare ask if they have ever written a unit test?
  2. Scrum is suffering from it's own simplicity. Anybody can pick up a cole's notes on Scrum and genuinely feel like they've cracked it. The fact that i can get a Scrum Certification after 2 days in some places only entrenches this myth.
  3. People focus on the structure of methodologies, often at the expense of the values and principles. Exercising Scrum is the easy part, but ensuring that you maintain the spirit of the Agile Manifesto is difficult to master.


And so here i am, 10 years later - a self-diagnosed abuser of Agile for at least half that time. As the counter-culture builds around me in a typical reaction to failed attempts at Agile, i'm left wondering how to describe my approach to software development without using the terms that i evangelized before. I daresay Agile has mainstreamed, and that is the first step in it's inevitable decline.

Now we have to play the game of semantics so that we can indulge executives everywhere with a new rebranded methodology, but that somehow, surrepticiously, maintains the same old values and principles. Because, in the end, the foundation for code craftsmanship and software professionalism must surely stand on its own.

Here is the article that prompted this latest stochatic ripple.

t's too bad. The good Agile--the real Agile--it really works. I've seen it. My colleagues have seen it. It's been repeated hundreds of times, and some of those projects have succeeded for years. But those hundreds of successes will be drowned out by the thousands of failures. - James Shore


Making a Business Case for Refactoring

Here is the business case i recently made for a necessary refactoring in our platform that emerged after the project scope was approved. This may be of additional interest to others that consider Business POs to be the sole source of prioritization in a complex matrixed organization.

The Epic Story can be described as:  “As a developer, i want the cost of adding a new <product> to the platform to be as cheap as possible, so that we can deliver to market quickly and so that we can deliver on our promise of high quality.”

Cost of refactoring = 50-75 SP

Reduced cost for adding future products= –20SP

The immediate response from Product Owners or Project Managers is to balk at the cost and to bemoan the effect it will have on approved delivery dates. Typically, after considerable humming and hawing, handshake deals are made to preserve the Iron Triangle without admitting to the quality concessions that are necessary. Where have we seen this before? It almost sounds like an endemic decision tree that perpetually afflicts our industry.

The impact this decision has on quality is worse than one might believe. The cost calculation is compounded with each successive backlog that does not implement this new software pattern. That is to say it is exponential, not linear.

Let's look 2 years into the future and assume we'll deliver 3 products / year.

Base Cost of implementing new product with older pattern = ~40SP

(+) escalating cost of low maintainability code = x^3+10

(+) escalating cost to quality and QA efforts = x^3+10

If x=1 for the first product of that year, then this project will incur an additional 22 SP in rework, for a total of 40+22 = 62 SP.

x=2 --> 36 SP

x=3 --> 74 SP

x=4 --> 148 SP

x=5 --> 270 SP

x=6 --> 452 SP

Cumulative Cost = 1000 SP (you can probably argue the math and the numbers used, but you cannot argue the exponential decay to quality)

What this leads to, of course, is another House of Cards Platform waiting to happen, and the resulting paralysis that is often faced when trying to approve a new project. This is a pattern of decay that a lot of organizations follow, and these are the types of decisions, when not acted upon, that lead  to large 6000+ SP replatforming efforts. Perhaps we finally see how the cost of Refactoring now seems small compared to the alternative.

This is why Engineering/Architecture will always have the legitimate case to push for 'Technical' POs on a given backlog. Tech debt has increasingly been associated with 'optional' engineering work to help address token quality concerns, but the truth is that we are trying to independently select work that has a definitive impact on business value - albeit through reduced cost and time to delivery, if not directly through user NPS scores. We are ensuring that the derivatives market for an organization remains healthy, if not the present stock price.

So, we have 2 choices here. We either pay for the cost of this refactoring now, or we pay for it later. The cost in choosing the latter paints an awful picture above.

1. The trade-off is between short-term business need (revenues / time to market) with intentional decrease in platform quality (must pay for it later)


2. Long-term health and stability of the product while possibly missing initial product launch dates

I'm ok with either decision, as long as we understand the ultimate cost to the future of our products, our quality, and our delivery times. Ultimately, the business must make the best decision here, and with enough trust between these groups, i am confident that it will always be the right one.


Business Value & Quality are the same: Convincing the Organization

Seeking and engendering accountability amongst an agile team is one of several difficult transformations within the maturation process. Unfortunately, some of us are still of the belief that accountability can be 'encouraged' or influenced from a motive outside the team. Although this approach may ultimately work, it's far more likely to fail, because the only lasting form of accountability, is that which the team builds within itself.

For every developer on a modern agile team, the motivation to achieve a date is still important, but what has now ascended above it, is the motivation to build a high quality product at a sustainable pace. Do no devalue the pride a developer feels in delivering high quality craftsmanship, as opposed to just simply delivering it on time. The irony here is that the business ends up with far more intrinsic value with the former. Business value and quality are one in the same, and cannot be separated. We have 40 years of software development to back up this claim.

And so, yes, i too would love it if teams could report on their status at the demo, and to explain why certain stories weren't completed, but with respect to time and maturity, we weren't able to make it work. As long as that explanation does not take the form of an apology to an external source, because if accountability is flowing upwards and outside the team, we have only paper accountability that crumbles with the slightest pressure. Bravery and not fear must be the prevailing emotion on the team.

Our current answer is to put our faith and trust in the Agile leaders of those teams, and to invest in their training. A team that is forced to adopt scrum without understanding the underlying principles and values, is a listless team with unpredictable quality and productivity. We may ultimately force them to meet dates, thinking it is the right thing to do, but at what cost? The Agile Leader is responsible for building a culture where both quality and execution are sought, and where much pride is taken from achieving both.


Manager 2.0

Managers in the IT world are slowly realizing that the previous model of command and control is a poor bedfellow to sucess. Forty years ago in a new industry that had little history and wisdom to draw upon, the tendency to resort to a more traditional, and disciplined model, was natural. Comparisons with the Engineering disciplines, and all the pressure we put on ourselves to achieve ISO certification, or CMM level 5, bestowed upon us an unhealthy expectation of certainty and predictability, where little exists, and indeed, where little is expected.

Agile forces us to focus on people and culture as the conditions for success. However, this success is often predicated on an organization's ability to transform culture throughout the older and more traditional hierarchy. The following article describes one aspect of this transition for the former Manager of the development team. How will this role change to accomodate self-organization and team accountability? Although it doesn't seem to fit into the classic Scrum model, we are increasingly finding a desperate need for leadership that applies itself differently, and towards a more noble goal - guiding and mentoring a team. If success is more often defined by the people who participate in it, rather than the technology or solutions selected, then it makes sense for a Manager to focus on this as well.

The days of General Patton like C&C are over. Wielding people like units on a battlefield has lost its appeal, and instead, our industry is transforming towards Servant Leadership and Management 2.0.




Environmental Hypocrisy

It just occurred to me how dangerous the prevailing attitude towards the environment may be amongst the well educated snobbery of Western society. How many times have you heard “I’m just doing my bit – whatever i can to save the environment”. This sounds dangerously close to the carrion call of the guilty. One could argue that if every single person on the planet “did their small little bit”, they would be accomplishing 2 things. With respect to the environment, this would be arguably nothing at all, but at least it assuages their guilt and apprehension about how their contributions are perceived as a concerned and conscientious global citizen.

I will now argue that the above 2 effects have a NET negative impact on the environment. Adding up the “little bits” from everyone is a lot less than the collective apathy generated by the same gesture. Imagine what impact we could generate amongst the mid to upper classes, if they directed their significant resources against making fundamental changes to their lives and their businesses. Instead, by satisfying themselves with enough effort to brag about their accomplishments at a coffee table chat, they’ve effectively immunized themselves against criticism, but at the cost of making a real difference.

So, i’m glad that environmentalists everywhere are picketing, rioting, making news, and changing their lives, but until the general public views the environment as a real issue and not just another way to prove their social responsibility, it won’t matter.

I understand that the next generation is being inundated with concern about the environment, but it is also a fallacy to expect that we have enough time to wait for them to institute needed change.

The clock is ticking, and although i’ve done my little bit, i’ll be the first one to line up in front of the hypocrisy claims office. My only surprise is that there are so few people there with me.