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, 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

Business, Leadership
You are a manager and hate remote teamwork? Here are three ways to sabotage it:

Put teams in time zone as far away from each other as possible

If teams work in close time zones, they can use their working time to collaborate. But that is exactly, what you like to avoid. Therefore, make sure that the difference in time between all your teams is as big as possible. The best is to have a twelve-hour time difference so that one team is going to bed, while the other teams are starting to work. That way it always takes a day to get an answer to your emails which slows down communication. Scheduling a meeting, that fits for all parties is nearly impossible. Isn’t that great?

Don’t allow modern communication tools

Give your team the worst communication tools. If possible, even prohibit emails (while telling your teams, that they should make use of face to face conversations). If you already have some tools in place, make sure to limit them to audio only. Video or screen sharing is only allowed for higher management (yourself) or needs a complicated application process (signed on real paper by managers around the world). You know, because of security. Somebody could walk by a meeting room and see some confidential information. Scary…

Don’t let them meet in person

The worst thing that can happen is that the whole team meets in person from time to time. This would lead to a better understanding between all the team members and eventual to a better (remote) team performance. You don’t have any budget for that, have you? That was exactly the reason, why you created that remote team: to save some money. So you cannot afford any travel expenses for those cheap workforces (That’s at least what you tell them).

Do you have any other ideas to sabotage remote teamwork? Put your ideas into your comments.

0