Tag: team

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 🙂

My Team – The World Dimension – The #ScrumMasterWay Concept

The world dimension of #ScrumMasterWay concept represents three levels ScrumMasters shall operate. The first element is called My team. Though the time and energy ScrumMasters spend on each level differ based on the team or organizational culture and maturity level, they have to be present at every level to keep an eye on changes. If you do it right, and your organization is not too dysfunctional with people actively fighting against what you build at My team level, you shall be ready to move to the next level in about six months.

Level 1: My Team

The first level of #ScrumMasterWay concept is My team. Being ScrumMaster at My team level feels like being a team member. They look at things from the development team perspective: Explain different Agile practices, facilitate Scrum meetings, help to remove impediments, coach the team, and make the team great. If people are only aware of the existence of this level, we often hear that ScrumMaster can be a team member at the same time, or it can rotate, or it shall not be needed at all after some time. They are all huge misunderstandings of the ScrumMaster role.

#ScrumMasterWay - My Team

My team level is a great start. If you do it right, it will help you to demonstrate the success of Scrum, and show you a way to the next level of addressing product success, and building an Agile organization. If you do it right, the team becomes not only cross-functional, and self-organized, but high-performing as well. The team will be significantly better that anything you ever experienced before. More productive, always improving, proactive and taking over the ownership and responsibility for the overall goal.

You can’t skip this level, as this is something tangible, something which helps you to demonstrate success. Something which helps you to taste Agile for the first time. And get feeling how it shall be. The first Myself dimension will help you to address My team level and prevent you from falling into assistant or mother of a team. You are done when you build the great team from the group of individuals. You recognize it with a high level of energy, positivity, and activity in the team. Team members will be happy to go to work, they will enjoy it, and take other team members as friends.

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.

How to make great Sprint Review

Scrum Reviews have been for a long time left out of our focus. Teams and ScrumMasters are asking how to improve Sprint planning, Standups, Retrospectives, but most of the time there are no real questions related to the Sprint Review. So how to make the Sprint Review great? Firstly let’s review the goal of this meeting which is to get feedback on our product. So no status of done vs. not done Product Backlog Items has any space here. No slides with any Burn-down or Burn-up charts, no velocity comparism.

The Sprint Review shall show real working product to our customers so they can give us a feedback. Yes, to the customers, not Product Owner (note that customers are all stakeholders, users, people who pay for the product, simply anyone both internal and external who has any expectations from that product). Showing the product to Product Owner makes no sense as he is part of the Scrum team and collaborated on the solution during the Sprint.

We don’t present technical solution, but business value delivered and we let team members take the opportunity to show that they did and get the applause :). However, if in some rare cases you happen not to get that enthusiastic feedback, and your customers get angry for any reason, the Product Owner makes himself visible and protects the team. After all it’s his responsibility to understand the customer well enough so those misunderstandings won’t happen.

Your Sprint review is great if you …

  • Show the real product
  • Let users experience it
  • Don’t have any presentation / slides / status
  • Development team is presenting
  • Invite real customers / users
  • Product Owner is most of the time quiet and doesn’t need to interfere

Sprint Planning in 30 minutes

How much time takes your team to finish Sprint Planning? To my experience it could be anything in between of above mentioned 30 minutes and full day. If you are closer to the second option and it feels scary, annoying, waste of time for you, let’s have a look at few recommendations how to cut it out into 30 minutes.

First, let’s see how to run the Sprint Planning itself. I recommend Product Owners to come to the Sprint Planning with physical cards for each User Story. They quickly introduce them, answer questions if needed and then let the team choose out of them. Don’t bring the exact ordered list; let them freely choose from the cards. There are two reasons for that. First, you maximize work done as they can organize themselves in a way they are most efficient, and at the same time there is higher commitment as well. Second, you build a trust between team and Product Owner. You trust them they will choose the right User Story which brings the highest value at the moment. Once the team select the User Stories witch they believe they are able to finish within the next Sprint and put them on Scrum board, Product Owner and Scrum Master can leave and let the team finish the Sprint Planning. During this second phase team will collaboratively split the selected User Stories into maximum one day tasks and revise the Sprint Backlog commitment. After 30 min they are done, have full board of cards and can start working.

If that still feel unbelievable, let’s have a look to the preparation. There are three key recommendations you should do in order to make your planning fast and meaningful. First is for Product Owner. 2-3 days before the Sprint planning let the team know what are your priorities for the next Sprint, so they can have a look and prepare themselves, ask questions, etc. Second is proper Backlog Grooming. The goal of Backlog Grooming is make sure the team understand Product/Release backlog (i.e. all User Stories, Super User Stories, Epics and vision). At this time team do the estimations and help Product Owner to split User Stories which are too big, or add Acceptance Criteria. Once understood, they are ready to be planned to the Sprint.

To summarize it, if you are not able to do such fast planning, improve your preparation (team time to prepare, grooming, pre-planning) so the planning is here not to investigate new functionality but to confirm how much we can make. Doing that, you gain motivated team who is not wasting time at never ending planning, better reliable Sprint plans and higher backlog quality as you are not pushed to do splits and changes at the last moment. Start step by step and continuously decrease your time needed. It’ll go much faster than you would imagine.

Online Scrum Board

I belong to the Agile crowd who believe the physical board is very much useful and can’t be easily substituted for any online board. Let me give you a few reasons.

5 reasons why not to use electronic board

  1. We are *still* limited by the screen inches and no electronic board gives you good overall Sprint visibility.
  2. No electronic card takes pride in your handwriting, so the ownership of the whole board is much closer to “someone else’s problem”.
  3. You can’t touch it, move it, or throw it away. It’s annoying how many fields in the *average* system are required to add a task. It’s a tiresome to crumble tasks to one day activities.
  4. It’s hard to draw on it. There is no creativity. It’s just reporting by definition.
  5. Regardless of the ability to share, usually the ScrumMaster controls the board during Standups. Not any team members.

To make it simple, to organize yourself as a Scrum team you need very good visibility of what is already done, what is in progress and what still needs to be done and who is currently working on which part. As there are no assigned User Stories to any team member, every individual is responsible for finishing Sprint Backlog. To be able to organize your daily work yourself as a team, you might need a flexibility – depending on where you are you might decide to distinguish tasks by colors, next time by shapes, then you start tracking dots per day, and the next time tear the task if it get blocked or anything else. You can start right away, and stop any time it suits you and there is no need to win over your system.

To make it clear, I’m not suggesting now your overall backlog should be at the board even if there are companies who work only this way. However, for this time of being I’ve been focusing on Sprint commitment, and simple tool which helps team to synchronize themselves. So keep your *future* – the User Stories – in the system, keep Sprint tasks and team synchronization be driven by physical board not connected to any system, and then link back any commit or important note back to your User Story in the system so you have a history and traceability.

And yes, I understand that some teams might not be at the same location, and can be spread over the world. So if you have such situation, still you might prefer flexible tool which gives you a good visualization. There is no ideal tool like that, but there is one I learned from some of my distributed teams. You can see the picture of that board below. It’s easy to use, it gives quite good overview as well. And yes, I can come up with hundreds of improvements, but I still like the simplicity of this solution. You can try it here.

Scrum Board

Scrum Master is Not a Secretary of a Team

I’ve been wondering why so many teams believe that Scrum Master is here to draw burndown charts, prepare reports and be the only point of contact for the team, whenever anyone wants anything from them. They maintain the board, write cards, and prepare all you can imagine. And the team works ok, but surprisingly they are not at all self-organized. Such Scrum Master role is quite boring. But that’s not what was intended by the role of Scrum Master. I guess the reasons for that are coming from two different motives.

Firstly, Scrum Masters are often missing the real experience with Scrum, teamwork and self-organization. They are in a new role and want to succeed in it. They biggest fear is they would not be useful to the team, and team would not appreciate their work. So they try to do their best to make their work visible for everyone. Be helpful. The biggest Scrum Master’s trap is to be locked in the position of caring mummy who is scared to let her grown up kids go their way. But in such case you will never get real Scrum team.

The other reason comes from one of the Scrum Master responsibilities – to remove impediments. It’s the only responsibility which seems to be easy to do for starting Scrum Masters. Seems to be. Unfortunately, that often comes with huge misunderstanding. The goal of the Scrum Master is to build self-organized team which in the ideal theoretical world means “do nothing”. In other words, Scrum Master is here to help a team to find solutions to their problems, not to solve problems oneself. Nonetheless, most of the beginning Scrum Masters are eager to help, happy to do any work needed if it helps their team. And they don’t see that by doing it they are destroying the team.

Is Product Owner part of the team?

When you ask this question in the companies, you find out that about 30% of teams believe that he or she is not. If you ask why not, you find out that they feel their Product Owners are far away from them, they don’t help them, and they don’t understand them. And I’m not talking about physical distance now. So where is the problem? In many companies, at the beginning of their Agile transformation, they simply move team to Scrum and the Product Managers to Product Owners. What happens? They don’t have a time to be Product Owners as they are responsible for several huge products. Luckily they understand the product, but they have no time to share their understanding at any higher granularity than general ideas or epics. And that’s indeed not enough. Such teams are having a Product Owner Proxy, or Tactical Product Owner who is in reality acting like real Product Owner and don’t miss their business Product Owner. Why is that usually not good? We are missing the “one PO voice” and we are losing the business driven approach in favor of technical point of view. In such environments we are as well missing the push to “maximize work not done”, which is one of the Agile Manifesto principles. That is indeed not good for either team or product.

Then we have about 50% of companies where they believe the Product Owner is part of the team, but he is not responsible for writing User Stories. Why not? Usually because he or she doesn’t understand the technical aspects, so how can he possibly do that? They usually don’t invite him or her to the retrospective either, because… well… he is a team, but retrospective is for development team only. So it’s kind of unclear.

The remaining 20% take their Product Owner as their member. They invite him to the retrospective, they trust each other. If that’s possible, they sit together. If not, they speak with each other often. Such Product Owner relationship is very helpful. Not only for your team, but the product as well.

Measurements are dead, let’s measure

During my career as both Director of Engineering and independent Agile Coach, I’ve been hearing still the same grumble from managers: “We can’t get rid of measurements and KPI’s. How else could we know if the person is performing well, how can we compare people?” and at the same time, grouching from the team members: “We don’t like the individual based KPI’s and measurements, how are we supposed to be a good team when our managers can misuse that against any team member?” It’s surprising but no one likes individual metrics, they all admit they are useless, but they are all afraid to try anything else.

So if you have a bit of courage, you may try this: It’s based on coaching relative scale and is team oriented: 1 stands for 🙁 and 9 stands for 🙂 and it’s great if you add a reason for rating lower than 4 and higher that 6. Firstly, let the Product Owner give a team his number how he is happy with the team.

As a second input, ask Scrum Master to give a number to every team member how much he is happy with this person as a team player. Let them discuss it, but make sure the discussion is not about “why I’ve got 5 instead of 7”, but is focused on future development of that person discussion “what should I do differently so that I’ll get 7 next time”.

And last number goes from the team members. The best you can do for this part is to ask everyone to divide 100$ to all team members except himself. You may worry that they can agree with each other and rotate all the money one by one, or distribute them equally, but that’s not common in real life. The great think on this evaluation is that the team members are giving a feedback to themselves. So every team member gets an answer to the question how do you value my contribution to the team? And if you find out the other team members don’t see any value in your work, you would most likely be very much concerned about that situation and asking how can I do differently so that you value my work more.

Combining those three inputs you will learn much more than from traditional metrics, regardless the company size and culture. It’s working just awesome, but you have to have courage to give it a try.

And when this is just normal for you, you can take it one step ahead. The fully Agile companies are using such tool as the only one appraisal tool across the company. No other bonuses than those distributed by employees to the other employees. So in such company, if you feel you would like to appreciate the receptionist, give her some part of your bonus sum. The other one can be for your colleague, another part for a developer from a different team who helped you with some issue. And when you are afraid it’s too crazy for you, I would like to remind you that we are only talking about bonus distribution, not the whole salary. When you do so, you will increase team cooperation over individual heroes work, and openness and transparency over politics and gossiping. And it would be fun. If you still don’t know, start with Appreciation cards. Make them available and encourage people to give them to each other. Even by that you will learn a lot about yourself, your team and the whole organization ecosystem.

Product Owner Development Model

What is the difference between requirements, use-cases and User Stories? I’ve been struggling with that question a lot. On one hand it is easy. It’s something completely different. On the other hand, that’s not anything which would help people to understand the difference on their way to implement Agile.
After some time working as Agile Coach, I created this Product Owner development model. It’s focused on product creation and Backlog item definition process.

Level one: User Story is just a special format of a sentence

At this basic level of understanding we are very close to the requirement-like specification. We keep the backlog in the Word document, as we anyway wrote very long sentences and extensive document chapters about the functionality. There is often huge mix of current functionality we want to keep, and new functions. The only change we do with that requirement document is to change/add User Story sentence instead of general name. So we get something like “As a MyCompany, I want new tariff, so that my customers are happier” followed by 2 pages long text description what the “tariff” exactly means. Such User Story may survive at team board for several Sprints without getting done. Surprising, isn’t it? We wrote User Story and it didn’t help!

So this stage is about documents. We create PowerPoint presentations to describe product goals and vision, we use complex roadmaps to define timeframe and we have written long specification documents to describe functionality. The more we write, the better product we have. The understanding of the role of Product Owner is very limited, decisions are often taken as a board of people without real product success responsibility.

Level two: We have ‘bigger fish to fry’, than write User Stories

At this stage we already understand that we have to describe our User Stories better. The team needs higher granularity and detail. But we don’t have time to write User Stories, so that we delegate that unimportant work to some administrative position called business analyst, business requirement specialist, business delivery manager, development team or whoever else is around. We don’t have a time to write such ‘technical’ details. It’s not important for us. Just make sure you will deliver it on time. We have bigger fish to fry. We have to talk to the customer. It’s more than enough to discuss our product ideas and high-level visions. We are responsible for Backlog, and yes, we prioritize it. However, the level of Epics is just about the right level of details.
So this stage is about big high-level decisions and quantity. We already have a Product Owner position, although that person is not often seen. Instead we have the army of people, who are willing to help official Product Owner with creating as many User Stories as you can imagine. What if we need that functionality in the future? Let’s describe all we can possibly do. And if we cover any potential functionality, it must be successful.

Level three: User Story is use-case

Here we finally got it. It’s about functionality slice, it should be INVEST. We have to make it concrete, understandable, and testable end to end functionality. Isn’t that easy? It’s like a use-case, isn’t it? Well, unfortunately, sorry to say that, no. There is a huge difference between use-case and User Story. So what’s the difference? Use-case is end to end functionality which defines what user does and how he is using the product, while the User Story defines only a new/changed functionality. We don’t repeat the current functions anymore and we focus on the changes only.
This stage is already user focused. We start describing different roles. We focus on functionality end to end. However, it’s still not simple and not clear enough. And it’s still not what we expect from the Product Owner.

Level four: We will design one big User Story and copy-paste the rest

This stage looks already pretty good. We have understood that every User Story has three parts – Who, What, and Why, and we think about all three of them. However, we haven’t still understood that every single User Story has its unique value, and it makes sense to invest an energy into individual detail User Story creation process. We are now spending energy describing Super User Stories (smaller and much more concrete pieces than Epics are, although nor small enough to be done in one Sprint yet.) We have great tools, which unfortunately offer a copy-paste feature. So we heavily use it to save our time.

This stage is about User Stories which already create some picture in your head once you read or hear them, but they are very similar to each other and hard to be recognized. We already have spent some time to investigate reasons ‘why’ for bigger chunks of functionality, and we are very happy about it, so we use it at every detail User Story which we create from it – just copy and paste.

Step five: Understand of business value and impact

Finally, we understand that it is worth of investing our time to every single User Story. And we are even looking at it more than once. We reprioritize individual User Stories and not only big Epics. Every User Story has a special role or persona. We have spent time and energy defining every one of them. We encourage ourselves to throw away or postpone User Stories already written, if they don’t match our product/release charter (vision, goals, success measures, timeframe).

We focus on business value and “maximizing work not done” which is one of the core Agile Manifesto twelve principles. We keep our product simple. We try to visualize business value for every User Story in the “Why” part of the formula, so that it helps us to decide on Backlog priorities.
Furthermore, we compare every new User Story with product/release charter and discuss how that User Story contributes to the defined goals and vision. Before we write the complete functionality, we try to measure impact, i.e. if the goal of Epic1 is to limit the traffic through the component A, than individual User Stories may propose different solutions how to filter that traffic out. In traditional management we finish most of them if not completely all. In this stage of this model, we try first to measure the impact by identifying of the percentage of possibly filtered traffic by each solution proposed. And then implement just the ones which have real impact with respect of our goal to limit the traffic. We may identify many great ideas, but we stop implementing as soon as the goal is achieved. At that time we don’t need any other functionality and we can move on to the next important area.

This final Product Owner Development model stage is about business value and impact. The less is more. Product Owner is feeling strong ownership and responsibility over the Product Backlog and individual User Stories. There might be people to help him as Product Owners rarely works alone, nevertheless he understands the importance of his role in defining even the small functional slices as User Stories are. Finally, in this stage the Product Owner is here to shrink possible functionality to the minimum which brings just enough business value. Product Owner must negotiate the functionality and focus more on understanding the customer real needs than all their wishes to come true.

Summary

To summarize it, Product Owner Development model is useful tool which helps you to understand where you are with your Agile Product management and product ownership. It also shows you the way where you shall continue and which areas you shall focus. Theoretically you don’t have to go through this model one by one, but it is very likely you will pass all next layers from the one where you are now even if you stay at that one just a very short time.