Scrum Guide Update

A few days back there was a new update to the Scrum Guide – the definition of Scrum. So what’s new? Not much, which is a good think. Most of the changes were minor, correcting, clarifying and updating the text so it’s clearer. Few interesting updates:

The trend of using Agile and Scrum out of IT was addressed explicitly:

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”

Nothing new, for us, but it can make a difference to the people new to Scrum.

I specifically like the update in the Daily Scrum section where the three questions were only made as one option. Finally, right.

“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.”

So there is a chance people stop using it as individual status meeting and use it to inspect and adapt their plan ow they are going to achieve the Sprint Goal.

The only change I don’t understand as it is to my opinion going against the philosophy of Scrum as a framework, not a process is the Sprint Backlog section:

“To ensure continuous improvement, it (Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.”

So here we are, pushing one practice which may be good for the teams who are at the beginning of their Agile journey and don’t improve as part of their DNA to everyone. I can imagine many other ways how to improve then making it part of Sprint Backlog and soften the line between delivering value and “other important tasks which need to be done”.

I like Scrum as it is not much prescriptive and I hope such weird changes will not increase as they will eventually be the end of Scrum as a flexible framework…

Make product as wide as possible

Some time ago, when I first heard the definition of LeSS (Large-Scale Scrum) product, I found it a bit unrealistic. Large-Scale Scrum is one of the Agile Scaling methods and I happen to like it as it’s very close to what I had experienced to be successful in various environments before. But the definition of the product is quite wide. Specifically – the product shall be as wide as possible, but still practical. If the customer feels it’s the same product or if it’s similar from technical perspective, it is the same product. When you start to apply this rule, in general it means that most of the companies have one product only.

Let me give you a few examples… Amazon and all its services shall be one product because that is how customers see it, the service company delivering internet solutions and mobile apps for variety of the customers is one product despite of the diversity of the customers and technology, the maintenance and the new development is one product as it is same from the technical perspective. Your projects are just Epics in your Product Backlog. When you think about it for a while it makes sense, as you need consistency in your delivered functionalities, flexibility to be business driven and ability to prioritize your business only by business value not by technical skills or domains. This is the real crossfunctionality we aim for. It’s not that difficult despite of the complexity of your product. The people who create our software are usually having university degree which shows they can learn. They are smart and creative software engineers. They can make it. If you do it this way it makes everything so much easier as dependencies at code level are much simpler than dependencies at business level.

Definition of Done

Definition of Done (DoD) is a simple thing, although people are often struggling with it. It only defines what “done” means. It brings consistency into the product delivery. It sets the bar of quality we all keep the same. People often mix it with the acceptance criteria and are confused. So let me summarize it. Definition of Done shall be the same for all Product Backlog Items, as we need consistency, we need to know which quality standards are kept.  Definition of Done is created as an agreement between Product Owner and Development Team, so it contains both technical and business quality requirements. It shall be stable for the product and not change Sprint to Sprint. Eventually, we can improve it, but we aim for consistency so we keep it stable. Definition of Done is the same for all teams who work on the Product Backlog to keep that consistency.

So how can such Definition of done look?

  • Coded
  • Tested
  • Reviewed
  • Documented
  • Running on test server
  • Accepted by Product Owner

You can make it more specific:

  • Coded according to Product Backlog Item (User Story) definition
  • Automated tests (unit, functional)
  • Reviewed (by different team member)
  • Documented (internal)
  • Running on test server
  • Accepted by Product Owner

Eventually, in some time we may improve it for example as follows:

  • Coded
  • Tested
  • Reviewed
  • Documented
  • User documentation
  • Translated to Chinese, French and German
  • Running on production
  • Contains business measures how users used it
  • Accepted by Product Owner

In this case, we achieved continuous delivery within our Sprint. We release each Backlog item to our users directly whenever it’s done. We need to translate it as a part of that otherwise we can’t be able to release. And we have to add some business measures to know if we are getting the expected impact or not and get fast feedback. As you might see, the more the organization is Agile and teams cross-functional, the wider is their Definition of Done.

Definition of Done shall be visible so everybody can see it. Never compromise. The User Story is either done or not. Any other state only brings chaos and makes any release completely unpredictable.

Are we Agile… ?

Are we already Agile? How do we know we are Agile? What level of Agility have we? It’s hard to say. On one hand, you never touch Agile as Agile is like a star on the horizon. On the other hand, you can feel it after the first 15 min you enter the organization from the energy, level of the positivity, interactions from people, and company space setup. A bit later you might search for more tangible proofs of Agility / non-Agility. But the initial sense if usually right.

It’s so hard to measure as once some authority publish the assessment questions, companies make those things happen and fake it. It will most likely not even be conscious, as people are starving for simple recipes. So such assessment can only work once in life. Here are the first seven ideas which come to my mind. If you like to answer, be honest and use the whole scale <0 .. 10>.  No organization is ideal, and so there is low chance you will be the ideal one.

I can continue, but firstly people can only answer few questions, I hope 7 is not too much and secondly, it’s just a short test which is only valid for the first time you do it, next time when we meet during my Agile coaching, I will ask a different set of random questions :). It’s not any complete assessment, just a fun test which can possibly make you think about yourself and your way of work.

If I got enough replies, I will publish them in some of the future posts.

Agile Leader Competence Map

The more the Agile Leadership is popular, people are asking for more description. Who is the Agile Leader, what makes him different from a traditional manager, and which competences and skills they have to have. So I created this Agile Leader Wheel so you can map the competences and skills.

Great Agile Leaders have four core competences in which they can create vision, enhance motivation, get feedback, and implement change. Vision is the driving engine. It’s not necessarily related to the product and business but the organization itself. The second segment is motivation. Agile Leaders understand the nature of motivation, are familiar with the power of intrinsic motivation of autonomy and purpose. The third one from the top section of Agile Leader Wheel is feedback. For Agile Organizations feedback is crucial, it makes the team and product feedback part of their DNA, it becomes integral part of their culture. The same for Agile Leaders, the regular feedback from the system is the key to their success. The last piece is ability to implement change. For Agile Leaders the change is happening at three levels. Firstly there is change of myself, my own beliefs, reactions, the way I work. Secondly there is the ability to influence others. Make them part of my team, get supports who will help me to lead the change. Finally the third element of change is change at the system level, the whole organization level.

Agile Leader Wheel

In addition to the mentioned competences, Agile leaders will need to balance the time when they need to take a decision and when it’s better to delegate and empower others to take decision and responsibility for that. Finally on the right side Agile Leaders are facilitators and coaches. We are not speaking here about one-one coaching. Great Agile Leaders use coaching as a spice to address the complexity at the system level, and coach organization as whole. Great Agile Leaders are not born this way but constantly develop those competences and skills. This concept is part of my Agile Leadership program where I help leaders to understand complexity of nowadays organizations and be successful in their roles. Looking forward to see you at some of my Agile Leadership workshops.

Traditional metrics are dead, let’s kill KPIs

Most of the people, when you ask them, admit that KPIs are not any useful at their organizations. They don’t motivate, they don’t change people’s behavior to any better way. In the best case KPIs are usually a formal metric, in the worst case a way how to punish people. In modern organizations, which are built on top of collaboration and teams, the need for individual metrics disappeared. So what can you do instead?

If you have a bit of courage, you may try this: ask all team members to distribute for example 100$. They can give it to any team member, but can’t keep it for themselves. In a very short time, you get a very honest feedback. If you ask people to give Kudos or appreciations together with that, it’s awesome. Problem of bonus distribution solved. There are companies which distribute the bonuses not only within one team, but across the whole organization. To the receptionist, CEO, sales, developer. Your choice. We make it very transparent, so the system will correct any weird behavior as exchanging bonus money within two people. In general this is more theoretical question. I haven’t seen it happen but it comes out anytime we talk about it with managers. I guess it indicates lack of trust.

Another way how to do it when your organization is more Agile is to give every month people some money to their bonus account, you can keep them of give some to the others. Each month the random person from your company rolls a dice and if there is a six, the money is yours and we start to build another jackpot. When it’s any other number, they just continue in moving money as appreciation. As no one knows when the money is going to be paid, they don’t game it.

Finally, I have to admit that I don’t believe in any money bonuses. They are not going to help with real motivation and the risk of side effect is higher than possible outcome. So I would kill not only individual KPIs but bonuses as well. You can achieve better motivation by giving people autonomy, responsibility and clear purpose. And you can help them grow with coaching. It takes more time and energy then do KPIs and bonuses, but it brings higher results.

Agile Culture

Culture is intangible. It’s hard to touch. Hard to define, hard to measure. However, it is the critical piece for the organizational success. We may debate if culture follows an organizational structure or vice versa, but I don’t think it is important. Culture reflects our values and philosophy. The way we are. Being Agile is about changing mindset. If enough people change their mindset, the culture changes and they become Agile Organization. Simple if you say it this way, but hard to do.

I’ve been looking for a good definition of culture for years. I surprisingly find it at CAL (Certified Agile Leadership) training which I attend from Michael Sahota in California. I very much like his way of describing culture, and I used it as an inspiration for my drawing.

Agile CultureThe culture consists of two parts. The mindset and structure. I’ve always seen the mindset as the most important part of culture, a driving force. Something which can change the structure part if done well. To my belief structure is always preventing us from change, from being successful. So shall we change the structure or mindset?  I would always go for the mindset. It’s harder, but it brings significantly better results. Create a clear goal. Purpose. Something which makes to you stand up every morning and put energy into it. Something you truly believe in and are willing to take ownership and responsibility for. Something which makes you collaborate with others, something which makes your day. When you succeed with the mindset, you are usually ready to change the structure. So I truly believe that structure follows mindset. Which is good, because as the first step you can start with changing yourself. 🙂

State of Mind – Myself Dimension – The #ScrumMasterWay concept

Let’s continue with the next element of ‘Myself’ dimension. As we already said in the previous blog posts, each element of this dimension represented by a dice which you can roll every day or Sprint and choose the aspect you are going to take. The third dice is for choosing the approach – State of mind. The approach you take is important and can completely change the result you get from addressing the different situations. For every situation, you can choose one of the following aspects: observe, facilitate, coach, remove impediments, teacher and mentor, and increase positivity.

Observe

Start every situation with observing. There is no rush. Then choose any of the following approaches, address the situation by facilitation, coaching, teaching and mentoring or increasing positivity and return back to observing to see how it landed. If it works, you can continue with the selected approach, if not it’s time to change. Keep in mind that you work at system level and systems are complex by nature so hard to predict their reaction. You have to inspect and adapt.

Facilitate

Almost every situation can be addressed by proper facilitation. You can prevent conflicts by keeping the discussion in the problem space and prevent the situations when people takes it personal. Facilitator you shall be neutral. It’s their agenda, you only take care of the discussion flow.

Coach

Coaching can help when the other approaches can’t. Coaching will raise awareness and grow the interest to learn or change. It will start thinking process and creativity. Through coaching you can help team to reach the next level and become great team.

Remove impediments

This approach is actually a trap for ScrumMasters. Way too many ScrumMasters takes this approach as a destination and become assistants or mothers. Instead, you can help team to identify impediments by proper root-cause analysis and help them to solve the impediments by themselves.

Teacher, Mentor

ScrumMasters shall be the subject matter experts with hands-on experience from Agile and Scrum environment. This approach is about sharing the knowledge and experience so people understand the purpose of individual practices, Scrum framework and Agile.

Increase positivity

Finally, increase positivity. Celebrate success. Search for short wins. The more positive the overall team and company environment is, the higher chance they have to become great high-performing team and bring overall organizational a success.

Learning – Myself Dimension – The #ScrumMasterWay concept

Let’s continue with the next element of ‘Myself’ dimension. As we already said in the previous blog post, each element of this dimension represented by a dice which you can roll every day or Sprint and choose the aspect you are going to take. The second dice is for learning. Scrum Masters shall learn new things every day. This element shows a direction where you can focus the learning activity to gain Agile, coaching, facilitation, business, change, and technical skills.

Agile

ScrumMasters you must be Agile enthusiasts, constantly looking for new practices, concepts, and ideas. Joining local communities, attending or speaking at conferences. Looking for trends where Agile is heading. The world is changing fast, so do Agile and Scrum.

Coaching

Without good coaching, you can’t create sustainable high-performing teams. So better start right away. There are many classes and books on coaching, plenty options to choose from. But after all, it’s all about practice. Start tomorrow and get better during the time.

Facilitation

Facilitation is critical especially when the team is not that mature. Be ready to facilitate not only during meetings but anytime. Every conversation can go wrong, and create a conflict or misunderstanding. Be on a watch for those situations.

Business

As part of the mentoring and teaching, you will need to understand the Agile Product Ownership. Have an idea on how to form a vision, how to prioritize, how to build the backlog. Help Product Owners with business Agility concepts.

Change

ScrumMasters are implementing change in organizations, they change their culture, and way of working. Such change is one of the hardest. You are change manager, change is your day to day job, so be better at implementing change.

Technical

Finally, the most controversial aspect of this element is technical. It’s controversial because as ScrumMaster you shall not be a team member at the same time as you will lose the overview. The technical aspect here points to the Extreme Programming practices as continuous integration, shared codebase, auto-tests and TDD, BDD, pair programming, regular refactoring, agile architecture and continuous delivery. They are critical for team success and every great ScrumMaster shall have a decent knowledge about them.

Metaskills – Myself Dimension – The #ScrumMasterWay concept

Let’s start with ‘Myself’ dimension. Each element of this dimension represented by a dice which you can roll every day of Sprint and choose the aspect you are going to take. The first dice is for metaskills. Scrum Masters shall be able to take the metaskills of teaching, listening, curiosity, respect, playfulness, and patience.

Teaching

Teaching is embracing the wisdom, ability to advise people, be a good mentor. Your knowledge and experience on different frameworks, concepts and practices are your ground here.

Listening

Listening is a critical skill to be able to learn from the feedback and choose the right approach. We as human beings are not listening enough. Too often, we jump towards the closest solution and ScrumMasters are not any different. Good listening is a prerequisite of being a great facilitator, coach, and leader.

Curiosity

Being curious helps you not to take sides. Be open to different situations and solutions. Find creative and innovative ways of approaching things. Working with team and organizations is a complex task. It requires different skills in order to address the complexity.

Respect

Respect will help you to build trust and create safety environment. Respect different opinions, who knows what is right and what is wrong. At the level of a complex system, it’s hard to assess. Openness and transparency are your best friends here.

Playfulness

It’s going to be a long journey, so make it fun. Bring the metaskill of playfulness to your day to day work. Take the same approach as if you were playing the strategic game. It is just a game, so enjoy every single day of it, don’t get frustrated when you don’t win the first day. The good game shall take some effort to play well.

Patience

You have unlimited time as ScrumMaster, there is no hurry. You are not responsible for delivery, nor the short-term goals. Your goals can only be seen long-term when the teams are getting self-organized and high-performance. Only then people can see the ScrumMasters are doing the right job. You will never be finished, as Agile is not a destination, but a star on a horizon. There is always a better way, there is always a need for great ScrumMaster to guide us on our Agile journey.