Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Data is Loading...
Your address will show here +12 34 56 78
Agile Coaching, Business, Leadership, Passionate Teams, Podcast


Key Take-aways: 


Passionate teams are motivated

Yeah, a passionate team to me is a team that’s comprised of people that are motivated. They’re very interested, intrigued and driven to do the work of the team. There’s something about it that they feel like they’re making an impact and they know it and so they strive to come up with unique solutions to achieve the goals that they have from their customers. 

Team chemistry by giving choice

You know, I think that if people have the freedom to choose their teams, maybe there’s a greater chance that the teams will have chemistry, that the people will want to work together. Maybe the people choose to work together. I think giving choice in team, is something that, it’s almost like risk management for team chemistry, If people have choice. 

Sometimes people need to work with others

Forming, storming, norming, performing and you know, sometimes I think, yeah, if a team is together too long, they could feel like they’re stagnating. Maybe there’s not enough diversity of thought […]. You could try to change it up and bring in different work or start a book club or something, but sometimes people just need to work with others.

Change is also a personal choice

So it’s a business decision how the rate at which you grow, it’s kind of like stepping on a gas pedal fast or slow. But then it’s also a personal choice, I think. Just like our opinions about change in general, I might be a person that wants more change or maybe I might be a person that prefers more stability and less change and I think that’s valid.

It’s valid to not change your team

And it’s valid to not change it. So I’m not saying bust up all your teams, I’m not saying dynamically change all your teams as fast as you can, what I am saying is that reteaming the ability to change is an option that I think is left out of many of the discussions in software development best practices. It should be on the table for many reasons that are valid and then sometimes invalid. Team change is gonna happen, so you might as well get good at it.
 

Tap into the interests and needs of the people

Yeah, I would say really try to tap into the, get to know people. Tap into their interests. What motivates them? We’re motivated by different things. You know, have one on ones. Talk in groups. Be open to enabling people to grow maybe into a different role or into a different squad, into a different team or to working on something else like really try to tap into the interests and needs of the people and really support them to help them into the directions that they want and it’s the sweet spot when you find the direction that the person wants to go when it’s in step with the direction the company wants to go. So I think through having close relationships, we can make this happen.
0

Agile, Agile Coaching, Basic Scrum, Scrum
A few years ago I attended a Sprint review of a product development team. All stakeholders were invited to this meeting and got an update on the product the team was developing. The central message of the review was that the team wouldn’t be able to deliver the full feature set as promised before. Instead, the team was far away from delivering anything sellable to product management. The whole product was a mess (for various reasons that are not important here). The message was quite clear for everyone in the room: we are not able to meet the defined release date. In spite of these facts, the head of product management got up at the end of the review, gave everyone a pat on their shoulders and said: „I’m sure, you’ll still make it.“ He just ignored the plain truth, that was shown to him. He believed in miracles.

Scrum (and any other agile framework) is based on empirical data. Of course, this applies to estimation and planning, too. Due to the continuous inspect and adapt cycle, you are always able to replan, if necessary. In agile we always plan to replan. If you find out, that you won’t be able to meet a certain date or deliver a defined feature set, you have to react. It doesn’t help if you ignore the truth, even if it hurts. It won’t get any better. Instead, you lose the chance to do something, that might save your product or project. If everybody accepts the facts, you can always:

* reduce the feature set (in most cases it is anyway too big)
* move the release date
* add more people to the team (if it is still early in the project)
* Stop the development
* …

Don’t believe in miracles; they happen only rarely. Instead, accept reality and adapt your planning accordingly. You should always plan to replan.
0

Agile, Agile Coaching, Business, Scrum, tips & tricks
After many years of consulting large enterprises, building the right product I found, that there is one theme that keeps coming up again and again: Garbage in, garbage out. Those teams are trying to build the wrong thing righter, and the result is often disappointing. If the input of the team is crap, so will be the output. There are various reasons for that:

PO not empowered

Most companies implementing Scrum just grab their existing development teams and transform them into Scrum teams. The old project manager (PM) is now the Product Owner (PO), and some developer is playing the Scrum Master (SM) role additionally. The rest of the organization stays the same.  Usually, there is some marketing or product management department, that defines, what has to be built, which results in requirement documents that are handed over to the new PO. The newly appointed is then entering each of the requirements into Jira, VersionOne or any other “agile tool” and the Product Backlog is done. If he tries to order the backlog by asking what is the most important, he gets the answer that everything is important. In the end, this pseudo PO cuts the product backlog into Sprints and the only things that change for the team, are the bi-weekly Sprint Plannings. A few month later, everybody states, that Scrum didn’t bring any improvements. Does this sound familiar? Some companies call that “Proxy PO,” which isn’t simply more than an anti-pattern.

Stop doing this! Empower your PO! Get somebody in your Scrum teams, who can take product related decisions. Only then, you have a chance to build the right product.

No Vision

It’s still scary for me, how many development teams don’t have any vision. I just had a team building a product for the last 5(!) years without knowing why they were doing this. Even the Pseudo PO had no clue, what the purpose of the product is and what problem it solves for the future customer/user. They even build a second version completely from scratch. Millions of Euros have been burned, without earning a fair amount of money. How can you create something without knowing, what the problems are you are solving? How can you take decisions on a daily basis, if you don’t know where you are heading to?

Before you start developing your product, make sure that you know WHY you want to build it. There are various tools out there, that can help. Try to start with the Product Vision Board (Roman Pichler) or even simpler: a Lean Canvas.

Swiss Army Knife

You don’t know exactly, what are the most important use cases for your product? Ok, then let’s build a Swiss Army Knife! Not! It will just make you slower. You won’t benefit from a shorter TTM (Time To Market), even when using Scrum if you are trying to cover all possible use cases. This is a so-called CYA (Cover Your A**) tactic. Usually, this happens, if nobody in the company has a clue, what the most important use cases are. This leads to long development times, and when you hit the market, you only have a mediocre product.

Talk to your customer! If they are working on confidential products, where your product is only one part (e.g. a sensor for a new upcoming smartphone), sign an NDA. Convince your customers, that you can only build the perfect product if you know their future use cases. Stop being mediocre and start being outstanding solving your customer’s problems.

Conclusion

You can’t deliver excellent products if your team’s input is average. If you put garbage on the team, the outcome will be garbage, too. It’s not enough to transform your development teams into Scrum teams, you have to work on their environment, too. And you have to make sure, that you transform your input to your development teams into something meaningful.
0

Agile, Agile Coaching, food for thought
You may have seen this: A company decided to become agile and introduced an agile framework e.g. Scrum. The management hopes for higher product quality, a better TTM (Time To Market), an improved risk management, finally a project that is on time and budget and more. Although they implemented Scrum by the book, after about half a year, they realize, that none of the promises came true. The Scrum Master is searching desperately for another, a better tool he can try next, but none of them has the desired effect. Step by step the team is falling back into their old habits and in the end they say: Scrum does not work. And they are right! Only by putting a new shiny saddle on your dead horse, you won’t get it running again. To understand what happened one has to know, how Scrum was created. 
Success is never because of the process but always about the people – Marc Löffler
keep reading
1

Agile, Agile Coaching, Scrum

There are still a lot of people out there who believe, that agile methods are the silver bullet to all their problems. This leads us to the 7 agile sins, that I collected in this post. Let’s have a look at the 7 agile sins: 1. Stop learning
2. Don’t listen
3. Stop thinking
4. Be dogmatic
5. Ignore the agile values and principles
6. Misuse the agile toolkit
7. Ignore the transparency

29

Agile Coaching, Scrum
During my time as ScrumMaster I collected an interesting list of bad behavior in Scrum teams called the “10 things that drive ScrumMasters crazy”. At the same time I started thinking about what I could do about it and how to stop the dysfunctional behavior in my team. I searched for the causes of the different behaviors and I found a lot. But what you tend to see at first is only the surface and not the real reason. That’s why I began to dig deeper to find the real cause. In the end I found out that everything can be condensed to four root causes. I call them “The four evil root causes from hell”:
  • Ignorance
  • Fear
  • Indolence
  • Apathy

Ignorance

I met teams were the only Scrum training they got was the link to the Scrum article on wikipedia.org. It’s no wonder that they don’t know how to implement Scrum if there’s nobody to train or coach them. Sure, there are some rare teams were wikipedia may be enough but most teams new to Scrum, especially in bigger organizations are in need for some initial training and at least somebody who has some experience with implementing Scrum. E.g. if a team member is doing tasks that are not part of the Sprint Backlog because Harry Smith* told him it may happened because nobody told her that it is the job of the ScrumMaster to stop these disturbances. It’s the same with hidden impediments. Most of the time they are not hiding their impediments on purpose they just don’t know that they can bring it to the team or ScrumMaster. There are several other things on the crazy list that are caused by ignorance. Overcoming this root cause is relatively easy: Train and coach the team! When I start with a new Scrum team I’m using a special recipe. You can read about this recipe here: “How to kick off your new Scrum team”.

Fear

Fear is not only a problem in software development (Oh, really?). Fear can be a problem in any domain or private life. In software development it’s primarily the fear of change, the fear to learn something new or the fear to lose control. If a team member don’t want to work on a task because it doesn’t fit in what he was doing in the past it’s mainly a fear to leave his comfort zone. If the team member doesn’t want to split his tasks into smaller ones it’s maybe because he has the fear to be tracked. Or if a team member always asks the ScrumMaster what to do next she may have the fear that she won’t be able to solve any of the tasks in the sprint backlog, Fear can be the reason to a tremendous amount of dysfunctional behavior. And that’s why fear is one of the evil root causes. A few years back I was working for Volkswagen. After one year as employee my manager told me that I’ll attend a training called “Self organization and self management”. When I talked to other Volkswagen employees about this training I was faced by a lot of rumors. They told me that this is a real tough training and that several attendees canceled the training because they could not stand the psychological pressure. Now I was curious 😉 The first day of the training started and nothing special happened. But in the evening of day 1 they came up with the rules for the next 3 days: Everybody has to do something which is out of their comfort zone. The procedure was like this: When you think you are ready for your “Performance” you have to stand up and say load “Performance”. After that the other attendees are clapping their hands. Then you start doing whatever is challenging for you. It was up to the attendees when they start their “Performance”. Interestingly most of the attendees did their “Performance” before lunch. We had people praying with us, reading books (everybody laughed at him in school), dancing and so on. And now guess what I was doing? I did a presentation in English. At this time it was a real challenge for me and completely out of my comfort zone. But after the 3rd presentation in English I started to feel comfortable. I increased my comfort zone. If you like I’m a living example that this method worked. This is why I still believe that this methods work. So kick your team mates out of their comfort zones 😉

Indolence

Ever tried to move a car were the motor is broken? You have to put a lot of energy into pushing the car to get it moving. It’s the same with indolent people. They are sitting at their desk or standing at the coffee machine and are just doing nothing. They don’t have the energy to get themselves started on a new task and instead they are procrastinating all day, week, month or even year. These people are late at meetings, won’t start to work on something new or doing any other stuff but their work. If you have such people in your team it won’t take long until other team members will complain about him. You have to find a solution to start their engines on a easy way to get them working with the team. The following methods have been proven to work:

Get their commitment

It’s not only a phrase if the ScrumMaster asks the team in the sprint planning if every team member commits to the sprint goals. But sadly this is sometimes happening. Comments from team members are ignored or everybody is just nodding their head without really being committed. Get their real commitment, this is important. In new teams you could write an informal contract with the sprint goals that every team member has to sign. Put the contract on the wall of the team room so that everybody can see it.

Rotate the moderator role

In Scrum there is no rule that the ScrumMaster has to moderate all meetings. Instead rotate the moderator role. The sprint retrospective is a great meeting to start with this approach. Try it you’ll be surprised by the results.

Use Avatars

Every team member should have an avatar on the sprint backlog. With this approach everybody can see who is working on what. This helps the team to recognize if somebody is working on the same task for days and gives them the chance to check what’s the problem with it.

Involve them

I saw a lot of e.g. sprint plannings were one or more people didn’t really participate. They were just sitting around listening (or playing with their phone) instead of working with the team. If you recognize this behavior involve these team members. Ask them what’s their opinion on the current backlog item. Avoid that only 2 or 3 people are working on a new story. Involve everybody!

Apathy

Apathy is the most evil and most dangerous evil root cause of all. If their’s one team member getting apathetic you have to immediately do something about it otherwise it will spread like cancer. A apathetic team member is easy to recognize. He talks bad about the company, the project or the management. He doesn’t participate and nothing matters to him. It doesn’t matter for him to be late it doesn’t matter to him what is defined in the DoD and it doesn’t matter to him what the feedback is like in the sprint review. Even if apathy is IMHO a root cause in most cases their is an additional cause which leads to this state. Often this isn’t an easy one. Start doing face-to-face interviews with every apathetic team member to find out what’s the problem. After you collected the data from everybody decide what to do next. If the reason is technical debt schedule a workshop to define how to cope with it. Build a vision describing how to solve the problem so that everybody sees that a real chance to overcome the problem. If you find out that their is a insulating layer between management and the developers I wish you good luck 😉 No serious, that isn’t an easy one and I can’t really tell you how to overcome this because this could mean a complete mind shift in the whole company which isn’t simple. It really depends on the management and if they are willing to change something. You can also try to introduce an FedEx-Day or 20% time like Google or Atlassian. At Google every employee has one day in the week were he can work on whatever he likes. In this 20% things like GMail, Google Maps, Google Buzz or the Google Wave were created. If 20% sounds to much start with 10% (e.g. Friday afternoon) and try it for e.g 6 weeks. Do a retrospective after this time to find out if it had some benefit. You can read more about this in Daniel Pink’s book “Drive”.

Conclusion

There are no silver bullet solutions for the 10 things that drive ScrumMasters crazy or any other dysfunctional behavior. But their are some things you can try. Let me here if you had success with one of the suggestions above or if you solved on another way. Every feedback is welcome… Here is a short ligntning talk I did a few moth ago about this topic. Enjoy! How to Defend Against the 10 Things that Drive Your Scrummaster Crazy from ACE! Conference – Best Practices on Vimeo.     Here are the slides of my talk. Unfortunately Slideshare doesn’t like the color of the font: Want to rate my talk? Go here:
7

PREVIOUS POSTSPage 1 of 2NO NEW POSTS