Apply Agile Values and Principles at Your Team and Company
Why even focus on values and principles? Why isn't there a more prescriptive way to work? Isn't there some magic formula for development, design, business, product, marketing, sales, devops, data, customer experience and others to work together?
The reason to focus on an agile mindset is complexity. In a complex system, the behavior of parts isn't easily (or at all) predictable. In software development, as in many other areas in life, we can't know in advance what will work. Thus, experienced software developers got together and thought of a better way to work with business to create valuable products. They practiced different ways for years, and got to a place where they could phrase it and define it.
Thus, In 2001, the Agile Manifesto's 4 values, and 12 principles were formed. Agile, as a practice of software development, focuses on delivering value, early and often. It isn't a prescriptive set of rules, but an overall guide for creating valuable products.
When you are building something in a complex, and complicated environment, with high competition, uncertainty of approach and many other variables - which characterizes software development in an ever-changing world, Agile practices are the 1st step towards making that achievable.
That's why I am providing Agile Coaching and Agile Management Training (Management 3.0) (to come in the future) to individuals and groups. It's the key to building better products, in a better way.
The Agile manifesto itself is cleverly simple and forms the basis of a very clear-cut methodology that's guiding the hands of development teams across the world.
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
You can learn see the original Agile manifesto here
The caveat is this: the Agile manifesto was written by software development leaders. To reach an overall agility as an organization, we must shift the mindset of many other roles: marketing, sales, business, for example. There are ways to achieve it, but by limiting agility only to software developers, we'll eventually face a strong gravitational pull towards a more "command-and-control" style of building software to achieve business goals. We will discuss how to spread this mindset.
12 Agile Principles
Elaborating on the Agile Manifesto
If the 4 statements of the manifesto are the guiding light, the simplest way to create heuristics, rules of thumb, for Agile Software Development, then the principles elaborate and provide concrete examples. Worth noting, they are prescriptive, not descriptive, as in "they provide guidance, not answer every question". This is the desire of software developers, put into words, of their ideas on how best to develop software. Are they the "end all, be all"? No. But if you find yourself following all of them, or none of them, it makes it much easier to say "we're agile" or "we're not agile".
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
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.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
With COVID19, the switch to initially remote working conditions (and now hybrid), things like "face-to-face conversation" don't have to mean physical interactions, but the overall importance of following these principles was highlighted by the pandemic. If you weren't interacting with your developers, as a business leader, or if you didn't create a "mental" environment of safety, then remote work might have caused issues for your company. Self-organizing teams should know to adjust to such conditions as 100% remote work. Micro-managed teams rely on a single bottleneck (their manager/team lead/etc.) to tell them what do to for each scenario.