Category Archives: Leadership

Leading Tech Teams

Leading Tech Teams

Slides from my workshop at I T.A.K.E. Unconference 2014

Advertisements

Optional Conference impressions

This week I attended the Optional Conference organized in Budapest. Below you can find my notes.

My talk on the Agile Mindset

I gave a talk at the conference comparing the agile and the traditional mindset. It’s the stuff I’ve written about in a paper earlier this week. Here’s the presentation from the conference.

Notes from other talks

Here are some notes I jotted down during the talks:

  • Budgets don’t work because they force two different numbers into a single one: the estimate and the target budget.
  • It’s hard to manage people in Generation Y, because their parents made sure they have everything. As such, they can’t be threatened or bribed. Instead, they must be inspired.
  • There are two types of stress and we want to avoid the second. When we start adding pressure, at first eustress kicks in, but with enough additional pressure we become distressed:
    • eustress is good, it helps achieve results
    • distress is not good, because it triggers the limbic system (our primitive brain)
    • agile helps because it generates mainly eustress
  • If you want to get into a state of flow, you need the right balance between the difficulty of the problem you are solving and you own skills. This model of flow illustrates the various combinations between difficulty and skill.
  • Ericsson is doing agile in a 112.000 persons organization. The R&D department is more advanced in terms of adoption, and they have a massive 24.000 people involved.
    • The program manager for a product being developed by 450 people told the story of trusting too much in incremental architecture and being bitten by it when they had to make significant investments to switch from a simpler database to a more scalable one.
  • Deutsche Telekom is another massive company who is transforming to agile. In one city, they have 100 teams who are organized using agile concepts: long lived, cross-functional, collocated. To ensure a constant flow of ideas, periodically one person is rotated between the teams.
    • The team members rate their managers on how well they embody the company and agile principles.
    • Teams have veto rights on new hires.
  • Rational arguments are not that useful for convincing people. What works better is storytelling.
  • Boris Gloger had the closing keynote. He advocated for an agile management style based on strong leadership skills. He emphasized four: clarify the purpose, give positive feedback, listen and use appreciative inquiry.
  • I need to learn more about holacracy, human system dynamics, radical management and appreciative inquiry.

Agile and HR

More and more people are asking me about how to “marry” agile and HR practices. The performance review is one of the most pressing concerns for HR professionals, and they want to align the practice to fit with agile principles.

Jurgen Appelo advocated during dinner for dropping the practice altogether, but my feeling during the Open Space was that most managers were afraid of this perspective (I ran a session on this exact topic). Boris Gloger gave me an interesting idea to chew on when, after discussing various alternatives, he said “So, are we thinking that the HR manager should be like a ScrumMaster for the organization?”

I’ll have to clear up my thoughts on this, but I feel that’s an interesting direction to explore.

How Disney and Pixar manage creative people

A recent blog post on Harvard Business Review got me really excited. It’s an interview about how to manage in a creative environment with Ed Catmull, the president of Walt Disney Animation Studios and Pixar Animation Studios. His words match many of my beliefs about modern management, and I’ve highlighted below my key takeaways.

Embrace diversity
Disney has several studios doing animation, so a lot of traditional managers would push for unification of technology in search of economies of scale. Ed advised his employees differently:

“You may look at the tools that the other has, you may use them if you want, but the choice is entirely yours. You don’t have to take ideas from anybody else.”

Deliver quality
There was some media attention that Pixar had to push to 2015 the movie The Good Dinosaur, originally planned for 2014. Ed isn’t worried though:

Ultimately, there’s a criterion whether the film is good enough and we don’t let the other stuff get in the way of it. One thing I don’t believe in is the notion of a perfect process. Our goal isn’t to prevent all the problems; our goal is making good movies.

Create a spirit of trust
When Ed took the leadership position, there were several people leaking information about the movies to the press. Instead of entering an Inquisition mode, he focused on building trust. He had a speech in front of the employees in which he highlighted that when somebody goes to the press, they break their colleagues’ trust. This simple message was way more powerful than threats to change behavior:

When I said that, the entire audience burst into applause. For the one or two people who were talking to bloggers on the outside, what they saw was that everybody else in the studio was really upset that somebody was doing this. So the message didn’t come from me, the message came from that response of the audience − and whoever was doing it stopped doing it.

If you want to learn more, Ed has a longer article (How Pixar Fosters Collective Creativity) and a book (Creativity, Inc).

Re-blog: Do Agile Teams Have Performance Reviews?

I’ve been recently getting a lot of questions about managing performance on agile teams. Managers and HR professionals are used to the annual performance review process, where the manager analyzes a subordinate’s performance and plans their next improvement steps. This doesn’t seem to be congruent with a self-organizing team. So, how do we address this issue?

Read more: Do Agile Teams Have Performance Reviews?

YOU are the professional

You have a responsibility. And you’ve been ignoring it.

Almost every month I work with one or two new teams. So I get to see a lot of cool new products, ideas, environments and technology.

Unfortunately, I also get to see a lot of crap. Crappy code. Crappy team morale. Crappy project plans. When this happens, I put on my detective hat and try to get to the bottom of it. In most situations, after asking enough questions, I hear a common reason for the problems: “Our manager asked us to… <x>”.

It seems that managers ask us to write code without pairing or code reviews because that’s a waste of time. They ask us to start developing even if the requirements are unclear. They make us commit to deadlines we know are not feasible.

Why do they do that?

I believe most of the time the managers are trying to do a good job. It’s us, the techies, that are dropping the ball. Let me explain. As I see it, management’s job is to maximize the output of finite resources. So they try to negotiate bold goals hoping that would make everyone bring their A game and consequently the team will achieve its best result.

Unfortunately, in their continuous quest for better results, they often demand things that make sense only in the short term. In order to close a deal based on a certain scope and release date, they ask us to commit to both. To start that new project sooner, they ask us to skip TDD and architecture enhancements for the current project. And the list goes on and on…

And we agree

We have become conditioned to believe that we are not allowed to fight back, when that’s exactly what we should be doing. Our managers don’t always understand the architecture needs, what clean code does for long term code maintainability or how pair programming and TDD can increase the quality of a product.

But we do. And I don’t think we do a good job of explaining the long term consequences of the decisions we are being asked to make. We aren’t brave enough to step forward and have that difficult conversation. We retreat to our desks and lament our manager’s narrow mind to a colleague.

This has to change

As the IT industry moves more and more towards agile, everyone’s voice gets stronger. Every team members is encouraged to express their opinion about potential risks. Naturally, you should have a clear, economically motivated argument for rejecting a request. Not just managers, but every role in our industry should learn to think and reason in terms of (to name a few) customer value, efficiency, effectiveness, productivity or sustainability.

A few examples of arguments you could make:

  • Committing to an arbitrary release date could lead to penalties due to delays.
  • Eliminating automated testing and refactoring generates the need for a stabilization phase in which no value is being added.
  • Banning pair programming means that new team members will become productive in months instead of weeks.

My challenge to you is this: The next time you are being asked something that doesn’t make sense to you, remember that YOU are the professional. Think about the experience accumulated in all the years you’ve been building software. And dare to fight back for what you believe in.

Against ‘Experiment’ as a Social Hack

Large Hadron Collider
The Large Hadron Collider

The year is 2009. I am having a hard time convincing my team to adopt one week iterations. As I’ve since observed, this short iteration length unnerves some teams, who fear they won’t be able to hold the high pace necessary to deliver each week. But I really wanted us to be extreme programmers, and I had read (sic!) that xp-ers did one week iterations.

So, I’m in the middle of my sales pitch and I can’t seem to be convincing my team, when I remember a trick I had learned from an agile book. I asked my colleagues:

Let’s make an experiment and see what happens!

After uttering the magical word: “experiment” everybody relented. It was something they didn’t seem to be able to fight against. We went forward with the one week iteration and eventually decided it had indeed been a good choice.

But the true meaning of experiments is somewhat different. Wikipedia dixit:

An experiment is an orderly procedure carried out with the goal of verifying, falsifying, or establishing the validity of a hypothesis.

Get it? No hypothesis, no experiment. You need to state what you are trying to prove with the experiment (the hypothesis) and also the means of verification (the measures). This way, assumptions and biases become more obvious.

So in the example with my team, I could have said:

My hypothesis is that one week iterations will not negatively influence our ability to deliver. We will run 5 one week iterations and 5 two week iterations. We will measure time spent in meetings against total working time. We will measure total story points delivered against total story points planned. The percentages should be similar for one week and two weeks iterations.

Often times, the experiment proponent does have a hypothesis in mind but doesn’t articulate it. By articulating it, the team can engage in critical thinking about the hypothesis and the measurements, thus improving the experiment.

Other times, like in my case, the proponent uses the ‘experiment’ coat as a social hack meant to get acceptance for a proposal. Please don’t use it like this. You owe it to your team to fully bake your thoughts.

I know I have learned my lesson.

References

(Photo credit: http://www.flickr.com/photos/11304375@N07/2046228644/)

What can leaders learn from Amanda Palmer?

Olaf Lewitz recently wrote a blog post and it included the following TED talk from Amanda Palmer:

Amanda is a musician who decided to give her music for free and ask fans to contribute as much as they’d like. To date, almost 25.000 people funded her next album for a total of almost $1.2 million.

Kickstarter project by Amanda Palmer

I was most impressed with a part in her talk where she says:

The media asked: “Amanda, the music industry is tanking and you encourage piracy. How did you make all these people pay for music?”. And the real answer is: I didn’t make them. And through the very act of asking people, I’d connected with them, and when you connect with them, people want to help you.”

I too get this question a lot: “How do I make my team members do X?”. Team leaders and Scrum Masters seem to be the ones in more desperate need for an answer.

But the real answer is: you can’t. You can’t make people do things. They have to want to. This reminded me of the Buffalo Bridle from Jerry Weinberg’s The Secrets of Consulting: “You can make buffalo go anywhere, just so long as they want to go there”.

In order for people to want to help, they have to want to. And what will determine them to want to help you, just as Amanda discovered, is you connecting to them. Telling them honestly: “I see you”.