Walk into a factory and you perceive noise, activity and movement. But walk into an organisation that works with digital information — a software development company for example — and you perceive silence, inactivity and stillness. A lot of things are happening, a lot of work is being done, but it is (almost) invisible to the naked eye.
While blueprints of physical objects can be displayed on screen and 3D printed to take in your hand, software has no single geometric representation and is very difficult to visualise. Further, software is arbitrarily complex because every component is different — if we need two identical components, we just clone the first one — and the differences are not systematic. Third, software is much easier to change compared to physical products. If a system combines both hardware and software, the software side tends to attract more changes.[1]
Since computers were invented, nothing has happened that would fundamentally make software easier to visualise, less complex, or less prone to change. This continuing lack of visibility and predictability still makes it very difficult to manage software projects. Despite well-laid plans and best practices for monitoring progress, a large proportion of software projects still fail to meet either schedule or budget. Moreover, half a century of research into project management has had little impact on software project failure rates.
Agile software development methods emerged in the 1990s when a number of people started to experiment with applying Lean principles to software development. As they shared information and learnings over the Internet, a dozen related but different methods emerged in a short time. The methods were all evolving in an empirical manner — “by doing it and helping others do it”.
The key insight of the early “agilistas” was that if our software projects are constantly faced with change and complexity, then we should design our processes to accept change rather than suppress it. In practice, processes should be based on creating transparency around what we are working on (our products and services) as well as how we are working on it (our people, processes and tools), inspecting all of this early and often, and adapting as we go. They should provide enough structure to enable people to get stuff done, but not so much that people find it difficult to use common sense.
Core thinking of Agile
The umbrella term “Agile” was first introduced with the Agile Manifesto in 2001, when the various lightweight methods were already starting to enter the mainstream. Agile is in itself an abstract concept, mainly a philosophy or a collection of thinking models based on the values and principles defined in the Agile Manifesto. Methods like Scrum and eXtreme Programming (XP) provide various practices and processes that are compatible with the agile values. Scrum provides mainly project and product management practices, while XP focuses on programming practices.
A few methods, like Scrum and XP, have gained an increasing following over the last few decades. They have been further adapted to changing circumstances and real-life experiences, and have by now become well understood and nicely packaged. A number of other methods have dried up and almost disappeared. Today Scrum is the most popular agile method, with 72 % of all agile teams using either pure Scrum or a Scrum-based hybrid method.[2]
All agile methods agree that the only real measure of progress is a working and tested product that gives value to the customers and end users. Agile methods generally try to refocus attention on outcomes rather than on the project that encapsulates the work, and on collaboration rather than contracts and specifications. As we mentioned earlier, software is invisible, complex and malleable, and therefore it must be made real (compiled) and tested early and often, and used (deployed) to elicit feedback from customers and end users.
Thus all agile methods share the following attributes:
- Incremental: Small and well-tested software releases are made early and frequently, often using automated builds and automated testing.
- Collaborative: Customers, developers and stakeholders work together with close communication, enabling distributed authority and responsibility, as well as direct and rapid feedback.
- Straightforward: The method is simple, and easy to learn and modify.
- Adaptive: The method can quickly and easily handle changes to products, processes and the organisation.
- Self-organising: The people involved own the process, and continuously adapt it to produce more customer value in less time.
The words agile, flexible and adaptive are often used as synonyms, although there are some small but important differences. An adaptive organisation is actively changing and can therefore adjust faster than a merely flexible organisation. An agile organisation goes beyond this by also being capable of driving change for the purpose of learning and creating disruption. Agile organisations constantly experiment with new products and approaches, push boundaries, apply pressure on their competitors, work smarter, and are generally capable of taking a leading role in the market.
It’s also important to notice that the Agile movement is not anti-methodology or anti-governance — it doesn’t say that we should ignore all project plans and just program away. Instead, planning is done in a different way: just in time, and to the relevant level of granularity. One could also argue that Agile methods put even more emphasis than usual on people keeping their words, following joint agreements, and finishing what they have promised to do. The main mechanisms for this include transparency, regular product inspection, joint goals and social pressure.
[1] F. P. Brooks. No silver bullet: Essence and accidents of software engineering. IEEE Computer, 1987.
[2] 13th Annual State of Agile Report. VersionOne, 2019.
RingCentral敏捷教练
不懂技术的产品经理不是好教练！
长按二维码关注