agile - Agile and Scrum Blog

Toxic environments

Building a great team is not that simple as it may look. Sometimes you are lucky and the team just forms without any effort, sometimes you are not and all you get is the group of individuals and all the effort forming a one unifying goal are failing. In such case, you may have a look at how toxic is the team environment. ORSC – Organizational Relationship and System Coaching describes four toxins (Blaming, Defensiveness, Contempt, and Stonewalling) as they are present in every environment. The same as any other toxins, if you only have a little of them in your environment, everything is fine, but they can be very culture and team destroying if they become common. So how do we deal with them? The good reply to those toxins is positivity and curiosity.

Let’s start with positivity. Interestingly, it’s very powerful. It works as a bank account. If your account balance is high, and you got a parking ticket, you are indeed not happy about it, but after all, nothing happens. You can still go to the restaurant for a dinner and pay the checks. On the contrary, your balance is low, you might end up eating just a plain bread every day. Quite stressful situation. In the same way, if your positivity balance is high, nothing can really spoil your day. No silly comments from your colleagues, no blaming can harm you. Again, you might not be happy about it, but you would take it easy and try to see it from the different perspective. Be curious. What happened that they are blaming? Maybe they are stressed, maybe they didn’t have a good sleep, maybe they had some troubles at home. Well, maybe there is a 2% right on what they say. Maybe there is a different perspective. Let’s try to understand the reasons behind it. What is the toxin really trying to say? What is the real issue here?

Positivity is a prerequisite. Curiosity is the way to limit the impact. If you have both, it’s easy to build great teams. So how about this. Next time you see someone blaming, being defensive, using contempt, or stonewalling, instead of reacting with another toxin you try to apply your curiosity and see the situation from different perspectives. After all, there is no right or wrong in the complex systems, everyone is right, but only partially as they say in the ORSC. Look at the things from the bright side. Make positivity and curiosity your friend. Toxins will disappear.

Deadlines in Scrum

One of the topics most of the project managers and traditional organizations at the beginning of their Agile transformation journey are struggling are deadlines. How can we do Scrum and commit ourselves to the date when we don’t know the scope? Let’s make this clear. Scrum is purpose driven, not functionality driven. What does that mean? It’s not about delivery, it’s about achieving the certain outcome. And that’s a game changer. Instead of fixing the whole scope at the beginning, we spend the time to understand the purpose. Form a vision. What do we want to achieve? For whom? Where is the value? How are we going to change the world once it’s done? What makes it different?

Once you have enough mutual understanding of the business value and the vision, you are ready to continue. So, we agreed that in long-term, you need to achieve this, what about mid-term? What is the most important to achieve now? Where is the biggest risk we need to mitigate by feedback? What impact do we need to get? Once you have this release agreed, you are ready to start Sprints. Again, Sprint is not about precise functionality delivery, but achieving certain impact, deliver value and learn from that. Therefore, there is a Sprint Goal – a small vision for a Sprint, answering a question what do we need to achieve in the short-term.

Finally, none of those deliveries can actually fail. Of course, you can learn that your business idea was wrong or the value was not where you would expect it. That’s why we use Scrum, to test our hypothesis. But the nice thing is, that neither Sprint nor release can actually fail the delivery if you prioritize well because 80% business value is hidden it 20% of the functionality. If you prioritize the value, you always achieve the goals.

So next time when your customer ask when it’s going to be done, you can invite him in the conversation about the value, vision, release charters, and Sprint Goals. Don’t ask what they want, ask what they need and why. Only then you are both going to be successful with Agile.

Agile at executive team level

Agile can’t stay just at the team level. Agile transformation only creates disturbance and gap between the management and employees. And the more Agile the teams are, the bigger the disconnect is. Managers feel lost, forgotten and start to be frustrated that those self-organizing teams might eventually not need them. Part of the problem is they’ve never been part of any Agile or Scrum team themselves. They’ve seen them working, joining them for Reviews and listening to their stories, but that’s not the same. People need experience to understand a different way of work. You might still remember your first feeling, when someone told you that this Agile and Scrum will be great. “What?” you thought, this stupid process will never work – what if… At least I still remember how I felt several years back.

One important thing companies often forgot during their Agile transformation is how to get management on board. Managers deeply need their own experience with Agile and Scrum. They can’t just read about it. Otherwise you continue hear such funny remarks like “I got it, you are a team, you collaborate, but who is responsible?”, “We don’t need ScrumMasters, some developer can take it as a second role” or “We don’t need Product Owner, we have a product committee”. If you really mean the Agile transformation seriously, it’s time to change the way you implement it. It’s not just a different process decided by C-level executives and implemented without them noticing. It’s a significant change of the culture and mindset. So why don’t we start from the other side, forming the first team from executives. Let them experience Agile and Scrum. Make them feel the pain of being the group of individuals with their own goals, no common passion, no trust. Or no unifying purpose. Let them experience what the self-organization is about, how the cross-functionality works. Let them do their refinement, planning, standups, reviews, and retrospectives. It’s always fun. And the same way as such first pilot is painful and difficult for a product development team, it is even more painful for the executives. They would hate it. If they can, they would kick you out of the door. So be ready for that and have strong enough sponsor who understands that such painful experience is critical for the organizational success. It’s like any other exercise. Starting is difficult. We all are great at finding excuses why running today is just not a good idea. I will run tomorrow. Or when it’s the right weather. Actually, I don’t think I need to run, I’m just good without it. The other people need that, not me. Familiar? If you force yourself to start and develop a habit, it is fun and you would miss it if you skip that for even a day. The same with Scrum, the first time you experience the power of the true team spirit you never want to be back. No matter where you are in the company orgchart. It works the same way.

Unfortunately, executives are rarely going that way. There are two reasons. First, it is a painful journey. That’s why I’m not running every day. It’s not that bad that I would have to, right. The company is still fine. Not struggling enough. But maybe when that happens it’s too late to change. Second, most of the Agile Coaches need a day job. They care about 6+ months contracts. They are afraid of losing it if they would push too much. They often forgot that their job is not to please the customer, but to change them. Guide them through that painful experience with all the risks that they will not like it, and stop. Very often you hear from them “I know that this is not the way how it shall be but this is a corporation, you have to do it differently” so they still have PMOs, no Product Owners, weak ScrumMasters and not real teams either. It’s a much more painful experience for everyone involved then starting this fake transformation repeatedly all over again and again.

If you mean it, get a real Agile coach. Not a consultant. Find someone who would guide you how to do it. Not do it instead of you. Who would be with you once per Sprint / month / quarter. Do their intervention, show you the way where to focus next and let you exercise. Start with smaller pilots. The first Agile bubbles. The more bubbles you make, the better. Aim for our own experience and learning. Inspect and adapt. Don’t forget that your executive team forms one of the first bubbles. They have to learn in the first wave. If you do it that way, Agile mindset will grow organically and very soon you would be ready to share your own Agile success story and inspire the others.

Using tribes, squads, and gilds is not Agile by itself

Many Czech corporations are now starting their Agile journey, at least they say so. Despite fancy labels, they don’t have any desire to change so, unfortunately, you can only expect some ‘fake Agile & Scrum’ and no real outcomes nor fun. How do you recognize them? Most of them got inspired by so-called “Spotify model” (which was never supposed to be any model to follow anyway) or got it second-hand from Dutch ING. Both were just a case-studies how they work at the given time. Both case-studies have one thing in common – both organizations went through a significant change in their values, approaches, and culture. Those who only follow what they shared usually don’t get such a culture and don’t pay any attention to the mindset change either. Just re-structure departments to tribes, squads, and guilds, it’s cool, so it must be the right Agile. But unfortunately using cool labels is not enough to be successful so such organizations who blindly followed what the others wrote about in the case-studies are failing miserably in a few months.

One example from a huge corporation who applied ‘Spotify model’ – after a year of implementing it, they end up in such a mess that they had to throw away a year of the development and start from scratch again. Quite painful. And expensive. They faced the same issues as the most of such corporations. Not enough of collaboration, culture, and mindset. After all, they didn’t really want any change. They just want to mark it ‘done’. We implemented Agile, we are cool. The similar business model like SAFe (apply new process and terminology, you don’t have to change the mindset or your way of working), just in this case we don’t use any ‘trains’ which if you thought about it are out of fashion for years now, but a modern terminology of tribes, squads and guilds. Nonetheless, the result is similar. Unfortunately. One huge American corporation recently started their 13^thAgile transformation. How fascinating. The rumors say that this time they are going to make it. It seems they finally understand that Agile transformation is a journey. It’s not about new terminology, it’s not about tools, practices or processes. It’s a different way of working, a different mindset. So even if it looks like a disaster right now, don’t cry :)… another five attempts and you make it as well. You just need to be patient and wait for the right moment. After all, it’s not that hard. Just stop pretending the change is not needed, and start the real transformation. Change your mindset. Change the way you work.

Any change starts small, with a sense of urgency. Only when you have a strong enough strategic reason, you will change. Remember that Agile is not your goal, it’s only the best way how to achieve your goals in the nowadays constantly changing complex world.

Agile HR

Agile HR or if you want Talent Management as it is called nowadays turn the whole company around. It’s employees centric, delivering value to the whole organization. At a glance, not much had changed. We still need to hire people, take care of people growth, do some evaluations. Just the way we work changed significantly. So let’s go one by one to see the shift.

Hiring

Hiring process focuses not that much on skills, because skills could be learned, and will change depending on the business value priorities, and the team needs, but a person who is a good match to the company culture and the team. In an Agile organization people who can learn fast, are the starts. They can go to any cross-functional team and deliver value. We look for someone who has not a fixed mindset, is ready to change. Having said so, people are often not hired by HR and managers but the teams and the HR are only consulting and coaching teams in that process. The world of the fixed positions is over. All the recruiting agencies need to adapt as well. When we’ve been hiring, we involve team members and give them a strong voice in the process. We stopped looking for C++, Java, or C# experts, we were looking for passionate people who have energy, passionate about anything they did. We want to hear stories about what they love to do. Even if it was just a tiny thing they did over the evenings. We were transparent on how the work is going to look like, stressing the downsides, so they have clear expectations. Transparency is the key, so one of the great ideas is to invite candidates to join a team for a day. It’s like going to the date, getting to know each other better, get a sense on both sides how is it going to be.

One example of a very different interview is to ask the candidate to use a creative set of Lego bricks and visualize how it’s going to be once they joined the organization and have a conversation about the model. It’s something you rarely see in the interviews but it shows a lot about the candidates.

Evaluations

Evaluations and performance reviews changed significantly in Agile space. It’s less about reviewing, performance, and evaluation, more about development and vision of the future and growth. As the Agile organization operates internally in very short cycles, where through radical transparency and instant feedback through retrospectives the organization gets to inspect and adapt and solve any issues right away, we don’t really need classical KPIs as they are not supporting the adaptivity and flexibility Agile organizations need and missing a team aspect as well. As a first step, you can start with setting team goals, instead of individual ones. It will help. However, eventually, you need to redesign the whole concept from the scratch. The key focus is on coaching conversations, transparency, and candid feedback from your peers.

One example of a radical change you can use is the team-oriented feedback. You give each person on a team or organization (yes, it scales) a certain amount of money to give away. Let say $100, and ask them to distribute it to the colleagues. The only rule is you can’t keep it. If you think about it, the message you got by receiving $0 it’s much stronger feedback then anything your manager can ever say about your performance. Indeed, we need a lot of coaching to help people understand and handle what’s going on, but in general, that’s a good thing. If you scale this to the whole organization it’s even more fun, as the managers get such instant feedback as well as the employees.

Talent management

As I mentioned at the beginning of this article we are speaking more about talent development then HR. What motivates people? How do we grow talents? How do we support them on their journey? How can we help them to be successful? The answer is coaching, support them to create their own development goals, grow their interest, empower them, raise their awareness about themselves. Not surprising, but how many HR are taking such a support role and how many of the companies take it as process and governance role.

Example of such coaching conversation for the people growth could be using a few categories which are strategic for the organization right now to frame the conversation. Firstly, you need to make people aware of how the coaching scale works, that it’s very different from evaluation, it doesn’t have to grow quarter to quarter and that there is always a better way of doing things, and that this tool shall help them to identify their potential and find ways how they can grow to support the organization. As a next step, you let people rate themselves on a relative scale 1..10, where 1 = not good at this area, and 10 = I’m great at this. They need to be able to compare themselves with the other people around in the organization, explain how it would be, when you are 2 points above the level you are currently, what would be different once you get there, what would it mean to the organization, what is currently in their way, etc. All of those are good coaching questions. No magic. It just works like a magic 🙂

Five books every Agile leader should read before they start Agile transformation

To continue my with my book recommendations (check Five books every ScrumMaster should read and Five books every Product Owner should read), I have several books here, I would recommend every Agile Leader and manager in Agile Organization to read before they start Agile transformation. It’s a mix which will help you to understand Agile Leadership, Agile Organization, it’s structure, design, and culture and allow you to adapt to the different leadership style. Enjoy reading 🙂

Niels Pflaeging – Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization is about complexity and work – and about how to deal productively with both. A condensed introduction to the theory and practice of organizational high performance. A manifesto for contemporary leadership and profound transformation in organizations of all kinds. It is “practically theoretic”, featuring cutting-edge insight. It proposes new language and thinking for a new way of work and organizations.
Frederic Laloux – Reinventing Organizations is a must. The way we manage organizations seems increasingly out of date. Survey after survey shows that a majority of employees feel disengaged from their companies. The epidemic of organizational disillusionment goes way beyond Corporate America-teachers, doctors, and nurses are leaving their professions in record numbers because the way we run schools and hospitals kills their vocation. Government agencies and nonprofits have a noble purpose, but working for these entities often feels soulless and lifeless just the same. All these organizations suffer from power games played at the top and powerlessness at lower levels, from infighting and bureaucracy, from endless meetings and a seemingly never-ending succession of change and cost-cutting programs.
Large-Scale Scrum: More with LeSS is looking at the organizational design from a different perspective. Rather than asking, “How can we do agile at scale in our big complex organization?” a different and deeper question is, “How can we have the same simple structure that Scrum offers for the organization, and be agile at scale rather than do agile?” This profound insight is at the heart of LeSS. In Large-Scale Scrum: More with LeSS, Craig Larman and Bas Vodde have distilled over a decade of experience in large-scale LeSS adoptions towards a simpler organization that delivers more flexibility with less complexity, more value with less waste, and more purpose with less prescription.
The Responsibility Process: Unlocking Your Natural Ability to Live and Lead with Power is about FREEDOM, POWER, and CHOICE. Leadership is innate. The Responsibility Process proves it. The Responsibility Process is a natural mental pattern that helps you process thoughts about taking or avoiding responsibility. How you navigate it determines whether you are leading toward meaningful results or just marking time. This book gives you precision tools, practices, and leadership truths to navigate The Responsibility Process and lead yourself and others to freedom, power, and choice.
Leadership and Self Deceptions shows how most personal and organizational problems are the result of a little-known problem called self-deception. Through an entertaining and highly instructive story, Leadership and Self-Deception shows what self-deception is, how people get trapped in it, how it undermines personal achievement and organizational performance, and- most importantly the surprising way to solve it.

BONUS:

Finally, there is a bonus book which I wrote a few years after this blogpost 🙂 The Agile Leader: Leveraging the Power of Influence Book published in December 2020 will help you to unleash your agile leadership potential and guide your entire organization toward agility. It’s a great overview of concepts for managers, directors, executives, and entrepreneurs―anyone, regardless of position, who’s ready to take ownership, challenge the status quo, and become a true agile leader. See more at https://greatagileleader.com.

Five books every Product Owner should read

To continue my with my book recommendations (check the five books every ScrumMaster should read, and five books Agile Leader shall read), I have several books here, I would recommend every Product Owner to read. It’s a mix which will help you to understand Agile Product Ownership, Discovery and delivery process in much broader perspective. Enjoy reading 🙂

Impact Mapping: Making a big impact with software products and projects is a practical guide to impact mapping, a simple yet incredibly effective method for collaborative strategic planning that helps organizations make an impact with software. Impact mapping helps to create better plans and roadmaps that ensure alignment of business and delivery, and are easily adaptable to change. Impact mapping fits nicely into several current trends in software product management and release planning, including goal-oriented requirements engineering, frequent iterative delivery, agile and lean software methods, lean startup product development cycles, and design thinking.
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In the book, Agile Alliance co-founder Mike Cohn discusses the philosophy of the agile estimate and planning, and shows you exactly how to get the job done with real-world examples and case studies. This book is a must-have agile estimation tool for your development toolbox.
User Story Mapping: Discover the Whole Story, Build the Right Product shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features.
Innovation Games®: Creating Breakthrough Products Through Collaborative Play is a must-read for anyone involved in market research and product or service development (which, when you think about it, means virtually everyone). Innovation is incredibly simple. All you have to do is accurately predict what your customers want, need, and will pay for. Oh, wait. Sorry. That’s actually very hard. At least with traditional tools. So how do you find this information? Well, you can just ask your customers what they want. The problem, of course, is that with most truly breakthrough innovations, current and potential customers don’t actually know what they want before they see it. If you just try to deliver what they already want, you’ll never truly innovate. Even worse, traditional market research practices prove that often, customers have trouble articulating what, exactly, they want in the first place.
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses is about a new approach being adopted across the globe, changing the way companies are built and new products are launched. The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute. Rather than wasting time creating elaborate business plans, The Lean Startup offers entrepreneurs – in companies of all sizes – a way to test their vision continuously, to adapt and adjust before it’s too late.

5 reasons why to attend AgilePrague Conference 2018

#1: World-class Program
Several years in a row we managed to achieve high-quality program while keeping it affordable to the people in the Czech Republic. This year you can be looking forward to awesome speakers – for example: David Hussman, Roman Pichler, Evan Leybourn, Marsha Shenk, Yves Hanoulle and many more.

#2: Business Agility Focus
The theme for this year is Business Agility. Agile is more than an IT process. We are going to talk about Agile transformations, scaling, the new ways of running your products and businesses, Agile Leadership, collaborative culture and great teams.

#3: Coaches’ Clinic
You can discuss any area you are interested in and get free help from experienced coaches at our Coaches’ Clinic. It is a unique and free service designed to help you with specific challenges you’ve encountered on your way to a more Agile way of working.

#4: Open Space
AgilePrague Conference is not just about listening. We want you to participate and come up with your own session. Every mid-day there is an open space where you have an opportunity to share ideas, discuss topics with each other and join a deep dive conversation with our speakers. Open space is an opportunity to create your own program and bring your own topics to the conference.

#5: Visit Prague
Prague is an awesome city, so why not combine the sightseeing & conference? Have a beer, wonder though old town & narrow streets, enjoy one of the greatest historical cities 🙂

Looking forward to seeing you on Sep 10-11, 2018 at AgilePrague Conference! Register for Agile Prague 2018.

Is Agile for us?

It seems to be a very common question. In general, if you are willing to change yourself, yes. There is no bigger enemy than yourself. There is no environment, size or business restrictions. Any company can change if they find a strong enough reason for a change. However, there are few questions which can help you to identify if you are ready or not.

Agile is not for us if…

We are looking for “magic” that helps us deliver everything faster.
We want to allocate individuals on tasks based on their specialization.
We focus on a buyer-supplier relationship and customer acceptance.
We focus on specification, requirements, and change requests.
We optimize for local efficiency (individuals, component, technology).
We just want to be “modern” and copy some terminology (tribes, squads, etc.).

Agile is for us if…

We are ready to build real self-organizing stable teams.
We are ready to form real cross-functional teams.
We are ready to build a partnership with customers and looking for feedback.
We are ready to focus on fast value delivery in a working product.
We are ready to optimize for adaptiveness, flexibility and change responsiveness.
We are ready to change our way of working to achieve some strategic goals and sustain the current complex world.

The first list is grounded in a misunderstanding of what the Agile and Scrum is about and leads to “Dark Scrum”. The second implies a significant change of your approach, values, the way of work, simply the change of mindset. It’s up to you 🙂

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.