organization - Agile and Scrum Blog

Positions and Career Path in Agile Organization

Considering the shift from siloed based departments with subject matter experts focusing on their specialization in traditional organizations to more general cross-functional teams where members combine different skills to maximize the value in agile organizations, there is a trend to generalize positions and flatten the career path as the hierarchy got less important. Agile organizations are moving from fixed detailed positions to t-shaped skill positions or even no-positions at all, with emergent roles depending on the actual need. They abandon the skills based positions and creating a competence based model where employees are deciding what is their journey going to be. We optimize for flexibility and career mobility. The reason for such shift is again dealing with VUCA challenges as the world becomes too volatile, uncertain, complex, and ambiguous for pre-defined skilled based roles. Agile organizations need flexibility. They need to react fast on any changes in the business environment, are there new competitors offering different value, are there new technologies emerging, are there new challenges in the market, those are just a few questions you can ask. But there is no doubt that the world is not the same anymore. To deal with changes and support the people growth, Agile organizations invest in developing coaching and mentoring programs, and encouraging the internal workshops led by employees where they teach each other.

From my experience, from organizational design perspective, the hardest to imagine is the flat structure where leadership is emergent, and no fixed positions even exists. People are developing roles for themselves based on the current situation and needs, teams are forming around business challenges and adjourning once the challenge is solved. It’s a liquid structure. Very flexible, and very purpose driven. It’s one of those things you need to experience to be able to believe in it. And that’s a chicken – egg problem. What helped me was the experience from our Scrum teams, where I could see how self-organization works at the team level. And then applying it to large ecosystem was simply just using the same skills I was used to apply at the team level. In such environment where people take over the ownership and responsibility for doing their best to maximize the value and achieve the purpose, the detailed positions become irrelevant as teams are cross-functional and individuals t-shaped skilled. Then you can freely remove them, as they are not needed anymore. Quite straightforward. The culture and mindset goes first, the practices will follow.

Now if my last paragraph was way too far for you, the first small step you can start with even in very traditional environment is to shift from managing individuals to team collaboration. The more they collaborate, they develop the T-shaped skills for each individual. It still doesn’t mean that every single person can do everything the same way as anybody else, but they can actually help each other, they can review and test each other’s work, and they understand the whole little by little. T-shirt are not taking too much effort and are creating a ground for forming cross-functional teams. Once you have a cross-functional team, as first step, you can shift from skill-based roles which are not applicable anymore – like tester, software developer, UX designer, business analyst, etc. to general roles – i.e. team member, engineer or as Scrum call is ‘developer’ (note in Scrum we don’t mean ‘software developer’ but ‘product developer’).

It’s not that hard. Collaboration is fun and t-shaped skills are going really fast. On that journey, detailed positions becomes very soon redundant, and soon after, the career path will reflect the dynamics of the organizational design. People in such organizations are not motivated by given career ladder. They care about their opportunity for growth and personal development.

Agile Leader

Over the last two decades, agile shifted from software teams to organizations. We talk about different cultures, agile organization, agile leadership, agile HR, agile finance, all over business agility. Simply the ability to embrace agile values and principles at the organizational level and change the way organizations run their business. It’s a fundamental change that is more than just implementing some framework.

“Business agility creates an organization best able to serve its customer, no matter what the future brings.”

I found this definition fascinating. In today’s complex, fast-changing, and unpredictable world, agile organizations are good at responding to the nowadays challenges. Agile brings flexibility, allows you to respond to changes fast, learn through the iterations, inspect and adapt. In order to be successful, organizations need to serve its customer, no matter what the future brings. Fixed plans are failing as the business environment is not stable enough. All that matters is creativity and flexibility.

In my second English book published by Addison Wesley – The Agile Leader: Leveraging the Power of Influence I’m looking at organizational agility and focusing on the shift required from the leaders and organizations. Through practical exercises and assessments, you learn how to unleash your potential, become a better catalyst and community builder, sensibly apply transparency, improve functions from HR to finance, and guide entire organizations towards greater agility. Agility at this level is not about practices, nor frameworks. Though those are good at the beginning, as they are helpful in creating an environment with high transparency, autonomy, and collaboration, the real impact we need to create goes way beyond that. Creating a culture that supports innovations and creative solutions is a pre-requisite for real organizational change.

So how does agile start at the organizational level? You can say it starts with a management decision or training, but I would say it all starts with a dream. Is that dream strong enough to leverage the discomfort caused by changing the way we work? Is it strong enough for you? Or let me ask you this: If you won a lottery, would you be still going to work trying to make it happen? Or would you better give up and take a rest? And I’m not speaking about having a vacation to relax for a while, but is the vision important enough for you to hang around even if you don’t need to get paid? No change is smooth and agile brings a fundamental shift of values and culture, so you better have a strong reason for the change.

Being an agile leader is a journey. It always starts with you. You need to change first, the others will follow. Agile leaders need to have a vision that will motivate people to join their effort and work together to achieve it. They need to create a collaborative environment, with high trust, and transparency where the feedback is natural. They need to motivate people by giving them purpose, autonomy, and a learning environment.

Agile Transformation Metrics

It’s very common that people ask me how they shall measure the success of their Agile transformation. It’s a hard question because there is no meaningful metrics unless you know why you decided to start the agile transformation at the first place at all. Agile is not your goal, it’s just a way how to achieve some of your more strategic goals i.e. address complexity better, be more change responsive, shorten time to market, be more flexible, … And once you know why you are starting your agile journey, then those reasons are exactly the metrics you are going to measure at the organizational level. All are business-oriented and value-driven (outcome), so there is no velocity, no story points as those are focusing on output.

If you want to have a fast culture check on how far you have moved towards the agile mindset, you may look into how many experiments the teams are running, what are their actions from the retrospectives, and how they help them to deliver more value, how likely your teams take failure as learning vs. blaming opportunity, how close are they to customers, and how they collaborate vs. work individually or in silos. As a follow-up, you can have a look to your positions (are they rather broad supporting cross-functional teams than detail task-oriented), recruiting (are we hiring for approach and personality over the hard skills), performance review (team-oriented based on peer feedback over the individual), goals and objectives (team-based focused on purpose and outcome over tactical and individual KPIs focused on output), … and I can continue.

Looking to technical practices, you can check how your software teams implemented Extreme Programming practices i.e. Continuous Integration (even one-minute old code is old code), TDD – Test Driven Development (and overall attest automation), if they use pair programming or mob-programming to collaborate, having strong Definition of Done, focusing on one story at a time, and are ready for Continuous Delivery.

All over Agile is about team collaboration, customer-centered value-driven way of working, and short feedback loops. The rest are just practices, processes, and tools which might support your journey or not. The most important is not what exactly you are measuring, but what you are going to change based on that metric. If the metrics is helping you to improve and change your way of working, it’s a good metric. Measuring something just so you have it, or so you can draw a chart is a waste of your time.

Scaling Success

Companies are not scaling Agile or Scrum, they are scaling success. At our agile journey, we were often wondering how to start, what practices, tools, and processes shall we use. What I learned on my journey is that we don’t need another method. None of these are silver bullets anyway. They are all great for the beginning to change the way you work and to change the mindset. But the most important part of your journey is success. Can you share a success story? Using your own language, describing how your own environment changed, showing the impact the different ways of working created? If yes, people start picking up and trying to achieve a similar impact. The most successful agile transformations I’ve seen started exactly like it. With a small team experimenting with practices, and sharing the impact with others and depending on the starting point, sharing the various different success stories, i.e. 5 times less bugs reported by customers, 3 times more value delivered by the given time (which is not the same as more functionality but quite the opposite), significantly faster time to market, higher motivation and engagement score, more innovations which result in higher customer satisfaction, … the impact varies depending on the environment. For us a few years back it was higher flexibility, faster learning, and higher customer satisfaction.

Sharing success is not anything new in change management. It’s one of the Eight steps for successful change by John Kotter which for some reason are still not widely known in an agile community, so I thought I remind you about them here:

Create a sense of urgency – Unless you know why you are changing the way you work (to be more agile, Scrum, or Kanban), then don’t do it. Neither Agile, Scrum, or Kanban is your goal. They are just ‘walking sticks’ helping you on your journey to success. You need to have a higher purpose defined which will be stronger than their individual goals and therefore unify people.
Build a guiding coalition – You can never change the organization alone. You need to find supporters (agile enthusiasts in this case) who will create a team that will help you change the system. So, at the minimum two additional people who are true agile believers, as three are the smallest team possible. The rest will join you in seeing the results.
Form a strategic vision & initiatives – Sometimes having a purpose is not enough as people don’t see a way how to get there and the whole change is too abstract. That’s a space where frameworks, methods, and practices are useful.
Enlist a volunteer army – Finally, it’s a time to make it bigger. Make it a movement, not just another project. Get buy-in from larger crowds. Get them involved. Again, if you skip some of the previous steps, there is no way it’s going to scale.
Enable action by removing barriers – Now, once you have the energy by your side, you need to help it and remove barriers (hierarchy, silos, detailed positions, individual KPIs, … ), otherwise, all the initial enthusiasm is gone before you realize it.
Generate short-term wins – Show the success early and often, make it visible to everyone. Share stories talk about improvements, celebrate even small steps. Success is a strong engine for change. Accelerate, multiply success. Without it, any change will die.
Sustain acceleration – You can celebrate, but you can’t stop pushing after the first win, being too satisfied with your progress. There is always a better way. Find another challenge, discover a better way of working until the vision of the new way of working defined by the original purpose becomes true.
Institute change – Finally by creating connections between the new way of working and success you keep the change stick. It’s the final glue that prevents the environment from flowing back to the old way of working again.

Agile is a change, and without driving it as a change you can hardly be successful. So don’t forget the define how success looks like, celebrate it, and make it better over time.

Hierarchy

I recently posted a quote from a conference saying that “Removing hierarchy and cross-team dependencies made space for strong collaborative teams.” Interestingly, I got many comments and questions about it. So let’s talk about hierarchy and why we don’t need it in Agile space.

But before we dive deeper… What is the hierarchy? – using dictionary definition: “Noun – a system in which members of an organization or society are ranked according to relative status or authority.”

Traditional Organizations Need Hierarchy

Organizations where employees are ‘ranked according to relative status or authority’ is what we inherited from the traditional organizational paradigm which is built on top of the belief that hierarchy is the key – every organization needs to have an org chart, we have to have a clear line of reporting and decision making. And I’m not saying it’s wrong, you can keep all the traditional practices like a career path, positions, performance reviews, KPIs, etc. however such organizational design is not what I’m interested in and has nothing to do with ‘being agile’. Traditional organizations might be still well functioning, applying some frameworks and ‘do agile’, but the mindset at the organizational level is just not there yet.

Agile Organizations Are Flat

What I’m interested in is applying an agile mindset at the organizational level. Help not only individuals to ‘be agile’, but the organization as well. Agile is fundamentally changing the way organizations operate. Agile organizations are built on a new paradigm. They have a team as the key building block and are forming collaborative, creative, and adaptive networks from them. In a team, we don’t have status, and we have no ranking either. All team members are peers, with no positional hierarchy and power. Indeed, you can gain respect from the other team members in a team, but you can also lose it if you don’t bring value to the people around you anymore. It’s flexible and dynamic. All you need is radical transparency, peer feedback, and honest culture with implicit trust. You might say it’s a lot, and I’m far from saying it’s easy. However, once you experience it, you never want back to the traditional world.

Who decides on the process? Teams. In a flat organization, they are not only self-organized, but self-managed (so they are responsible for the processes), self-designing (so they are designing teams), and self-governing (so they are setting overall direction). To get more insights on those terms, see how LeSS defines them. All over, you don’t need much more than what I already mentioned – transparency, feedback, and trust. If that’s too abstract, you can get inspired by Sociocracy 3.0. It will give you more ideas on how to get there.

Who set’s the goals and objectives? No one. They are co-created by the teams, reviewed through radical transparency, and inspected and adapted via frequent feedback to flexibly address the business challenges. At the end of the day, fixed goals are useless in the VUCA world. VUCA stands for volatility, uncertainty, complexity, and ambiguity. In other words, we speak about the world which is not predictable anymore. The cascading goals neither unify nor motivate. The more decentralized and autonomous the organizations are, the higher need is there for a strong evolutionary purpose. Co-created and owned by all. Transparent. You can get inspired by Frederic Laloux’s work.

What about budgets? Who says we need to have a budget in the first place. Again, you don’t need much more than what I already mentioned – transparency, feedback, and trust. Make all the finances transparent, and use instant peer feedback to review it. If that is too radical, you can get inspired by Beyond Budgeting.

All over, I guess you got the pattern. In an agile flat organization, we don’t need most of the traditional practices. All we need is radical transparency, peer feedback, and honest culture with implicit trust. No one is saying that you have to turn your organization into a flat structure and an agile mindset. But if you want to do that, be ready to redesign the way you work entirely.

Do we need CEO in Agile Organization?

Agile at the organizational level changes everything. I wrote here already about Agile HR, Agile Board of Directors, and Agile at the Executive Team Level. Let’s have a look at the top of the organization. Should it remain the same? Or shall we go one step further and change it as well?

Searching for an “agile mindset CEO” is frankly a nightmare. Everyone who tried it can confirm that. There are not many CEOs with enough Agile experience yet in the world and those few who has it are not likely looking for a job as they are usually quite happy in their current organization. So, no matter which executive search firm you choose, or what you write to the position description, the search firms are no real help here. Unless you already spent effort up front on growing the talent internally, you need huge luck to get someone who understands agile more than a basic theory. No matter how desperate you are searching for a CEO, this is still just a small obstacle, not the real reason for a structural change.

The real need for top-level change starts when most of the organization is having an agile mindset. The Agile transformation is about being agile. How many times you’ve heard this request: “How about if our management give us more support on your Agile journey?”, “How about if our executive team is Agile and don’t just push it to us?”, “How about if they practice the same way we work as well?”Would that make it a difference? Maybe. So why don’t we go one more step ahead and change from the top and become a role model for the entire organization? As the organization has changed and Agile is not solely the domain of the IT anymore, but the business agility got into every department, the need for a change at the top level is inevitable. Why do we need a CEO in the first place? Just because that’s how organizations always been? Shouldn’t we ‘eat our own lunch’ and change the way we work entirely? Shouldn’t we apply the same principles the team do? Sounds simple, right.

And as usually it is simple to understand, hard to do as it needs courage. Courage to say “We are going to be different.” We will have Organizational ScrumMaster and Organizational Product Owner instead of a CEO because it will be closer to the way we work at this organization, fits our values, and last but not least we believe it will help us to be more flexible and adaptive at the organizational level. And that’s worth of trying.

The Organizational ScrumMaster would be focusing on the right culture, mindset and structure, so we become high-performing innovative organizations which embraced agility, and Organizational Product Owner would be focusing externally to the business, vision a purpose to we know where are we heading and why and are value driven. Both roles need to respect each other and be open with each other, the same way as it is in a single Scrum team, as together they will be part of the Organizational Leadership Team, and the network structure of self-organizational teams. There are two roles in Scrum by a reason instead of one. When you ask people if they would suggest to combine them, no one feels it is a good idea. And at the top organizational level, we would still do it? The similar reasons are valid at this level as well. When you think about it, it fits the way we work much better, then a single CEO – supports the right organizational mindset, transparency, and collaboration, it is consistent with who we are.

From a legal perspective, it is perfectly possible, and it’s not that much work either. You might need to change the bylaws a little, but there is no reason why you can’t do it. From a hiring perspective, it’s much simpler, as you are not looking for that ‘superhero’ personality who would be great with both internal and external sides. Try it. As I said already, all you need is courage. And that’s one of the Scrum values anyway. Experiment, and from that stage inspect and adapt. Now, do I believe that this SM-CEO or PO-CEO will eventually make themselves out of job? No, I don’t. It’s the same as the team level. Even if the team is self-organized and knows the business well, there is still work for ScrumMaster and Product Owner. Similarly, at the organizational level, there is still a need for Organizational ScrumMaster and Organizational Product Owner even when the network of collaborative teams got self-organized, business value-driven, and customer-centric. The Organizational ScrumMaster and Organizational Product Owner would use Leader – Leader style to build other leaders around them, and if they are successful, the organization will become purpose driven where leadership will be emergent and structure liquid. The same way as it is in the Scrum team, the Organizational ScrumMaster and Organizational Product Owner will move from those who explain, tell and share, to those who coach, facilitate, and keep the system spinning. And that’s what is the Agile Leadership about.

Difference between manager and leader

Leader and manager, what is the difference? Is there any? People are often mixing these terms up so let’s make it more clear.

Firstly, managers shall be leaders. That’s where the confusion is most likely coming from. But leaders are not just managers, leader is not a position, anyone can be a leader. In an Agile organization where hierarchy is becoming less important, we take more focus on leadership than management. There is no authority given to a leader. They gain it by their actions and behaviors and by their service to the people around them. Leaders could be anywhere in your organization and their power grows by respect of others. Managers, on the other hand, are often associated with decision making, and certain power which must be given to them.

Leaders are key to any Agile organization. The more leadership is in the organization, the more likely the mindset will change and the Agile transformation will become successful.

“Leaders need to change first. The organization will follow. “

Don’t wait for anyone, you are the leader you can change today. Agile is not about practices, rules, or processes. Agile is about the different way of thinking, different way of approaching things, different mindset. And it’s all in your hands. You are the leader.

Emerging Trends in Agile

The world is changing in cycles, fashion goes in cycles, and the same is true for Agile. What was trendy yesterday, is not today and it can change surprisingly fast 🙂 So let’s have a look what are the new trends in Agile and what the Agile community is talking about:

Agile Leadership and Agile Organization

Agile is not just a set of practices how to write a good software, but it’s more and more used in every part of the organization. The traditional leadership (leader-follower model) is no longer acceptable in Agile environments. In the previous years, almost everybody focused on teams and how to adopt Agile, Scrum, and Kanban to the teams. But if we want to be successful at the organizational level, this is not enough. We need to push boundaries and help the whole organization to change. Hand in hand with that, we need to grow Agile leaders and support Agile leadership which is the critical key to the organizational success with Agile.

Agile out of IT

As it was already mentioned, for real success, it’s important to change the whole organization into Agile. The common practice is to change IT department and leave it as isolated island inside the traditional organization. But this is just the beginning. The company has to follow the same culture and the same style of the working, so you hear more and more about Agile in HR and talent management, Agile finances, Agile marketing etc.

Business Agility

Finally, there is a term of Business Agility which brings back the real value of Agile. Agile was never meant to be development process of your IT. It was supposed to be business value driven. It should bring the startup mindset back to the organizations, and look at the delivery from a business perspective. Prioritize, deliver value in short cycles, get feedback, measure impact. This is the real Agile mindset.

If you are in Agile or do you plan to try and implement it focus on these topics because without it Agile become only an empty skeleton of practices and processes. Agile is organizational change, it changes the mindset, culture, leadership, and business focus. If you take it as such change, you are going to be successful with Agile.

Undone Organization

Agile and Scrum transformation is not any easy and it takes time. For a big organization, such time can easily be counted in years. During those years you would be dealing with so-called undone organization. Scrum itself only knows three roles – ScrumMaster, Product Owner, and Development Team. That’s all we need to deliver value to the customer. The other roles are ultimately not needed.

However, at the beginning of our journey, the undone organization might be bigger than the Scrum part of our organization. As our Definition of Done is extending, the teams are getting more and more cross-functional, we are able to embrace those people and make them part of the team. The more the team extends its cross-functionality, the closer we get to the production quality and real-time feedback.

For example Architect and UX people are often at the beginning of the Scrum journey outside of the team but as the team is getting better and learn, teams are able to take it over and make it part of the Definition of Done and separate Architect and UX roles disappear and people move into teams. At first, it sounds unrealistic but in some time this is exactly what needs to happen in order to optimize for fast value delivery and feedback.

Tag: organization