Do we need 'industrial-strength' Agile computing?

Has Agile software development run its course? If it has, what's at the next level?

Jason Bloomberg, an IT architectural advocate, suggests that it may be time to move beyond Agile, the philosophy and set of methodologies that encourages collaborative, rapid and iterative software development between IT and business teams. In a recent Forbes post, Jason suggests that Agile isn't sufficient for the challenges of today's expanding digital organizations.

There have been organizational issues arising in Agile implementations (actually manifested as Scrum or Extreme Programming). "Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize," says Jason. He cites the walls Agile has run up against in practice within enterprises:

Difficulty in promoting business participation: There has long been a reluctance on the part of business stakeholders to get immersed in the process. Perhaps there's a continuing perception that software development is outside the scope of day-to-day responsibilities, or isn't a part of formal job descriptions. "Stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role," Jason says.

Lack of focus on software architecture: Agile engagements tend to occur as "one-off software projects as opposed to building reusable code," he observes. While there has been plenty of talk in recent years about the "industrialization" of software, much of the work still tends to be artisan in nature.

Silos: Yes, Agile is supposed to open up the development process, but it may have had the opposite effect. Many Agile projects have tended to reinforce the notion "that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort."

What's next after Agile? What does it take to move to the next level, a form of collaborative, rapid and iterative software development that scales well in enterprises? This is a great uncertainty,. but Jason looks at the possibilities:

Lean: Lean IT, which borrows from the Lean philosophy that revived the manufacturing sector, emphasizes producing things faster, cheaper and better in a continuous way. There is a strong overlap between Lean and Agile, particularly its emphasis on collaboration.

DevOps: DevOps, which also has roots in the manufacturing side, aligns product designers and creators with production teams, which often work at different paces and have different agendas. This is important in an era when software needs to be turned around in rapid order. But there are actually more Lean principles behind DevOps than Agile, Jason notes.

It appears if anything, there is a convergence occurring between Agile, Lean and DevOps practices. If this is indeed taking place, it points to an increasing industrialization of Agile. A perusal of the Agile Manifesto suggests an informality and craftsmanship in software development that may need to be elevated to mass-production levels, as required in many of today's hectic enterprise shops.

All of the Agile principles are important, and these are resonating well beyond the software development profession. In any business situation, such as graphic design, content preparation, architecture, engineering, construction, healthcare and even accounting, Agile is a superior way to get things accomplished. The manifesto was created in 2001, but it provides great advice for coping with the workplace challenges of 2016. Many companies claim to be practicing Agile, but how many are actually living up to these principles?

• "Individuals and interactions over processes and tools."
• "Customer collaboration over contract negotiation."
• "Responding to change over following a plan."
• "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
• "Business people and developers must work together daily throughout the project."
• "Build projects around motivated individuals.Give them the environment and support they need,and trust them to get the job done."
• "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
• "Simplicity--the art of maximizing the amount of work not done--is essential."

It's worth mentioning there is a similar set of values and principles for Service Orientation, formulated and published in 2009.

(Disclosure: I am also a contributor to Forbes, mentioned in this post.)