Why should not Scrum be the first “agile thing” to read about ?
If you are new in the agile world you might be thinking: What should I start studying: Scrum, Kanban, SAFe, LESS, the Agile Manifesto, XP(…) ?
This is an interesting question I often hear. It is hard to assume an one-fits-all-answer and support speeches like: “This is the correct path to master Agile, there is no other”. If you are the kind of person that has an unique answer, this text might not be useful to you. However, if you just started working with agile teams, within a company that is in the middle of an Agile transformation and, in someway, are struggling to make it happen the way Scrum promised you, I invite you to take a few minutes to read this.
— — —
As Agile Coaches, Agile Consultants, Agile Specialists we have a big responsibility for being the reference to people who are not familiar with the agile world (yet), especially when the company is going throw an agile transformation. Almost every week you are asked for some tips about Agile training, workshops or anything that might help them to clarify this “new world”. Unfortunately, the framework Scrum was so (commercially) strong at the beginning that it is commonly misunderstood as being the same as Agile. In other words, much people think that Agile and Scrum are synonymous expressions and therefore get frustrated when their questions remain unanswered.
Agile is a philosophy based on principles and values which is much much bigger than Scrum, by the way scrum is a framework like many others. I am not saying that Scrum is bad, actually what matters is how we apply it in real world. I’ll give you three real examples that happened to me during this Agile transformation experience that I was leading alongside 2 colleagues:
1- An UX specialist (Bob) that works inside a Scrum team came to me and asked for some advice about his career’s next steps.
2- A project manager (Terry), that suddenly found he would be part of a Scrum Team in the next months;
3- A project manager (Jonas) that managed 2 dev teams and will get one more team, all three working at the same product.
The first things that I asked them were:
- “What do you like to do? ”
- “What are you good at?”
- “What do you expect to do after this transition?”
Bob likes strategic design, thinking about the product’s strategy/roadmap, researching and being a team leader. He also mentioned that his goal is to have a more important role, with more responsibility and that pays better.
Terry, that will facilitate Scrum teams soon, he likes to manage projects and people and he was good at taking control of the situation, managing and show metrics/indicators about the project, people management and executive reports.
And finally, Jonas who knows a lot about the product, have high influence over the stakeholders and business owners, he is able to accept developed user stories, as well as owning many project manager skills like budgeting, scheduling, risk management etc.
Now, let’s think about the context that we were at: Huge, hierarchical and political company, in the middle of an Agile (at Scale) transformation, with many scrum teams (despite of some Scrum principles don’t be respected), project and functional managers and strong silos. In addition, the department of Corporate Governance allowed just two kinds of project: traditional and Agile. If a project was classified as Agile, a Scrum team will develop the solution.
If we think about it, the simplest answers to those three would be: Bob and Jonas would have to take a PO(Product Owner) certification, and Terry an SM (Scrum Master) certification.
I could answer this, but remember that Agile is not (just) about Scrum, these 3 distinct situations are not so simple as it seems. If I oriented them to look for information just at the Scrum literature, I would have contributed in creating limited persons , often seen around many companies. PO focusing on writing user stories, SM complaining about external impediments… People pretending to do Scrum, or striving to do it in a context that might not make sense.
Let me tell you some concepts that Scrum will not show you:
- The world has changed, most of the work today is what we call “knowledge work”, and not “operational work”. And when it occurs, extrinsic motivators (bonus, good salaries, gifts) are not the best ones to really motivate people at work.
- We are in a complex environment and the successful practices that you applied in the last team might not work anymore inside your current context;
- There are much more in product management literature than the 2-day classes of PO certification;
- The so-called “Business Value” can be so complex and relative that there are books talking about it. Costumer or user value, shareholder value, cash flows, ROI, security needs, business strategy may be part of the formula;
- Scrum masters usually discover that the organization itself is the impediment and by showing some flow metrics (kanban) can help them to overcome this situation;
- When you try to solve a problem in a living system (a team, the entire organization…) it is important to know if it is an efficiency or efficacy kind of problem, because the solutions can be conflicted themselves;
- A system can evolve no faster than its slowest integration point. For example: a software delivery process contains many steps and integration points between them. If you optimize your team’s development process (which is one of the steps) it might have little or none impact on the effectiveness of the end-to-end delivery process.
(In most of the cases that are listed above, every leader should read about them and be aware of the complexity of today’s environments)
I’m sorry if I may be confusing you, but it is really not simple. I promise you that Bob, Terry and Jonas understood me and made some important decisions on their professional careers. And I am not going to tell you what did I told them because there is no receipt, it won’t fit to everyone who is reading this. Everybody has a different context, always!
During an agile meetup here in Porto, the speaker was talking about frameworks being the starting and not the destination point. I disagree because the starting point must be your context. If you start with Scrum, SAFe, LESS or any other framework you (and the company) will have to deal with 2 set of problems: one that you already have and the new ones that will come from trying to run the new framework.
I want you to take all this information into consideration the next time that you think about getting a new certification, or talking to your colleges and managers about next steps, participate in agile communities and meetups. Let’s spread this message around the world to promote this critical awareness of how we deal with the world of today.
Note: This text includes concepts like Systems Thinking, Complex Adaptive Systems, Queuing Theory which will be developed in the following posts. I purposely omitted them for easier reading.