Agile Is Not Enough

I applaud the author's perspective on agile.  I would simply add that agile inevitably is more effective when all employees are treated as trusted partners, and they have a clear common goal.  

As of the talent management in IT, it is clearly essential to move the digital/technical team closer to the business, while meantime to move the business team closer to be more digital/technical. If we can find a way to move both team toward each other, then we are creating an environment to enable digital transformation of the organization. 

And the question then will be: what would be the nest way an organization shall be doing this: move digital team? move business team? or hire someone with the desired capability from outside?

This is actually a pretty pedantic explanation of the obvious, but when it comes from 'thought leaders' at a famous institution it gains a great traction with executive management that a senior engineer with 35 years experience does not have.

If you want to know what is going wrong with doctors talk to nurses.

If you want to know what is going wrong in IT ask your own engineers with decades of experience.

Sadly we live in an age where telling the truth at work may get you fired. So instead it all gets couched in the must recent buzzword soup that is usually qualified with weasel words.

Sorry boys, I call it like I see it.

Talent is at the core of the digital technology operating model, and Agile is powerful, but it is not enough(QC)  and who has accountability(FeedBack) when things go wrong(UCL and LCL ).

I agree that this article is a good read, especially in highlighting that Agile methods applied to isolated projects or with short-term goals will not get optimal results.  My reaction to the contractor comments are similar to those above.  I have seen where employees and contractors are indistinguishable from an ownership/accountability and innovation standpoint.  A good partner that brings good people to your company will deliver exceptional results.  Job performance is no longer related to some loyalty to an employer. We are much more savvy now.  Loyalty and job performance are "earned every day" through meaningful work, clear goals, mutual benefits and supportive leadership.

In my experience, the root of problems with Contractors come in three styles:
1.  Poor definition of what is expected of the contractor/supplier - a transaction based contract will optimize to the minimum viable service level.  This is only OK if you don't value the service provided (e.g., paper delivery for copiers).
2.  Purchasing terms and pricing carrying too much weight in decision making - going for the low-cost provider can easily lead to cutting corners on ownership, quality and innovation.  If you can't figure out how the price is so good, be wary.
3.  Fragmented Supplier/Contractor Landscape - using more than a few suppliers as interchangeable "cogs" in your machine creates a lot of churn in personnel, accountability and creates extra burden on the supervising employee, as the article states.  If you put a bunch of different, competing suppliers on your project without a rock-solid delivery structure, then YOU are the "zookeeper" and all of the hand-offs and churn are yours to manage.

Success comes with suppliers in the same way that it comes form employees.  Leaders must create a trust-based, goal oriented relationship where performance is rewarded and mutual growth, innovation and learning together are valued.

*Full disclosure -- I am a contractor that has worked for the same handful of companies for more than 20 years in mostly "badge-less" environments.  We strive for at least as much ownership and value as our client counterparts.

Hi Scott, I thought I recognized your name, we worked for the same company in 2009-2013.

On your comment above I think the difference is, this article is talking about out sourcing as a body shop activity rather than a true partnership, if you chose your partners right then you do indeed both grow from the positive experience.

While I wholeheartedly agree with much of what’s written here, there's one argument that misses the mark based on my experience leading digital product delivery teams at product and services companies.  The argument is that those who rely on external vendors are worse for it in the long run.  This can be true if you don't know what to look for in a partner.  For many of our clients, working with 3Pillar isn't causing technology and process atrophy, in fact, it's the opposite. We are agitating for modern practices, architectures, and techniques. There are numerous instances where working with an external partner that is committed to the craft of building great products with enduring value can be a great way to invest in your in-house teams and modernization through the process of building together.  This is a benefit that yields compound interest and goes beyond the code or design assets delivered.  This blog post delves further into why this argument is incomplete: https://www.3pillarglobal.com/insights/why-external-partners-can-be-the-best-path-to-business-agility-and-technology-modernization

Carol Ibach, you can share the article URL [ https://dev03.mitsmr.io/article/agile-is-not-enough/ ] if you'd like — blog posts are freely available and you don't need to purchase a reprint.

How can I share or get reprint

A finely written treatise on the benefits and not so obvious shortcomings of Agile.  Thank you Will and Steve.