Cross-functional teams and self-organization in the heart of Agile
This series of articles is based on my speech at the Krasnodar Dev Days #2 conference.
In this part, I would like to make an overview of Agile culture’s basics. This article might be interesting for people new to Agile or those willing to take a “different angle” view on it.
You won’t find something new here if you are an active Scrum Master, Product Owner or Agile Coach, but I would like to hear and discuss your thoughts and critics in the comments. Thank you!
Agile is a Mindset
Before we get down to the cross-functional teams and self-organization, I would like to take a look at the term “Agile”.
Agile Manifesto has been published in 2001 by a group of the software development enthusiasts. It consists of 4 values and 12 principles that give a basis for the Agile Software Development approach. During these 16 years, the whole Agile community and document itself have been criticised and reviewed many times.
Here you can find some stereotypes and prejudices about Agile that are widely spread, for example in Russia where I originally come from:
Thousands of practitioners actively applying Agile Manifesto’s values and principles in these 16 years have given a birth to absolutely new business attitude and working culture. It also made possible spreading of the Agile approach outside the software development industry. Other words being used together with “Agile” nowadays are “philosophy” and “mindset”.
I myself share an “Agile is a Mindset” attitude and I’ve created my own list of principles that do not deny but expand and specify those given by Agile Manifesto. They are based on my practical experience and many best practices I read and hear about in the articles, podcasts, meet-ups and conferences. I refer Agile as a culture, based on:
- Quick hypothesis testing — it relates to both business hypothesis like some feature or product at all (MVP) and technical hypothesis. That’s why so many Google products are being released while still in Beta;
- Frequent product delivery — it doesn’t matter whether it’s DevOps-style CI/CD, increments in Scrum or some amount of “Done” tasks in Kanban — the main goal is to release updates as often as possible. It gives us a possibility to do quick hypothesis testing;
- Feedback-based approach— not only a direct feedback from a focus group or AppStore/Google Play comments but also different kinds of metrics (marketing, technical, performance, etc.). Doing product delivery frequently we create an opportunity to harvest up-to-date data;
- “A failure is an option” attitude— being able to face a failure that should be considered as “an unexpected result” allows you to deliver the imperfect product to the market. Every mistake or failure isn’t a tragedy, but a valuable experience to learn from;
- High level of self-organization — I will get back to the topic of self-organization later, but it’s important to understand that it’s also one of the basic principles of Agile;
- Transparency — both in terms of product vision/development plans and inside the development teams. Only full transparency gives the team members understanding why they do their job and what value do they add. It also helps to prevent “cold” conflicts inside the teams;
- Equality of participants — every team or company member should be able to express his personal opinion about the product, specific feature or processes. This possibility shouldn’t be limited by his grade, experience, age or role;
- Continuous Improvement — working on the continuous improvement of our products (adding features, getting rid of bugs, optimising performance) is our main goal. But teams we work in and processes that we follow also need to be improved on daily basis. (e.g. through the Retrospectives in Scrum)
That’s how we see the difference between “doing Agile” and having the Agile mindset:
Summing up we can define that Agile is a Mindset with its own philosophy and culture that is described in 4 values, defined by 12 principles of Agile Manifesto and manifested through an infinite amount of tools and practices in such Agile frameworks as Scrum, Kanban, XP, LeSS, SAFe, etc..
Kicking off your Agile journey from the blind reproduction of Scrum Guide’s or Kanban’s practices you obviously gonna get another “cargo cult” whose failures convert into another coin in the “Agile stereotypes and prejudices” piggy bank.
To be continued…
