I’m off to a new adventure! While exciting, it’s also just a little bit nerve-wracking. What makes leaving one place for another difficult is when you truly love the people you work with and the work you are doing. I find myself doing quite a bit of individual retrospection on all the people I have been fortunate enough to work with and how they have each influenced me in some way. I also think about the skills and experiences I want to take with me and how I can improve on them in the future. Finally, there’s thanking everyone for the opportunity to be a part of their lives and allowing me the opportunity to learn from them and grow. It’s somewhat sad to be sure but, then, I also think about how my exit really won’t have an impact – in a good way. The people and work I leave behind will continue on as smoothly as ever. It’s like water….maybe there’s a little ripple on the surface but still whole and filling up the container just as it should.
I was given some really good advice tonight: In every situation you find yourself in, no matter how many times you have seen it, you must treat it like it’s the first time. You need to look at it with fresh eyes and try to remember what it was like, for you, the first time. I just loved how that was put. Once you have gone through the “same” process enough times, it would be easy to become a little numb to all the dynamics in play. It may also be easy to be a little insensitive to those who are experiencing something for the first time. As a Scrum Master, having an open mind is critical.
I know, personally, I have been put with new teams – just coming together and finding myself less patient with them because I KNOW what’s coming. But, really, I don’t. I mean, it may be fair to say that I know where they will end up but that’s not the important part when a new team is coming together. It’s HOW the team comes together that’s important and, if I’m less patient or dismissive, that can really impact the HOW and can also completely negate my “where they will end up” comfort.
There was a team I worked with a long time ago and the set up was somewhat screwy. Despite having learned that I don’t know it all several times over, when this team started, I wasn’t in the right frame of mind. There was a lot going on for me and I wasn’t invested in them. I wasn’t really there to help them. I dismissed their concerns and told them to “trust me”. Rightfully so, they didn’t. Why should they? I was very clearly not engaged. My mind wasn’t open to them and theirs sure wasn’t open to mine. This team was completely new to Agile and I was doing them a disservice. I didn’t want to go through their phases with them. I wanted them to hurry up and get there. You can imagine how well that worked out. It didn’t. Not at all.
I did recognize it and made moves to correct it quickly but, it didn’t matter much. They had no reason to trust me, value my opinion or seek my advice. What resulted was dysfunction at my hands. It was a complete waste of an opportunity for them and for me. A Scrum Master has a special relationship with a team because her focus is the team. She can shape the safe environment teams need to learn and grow. She can guide them through learning Scrum and help them chart their course to greatness IF two things are true:
1. The Scrum Master has opted in and has an open mind to her new team.
2. The Team has an open mind with regards to the Scrum Master and tackling Scrum.
I believe, if you begin with an open mind, there’s a bigger potential for greatness. With an open mind you listen with the goal of understanding. Being open automatically requires courage which is definitely needed when charting new territory. Openness allows you to view your team positively. Openness nurtures trust. When you’re listening, exploring, trying, brainstorming with the team, you’re building that trust and camaraderie.
As a Scrum Master, when you find yourself in a new environment or situation, don’t bring the events of the past with you. Open your mind to what is possible. Keep your eyes wide to observe and listen. Remember that, though familiar, it’s only familiar to you. Explore the solutions with your team with minds wide open and you’ll find the journey will be full of learning for everyone. Even you, the Scrum Master who (thinks she) has seen it all. Every team is different and so is their path. Be open to their adventure.
The minimum. If you wanted the minimum, then, congratulations! I’m pretty sure people don’t strive for the minimum though so what should be measured instead? Measure progress against the end goal. I know. I know. It’s crazy talk but, seriously, if there’s a goal you want to hit why not try to assess yourself against it? I guess the argument of “we want to know where we are against the least acceptable metric” may hold some water. However, I don’t want something that tells me 100% meet the minimum. I would MUCH rather know that 8% meet the target and 70% are pretty damn close. Those who are meeting the minimum now have a little competition and may actually kick it into high gear.
If I know who is closest to the target, I have a chance to leverage their insights and help those who are anywhere close get closer. I can see what everyone has in common (who isn’t excelling) and work towards identifying a root cause to help make it easier for them to hit the target. If 100% are meeting the minimum, what does that tell me? What can I do with that information? Reward it? Um……
I know! Let’s set an interim target! Guess what you’ll get? 100% are meeting the interim target. And it all starts again. Seriously, folks, let’s strive to meet the goal. Let’s not sell ourselves short and give ourselves crutches. People want to do well and if well means the minimum, that’s what you’ll get.
Personally, I love a challenge. When I’m not challenged, I get lazy. When you expect greatness from people you will get greatness. When you expect mediocrity you will get mediocrity. Shoot for the stars people!! Then, when you have scooped them all up, shoot for another galaxy. I DARE YOU TO BE BETTER THAN YOU ALREADY ARE!
My very first team as a “Scrum Master” (having never taken a class or worked in Agile before – thus the quotes) wasn’t formed well and I’m pretty sure none of us knew what the heck we were doing Agile-wise. At least I didn’t. That said there is one thing I did with that team which I still do today. I protected them. Protection is important for teams and it’s not just the job of a Scrum Master to do it. When I say protect, I think, what I mean is to protect the environment. A team needs an environment where they can be honest without repercussions, feel comfortable holding each other accountable, disagree on how to reach common objective, focus on themselves and their commitment and work in a way that works for them. I’ll never forget the Product Owner coming over to me and whispering that a developer was watching TV in the galley while eating lunch. The Product Owner thought the poor guy should be in the room coding! It wasn’t enough that the team and this particular developer had been killing themselves for weeks – they needed to starve too. Obviously, that wasn’t OK and I said as much to the PO (bless his heart). As a Scrum Master, you need to care for and about the people on your team and help protect the integrity of their environment. Amr Elssamadisy’s blog has some great posts on the importance of a safe environment which are worthy of your time and thought. Protect the team!
Further along my Agile journey, I noticed some teams had working agreements that took up an entire wall. Well, not an ENTIRE wall but, almost. On my teams, the “norms” were always super simple and I don’t think I’ve seen more than 8 in any of them. My teams would have things like “If you’re sick, stay home.” and “Don’t eat smelly food in the room.”. I saw one team that had Team Norms, Meeting Norms, Stand Up Norms and Core Hour Norms. It was nuts. It seemed, to me, that the norms were representative of many individuals protecting what they wanted. Their agreements didn’t reflect a single entity at all. Maybe I’m crazy but, I believe Norms should be simple, things everyone can agree on and no more than 10 bullet points. Keep it simple!
Further still….I created a backlog for newly forming teams. The stories accounted for things teams need to do when they first form like agree on a team name, create a team vision, decide how to organize the board, inventory their skill sets, establish team norms and so on. Each story had acceptance criteria. I let the team prioritize them and they also estimated them. A sprint was equal to 2 hours and they used the complete Scrum Process. The first time I did this was really, really cool. The team went out, as a team, to scout out other rooms and interview other teams to get ideas. They didn’t split up and what they got out of it was SYNERGY. Everything in that room had their stamp on it and it was clear to anyone who walked in. Seriously, executives would comment on how good the energy was in that room. My only role in that whole exercise was to answer questions as they related to Scrum and keep it simple for them. So, to sum up, let the team own the team from day 1.
I heard a Scrum Master refer to himself as a babysitter the other day and it made me cringe. The truly horrible part was he was saying it to a class of team members who were learning about Agile. *sigh* The beginning time for a team is precious. There’s no history or baggage. There’s a great clean slate and anything is possible. This is time to take advantage of to team build, establish ownership (the team owns the team) and set the tone for duration of their existence. As a Scrum Master, don’t squander this time and don’t let anyone take it away from the team either. Protect their space to form. You’re not a babysitter or a hammer. People are smart. They want to do well and they will give their best IF they have an environment to enable them and a Scrum Master who is willing to protect them, keep it simple and let the team own the team.
GAH! Do you ever hear that statement in relation to stand-up, planning, retro and demo? I do. I hear it far more often than I would like to. Often I hear it’s because the Scrum Master isn’t good. It’s not just a Scrum Master responsibility though and, generally, that’s not the case. Sure, for a new team, there’s a need for the Scrum Master to facilitate and teach. No doubt about it but, when a team is knowledgeable about Agile and Scrum AND has been together for a while, the team can own the solutions too. However, sometimes, you hear other reasons why I think a team member would feel this way:
1. The ceremonies (I really can’t stand that word) aren’t useful to the team members and take WAY too much time prepare for and conduct.
2. The team wasn’t listening during all that training about what they’re for, who they’re for and who owns making them useful and productive.
Too often, I also hear people blame training for the reason things aren’t working or say training is THE answer to the problem. Since I disagree with this more often than not, I’m going to focus on number 1.
Stand Up – It’s for THE TEAM. It should take no more than 15 minutes and you answer the 3 questions (when you’re just starting out). If it’s taking longer and it feels statusy, then, you’re doing it wrong. It’s not just the Scrum Masters job to point this out and keep the team on track. Come to stand up prepared. Don’t just look at the board once a day. Listen to what your team mates are saying and get in the practice of holding each other accountable.
Planning – It’s for THE TEAM. It’s when you decide what items to pull off the product backlog and how you will as a team execute. It takes a while when a team is starting out. If it’s still taking an inordinate amount of time and feels like overhead, get to the heart of WHY it is that way. Maybe the team isn’t focusing. Maybe the stories aren’t written well. Grumbling about it being overhead won’t fix it though. It WILL make it worse. Discuss, investigate and experiment but don’t continue to complain about it.
Retro – It’s for THE TEAM. It’s where the team takes time for themselves to reflect on how they’re working as a team. It’s to identify ways to improve – AS A TEAM. To me, it’s the most important of the ceremonies (there’s that word again). If it’s not useful, read Esther Derby and Diana Larsen’s book on the topic: Agile Retrospectives: Making Good Teams Great. Continuous improvement is a Hallmark of a high performing team. If you’re complaining it’s overhead, you’re not on one and you should do something about it. By doing something about it I do not mean you should leave the team. I do mean you should step up, learn and apply it.
Demo – It’s for THE TEAM to demo to their Stakeholders how they delivered on their commitment. It’s to get feedback and show off how awesome the team is. If it feels like overhead b/c you’re prepping for three days for it. STOP prepping for three days for it. It shouldn’t be onerous. It should be demonstrative. As a team, decide how you will conduct demos going forward and start experimenting.
Teams are empowered. Team members are empowered. You don’t need to wait for someone else to fix it. As a team member, you can and should fix it. Your Scrum Master can help. If you really, really want to lose the “pain” associated with the ceremonies (dang it!) learn how to make them effective as they’re described and, as you mature, modify them to suit the needs of your team. Also, you need to want to be a part of a team and a solid, if not high-performing one, at that. Teams need to start somewhere and complaining isn’t starting. It’s just complaining. Teams succeed or fail as a TEAM. That applies to how they work together as much as the product(s) they deliver.
So often I am amazed at how much I learn with regards to Agile that applies to my own life. Most recently, prioritization was front and center. I had a difficult and personal decision to make and I was truly struggling with what to do. I was torn and, frankly, I didn’t want to decide. I wanted to have it all! ( Now if that doesn’t sound like some Product Owners and Business Stakeholders I don’t know what does.)
I reached out to someone I thought could help and, what do you know, he did! How I got to meet this mentor is a great story which I’ll save for another time. Anyway, his guidance was to sit down and not focus on my decision. Instead I was to focus on my longer-term vision. Now, I will say my vision is still a work in progress, so don’t think you can just bang out a vision in 10 minutes and be done with it. Once I had the vision (in pictures ONLY) he said to put words to it and really think about what was non-negotiable, open for discussion and nice to have. Then, take the opportunity I was considering and compare it to the vision and the words. I did as he suggested and my decision was clear!
In delivery, when you know your long term objectives or vision, it’s MUCH easier to prioritize all of the cool things you could possibly do. If the vision isn’t clear, well, you could spend a lot of time, effort and energy on something that won’t bring you closer to your vision and that’s not OK. It’s not OK for the team, for the users OR for the business. If you’re not spending energy on things that bring you closer to your vision, the odds are good you’re spending it on things which will (likely) take you further from it. The true waste is you won’t know until you’re so far away and it will be harder to to get back on track.
It is a little shocking, when I think back on all the teams I have worked with, how many times I have heard “We HAVE to have EVERYTHING!”. Funnily, in our own lives we know having it all isn’t generally possible but, in work, it can get dangerously close to normal. And, how is that acceptable? It shouldn’t be. There should be uber-clear goals a company is trying to reach and the things they are trying to do should enable getting closer to the goal. A Product Owner who doesn’t understand the vision will not be able to explain the context to the team. This means it will be ridiculously challenging for the team to work quickly and efficiently. Without context, the how becomes guess work. If the Product Owner doesn’t understand the vision, there’s not a snow balls chance he will be able to effectively prioritize leading the team to work on things that aren’t valuable.
As a Scrum Master insist on the Product Owner reviewing the vision with the team. Allow for an appropriate amount of time to ask questions. Encourage the team to understand the thinking behind the prioritization and to challenge and suggest things to be considered by the Product Owner. This is the environment to strive for. Mutual understanding and benefit. Understanding the vision and fostering this type of relationship with the Product Owner is powerful. It’s powerful enough to allow a team to take off and deliver amazing things.
It still hurt to make my decision. I really, really wanted to give it a go. It wasn’t the right opportunity at this time in my life and I was able to be at peace with it. Of course I want it all. Who wouldn’t? That said, knowing the context of how that one “thing” fit into the larger picture was critical to me. Understanding the product vision and the resulting prioritization is one of those concepts where everyone will nod their heads and say they get it but, do they? Do you? We need to focus on the right things so we are always getting closer to the vision and doing amazing things. As close as we possibly can anyway until we’re satisfied.
Something I often try to remind myself and team members is to listen to understand rather than listen to respond. It is ever so much easier to say this than it is to do it! So, next week, I’m going to try to ask at least one question before I answer, respond or comment on anything and see what happens. I hope to accomplish the following:
- Provide better and more thoughtful responses to those seeking them
- Stop myself from just speaking and ingrain better listening habits
- See if, perhaps, my questions generate something for the person I’m speaking with
- Determine who is courageous enough to opt in and try this with me
And, I’m going to let my teams know what I’m doing and invite them to do the same and see who opts in and what happens with them too. I’m also inviting anyone who is reading this to join in. Come back here and write about your experiences. The good the bad and the awkward!
We talk a great deal about commitment in Agile. Generally, in IT, we’re afraid to commit. When you commit it could mean you put yourself and your team on a death march. There’s no such thing as a guarantee or sure thing but, there is such a thing as commitment.
Commitment means you will give your all. Your absolute best. You will do this for your team and yourself because you take your word seriously AND you want to give and be your best. Beyond yourself, you will commit to always learn and improve. You commit to holding yourself and your team mates accountable. You commit to succeed and fail as a team – one entity.
Really, it’s no different than life. Personally, I have had to make tough decisions based on whether or not I felt I would be able to give my best and commit. The times I have not listened to myself, I have found myself to not be “all in” and it hasn’t been a great experience.
To commit, you need to have heart and passion. It has to be about more than you. It can be intimidating but, it’s so worth it.
In the last week I have been hit hard by the reminder of how powerful value is. There are two instances I want to highlight.One is related to people and the other related to stories.
VALUE YOUR PEOPLE
It’s important as a Scrum Master, a people manager or a leader to show the people you work with and for that you value them as a person and for the work they do. When a person feels valued, they are motivated. And, I know, everyone is motivated by different things. For some, it’s money. For others, it’s recognition. There are many things a person may be motivated by but, all people need to feel valued. If they don’t, they disengage and that isn’t good for anyone.
You need to find out what is unique in the people you are surrounded by. It doesn’t matter if you manage them, lead them or work for them. Identifying what makes an individual special is powerful…for them. You can find ways to build on it, leverage it, showcase it and help the person shine. When you make someone feel valued, they will return it with awesome performance and, even better, loyalty. If you’re not investing thought like this into your people, please, take some time to do so. Have a conversation. Find out what they’re passionate about. Discover what they’re good at doing. Learn about what they want to learn about. Invest in and value people and the dividends are endless.
People want to be valued and they want to work on things that are valuable. In a SAFe release planning event this week teams had identified the features they were delivering and broken them down into stories. In SAFe, teams then specify their release objectives. It’s a layman summary of multiple stories which, Product Management then values on a scale of 1-10. Keep in mind teams are working in priority order so, the initial thought is their focus is on the right features. When you break a feature into stories and specify exactly what the objectives are for the release, what happens is amazing. A conversation with a group of Product Managers and the team takes place and, often, a high priority feature has objectives associated with it whose value is mixed. We’re all about delivering value right? Here’s an example over-simplified:
EPIC – Build house
Feature – Build Front Entrance (priority = 1)
Feature – Build a Deck (priority -2)
– Complete deck to hold more than 6000 lbs. – 9
– Complete steps to front porch – 10
– Complete front porch covering – 4
– Paint front door – 1
– Complete rails around deck – 8
– Build grill bump out – 2
When you look at it, there’s more VALUE in completing items associated with the lower priority feature. Good to know for a team. Very enlightening to Product Management. Awesome conversations and understanding generated between delivery and the business. All is all, just goodness.
In summary, there’s power in focusing on value – for the people and the work. See what you can do tomorrow for people. Make someone’s day.
A process doesn’t work without people. A framework doesn’t work without people. Process and frameworks are meant to facilitate the delivery of value. Value isn’t delivered unless you have people. If everyone can agree on this we should also be able to agree that, in order for the implementation of a new framework, process or effort to deliver value to customers faster, people are THE lynchpin.
If we agree people are the lynchpin, we need to agree on what they need to be a strong lynchpin. If I think on times where I have performed the best, there were common themes:
- I trusted those I was working with and was trusted by those I was working for
- The people I was working with were all focused on the same goal
- We all had high standards for ourselves, our product and each other
- Having FUN was not an afterthought
There are a few more but, these are the “biggies”. Note, there is nothing in here about how we worked together. I say this because I think, sometimes, it’s easy to get caught up in the process – or framework – of work. Actually, the simpler the framework, the harder it is to implement because it is so very reliant on…people. When you look at Scrum, it’s very light on the process and how. Kanban is even lighter. Simple processes imply a faith and trust in people to do the best they can, be open and honest with themselves and each other and try to be better each time.
Heavy processes or frameworks imply a lack of trust in people. Otherwise…why all the process? Process is made of checkpoints, flows, owners, approvers, accountable, responsible and the list goes on and on. At the end of the day, people either did what they set out to do or they didn’t. A process or framework won’t actually guarantee success.
When a company or team decides to implement a new framework, they need to first look at the people and decide a few things. One, do they have people they trust? Two, are they (the people making the decision) open to working differently? Three, do they believe the framework they are implementing and the people they have to work within it will truly help us achieve their goal?
Processes and frameworks for the sake of having them are no good. It’s not good for the company, the people or the customers. Make sure there’s an environment for people to be successful in. Keep the framework/process as light as possible and. Ensure people are working on valuable products. Leave the people alone unless they tell you they need you. Then, be supportive and enable their learning and success.