This is a question that some project and program managers ask often-times! Not just probing its verbatim meaning, but for its real-life significance and value. Is Agile framework specific for software or it can also be used in other types of projects like hardware and construction?
Let’s first recall Agile Manifesto posted on the “Agilemanifesto” website that I have also included at the end of this entry. Even though we all have heard about Agile framework’s rapid / sustainable development, customer-driven, lightweight, competitive advantage, iterative, yet simplicity approaches towards development, I would like to add a few more points! Scrum however, is a special implementation of Agile as short sprints (of actions) to iteratively define-implement-test work cycles or time-boxed team efforts. One thing most people agree is that sprints have deliverables that might not be the end-product! I know many experienced managers who have used Agile in completely nontechnical environments such as hydroelectric smart meter implementations, change management, medical device hardware sub-systems, and other related projects. They all claim they promptly create their teams, make lists (of requirements, etc.), prioritize the action items, flow their planned efforts collaboratively, produce planned deliverables, and iteratively handle next sprint in their list.
However and beyond regular philosophies and proven practical norms, Agile method of managing is more like a mindset to me than the process itself. Many scholars have dug up how human aspects impressedAgile framework, how behavioral-based project management applies to successful delivery, how to improve organizational success Agile-way, and how VUCA is used in emerging ideas of strategic leadership development, even at times of change . We can easily quote the adoption information curve when referring to the adoption of technology and ideas by a population. But when it comes to Agile change adoption, we mostly address the indirect changes (process) rather than understanding the human nature, resistance to change, improved substitutes, and continuous improvements!
I think besides the technique, Agile addresses the mind-set of how to collaboratively achieve a task (or a project) in a flat level among team members where everyone (from customers, to product owners, managers, developers, and implementers) work towards common goals in an iterative progression. Agile is more like conviction to the concept of the crowd (or scrum team) working towards continuous achievements! In this practice all players shall commit to the crowd strength, in a coordinated and collaborative manner.
As per the nature of its applicability, I have seen managers who successfully applied Agile process to technical and nontechnical projects, as well as pure hardware and even construction based projects. We all have heard about “Water-Scrum-Fall” where experienced leaders merge two distinct frameworks to plan, execute, and produce their needed result in a hybrid way.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’ competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.