image05
All we do is looking for some way to fulfill our needs.

On leadership

Articles about technical leadership



czwartek, 28 lipca 2016

Tagged under: , , , , , , , , ,

Perspective of the other side

While working with leaders I come accross the similar issue many times - they want somebody else to change their behaviour. For example:
How to deal with people that criticise my ideas?
How to force boss not to micromanage the team work?

We would like someone else to change, because we know that we are right, we have good intention and want to improve the work and the other side just disturb us. We believe that Agile/microservices/Product focus (not project)/whatever is the only idea that can help and everyone who doesn't agree is an enemy that should be ceased.
If somebody critices my ideas - must be wrong. If my boss try to micromanage he is an ignorant, because every book about management describe it as an antipattern.

But let's be honest - all ideas like:

  • (the power of) teamwork
  • limit work in progress
  • authonomy (instead of micromanagement)
  • timeboxing
  • agile/kanban/lean
  • TDD/BDD/ATDD/Spec by example
  • (...place your lovely idea here...)

are just ideas. They are supported by a set of believes, but mostly subjective believes. You believe it or not, but you can't prove they are right. They are just models, theories, hypothesises, patterns, heuristics, strategies. Because they are applied in complex enviroments, there are contexts where they will be beneficial, and there are contexts where they will not, and sometimes it will be very difficult to evaluate their real value. So everytime you meet someone else who doesn't agree, be aware that s/he can be right. It is a first step neccessery to deal with the issue. It is secondary what you believe in, much more important is how you react when sb doesn’t agree or follow.

The most important obstacle to tacle the challenge is our tendency to look at the situation only from one perspective - "I" perspective. This perspective is subjective, because it is based on our current believes, expectations, state, knowledge and biasases. This is why it is so difficult to solve problems between people. If we really want to find a win-win solution, we need to try to see situation from the perspective of other side ("you" perspective).

If a person critices your idea, just try to find an answer "why"? But beware because we like to see negative intention in other people's behaviour. "He critices me because he wants to diminish me". In some rare cases it may be true but it is not the root inention. The root intention is in most cases positive, at least from the other side perspective.
S/he may criticise your idea because s/he wants ensure that the best possible solution will be applied. Or want to warn about potention problems that may arise.

In the second example, if boss want to micromanage, just ask "why is it important". He may want to ensure that work will be done correctly or will be done in standarized way. When you know the intention, it is easier to find a solution - different way how boss can ensure it not micromanaging.
If you just say "Micromanagement is evil", you will try to take something away from him what is important and give nothing instead.

So the next time when you don't like someones behaviour or attitude, try to look at the situation from its perspective asking question "why is it important for him/her? what is a positive intention" and then it will be much easier to tacle the situation. And remember most of the stuff you think is right way of doing things is just set of believes, subjective belives so don't be too much attached to it.

(Of course the subject is not specific only to technical leaders but can be attributed to whole human race.)

Image source: http://www.etcfn.com/wp-content/uploads/2015/04/Rainbow-over-Rabbit-Ears.jpg

czwartek, 21 kwietnia 2016

Tagged under: , , , , ,

Simple things. Simple things. Simple things.

I have been yesterday to a great concert. The band is called domowe melodie. Here you can find one of their best know song. Of source the music was great, performance was great. But these things were not the only.

What hit me the most - these guys attitude to what they do. They just have a lot of fun from what they do. They play with it. They enjoy it and this is great and they do it in their own cute way. Just watch one of their videos. You get influenced immediately.

This reminded me what makes the juice of life. I wish we had so much fun and pleasure in our everyday jobs. The leaders (and everybody is a leader) can support making this happen. Be more emphatic, more smiling, more open. Life would be greater.

Don't do anything that isn't play - Marshall Rosenberg.

środa, 13 kwietnia 2016

Tagged under: , , , , , ,

Meetings in a hurry are not effective ones

The timeboxing is a fundamental technique for many Scrum activities. I can see a misunderstanding that meeting should be fast, a facilitator start to hurry up everybody to finish the meeting in the timebox. In the end problems are not discussed well and many uninformed decisions are made.

Time boxing in this case is about something different. It is for making conscious decision on choosing what and what not to talk about during the conversation. It is more for eliminating than for being in a rush.

In order to have effective timeboxed meeting as a facilitator:

  1. ensure everybody agrees what is the goal of the meeting, what is expected outcome and what decisions should be made (eg. planning meeting - we want to have items discussed with defined acceptance criteria, estimated and have brush design),
  2. ensure that agenda (structured) is agreed,
  3. keep an eye on time,
  4. if time is in danger, say it aloud and remind the goal, expected outcome and decision,
  5. ask what participants think they should focus on or eliminate in order to get the results in the timebox,
  6. if time is about to exceed the timebox, make an agreement for another time box (eg. we exceed the meeting for 30 minutes),
  7. sum up the results,
  8. sometimes it may be useful to make a short retrospective afterwards to find ways to improve the meeting.

6224819.jpg



wtorek, 5 kwietnia 2016

Tagged under: , , , , , ,

Have a clear vision, stick to the intention and adjust the implementation

No matter if you are tech lead, Scrum Master, Product Owner or just (why just?) a member of the team, if you want to make your idea a reality I have a very simple (and of course very difficult to implement) advise:
Have a clear vision, stick to the intention and adjust the implementation

Let's consider an example. Let's suppose you believe that incremental work is cruciual and want to influence the team to work this way.

1) have a clear and strong imagination of the target state
The first thing is that you yourself really have to believe in it. And you have to be able to imagine what it would be like for your team .How the team could split the work into smaller increments, how to verify if something is a good small increment. You need some kind of reference in your experience, then it is much easier to have such a clear vision. If you don't the only thing you can do is getting more inspiration about the subject (reading the articles, books, listening the podcast, watching conference talks or just taking part in a conference) and then suggest an experiment. You can use Disney strategy to get more clearance.

1b) try to find as many WHY answers as possible.
First try to answer the question WHY yourself. Why is it really worth the attention?

Why increments?

  • because it is easier to finish it in a short period of time
  • because if you have many small pieces your overall estimations will be better
  • if the increments are going to be very small, you may not need estimation at all
  • increments (slices of functionality) improves your ability to finish done work
  • you need to improve the way you work to be able to work in increments

Ok. But but then look for other resources - articles, books, blog posts and so on. And look for other arguments.
And then face these arguments (at the begging only in your mind) with your team. What would they answer? How that matches to the things important to them.

2) be patient and stick to intention
No matter how good arguments you have and how good they match team needs and how clear vision you have, others may not buy it. That's ok. Be patient. You just didn't find good enough way to show the value*.
Listen to the objections and look for the needs behind them.
Maybe they don't believe that they can organize work in increments. Maybe they don't know how to do it. Maybe they don't believe it is effective. Look for the way how to show it. Look for the way how to measure and compare both types of approach to items. Look for more inspiration.
Stick for the intention but not to solution. If you think about increments your intention is to slice the work vertically so that it can be integrated and deployed and the exact solution like BDD, TDD, the best slicing method are not so important. Be free about the implementation of the intention. Suggest the experiment, not the final solution.

3) adjust the implementation
If you managed to organize an experiment - do regular retrospectives (get feedback) and adjust the implementation. Maybe slicing one thing into 36 small items is not the best way. Let team find (and decide) a balnace in slicing.
No matter how the experiment is doing, regularly ask, what works, what not and why. What your team ca change to do it better. Getting back to the intention and revising  the implementation is your job. Local failures are just next step on the path of learnings. Failed? Just figure out what you learnt and make adjustments.

4) have a clear vision, stick to the intention and adjust the implementation
Yep, repetition. Repetition is mother of skills. So ... have a clear vision, stick to the intention and adjust the implementation.

* There is also a possibility that vision you have and/or share with others might not be a good option, so don't be eager to validate it from time to time.

czwartek, 31 marca 2016

Tagged under: , , , ,

Two structuring meetings patterns

As I describe it in my book it is good to structurize meetings (or parts of meetings) so that they get more effective. Here you can find two examples useful for Planning meetings (Scrum examples that can be easily adopted to other situations).

Structure: Expose the options

During the planning meeting there was a moment when the overall group energy was very low, but there were three guys intensively discussing about the subject having different opinions what to do next. There talked about their argument so passionately that it was very easy to get lost and miss the point, and I am afraid they also weren't sure what the other side is talking about. Then I suggested:
- Only three people are discussing here, the others are bored. Let's name the options you present and whole the team will vote and choose the solution.
And one of the team member got the pencil and started to write on the board:

  1. let's do the task as much as are able to, let's hope we will finish it in this sprint
  2. let's divide it into smaller items, and choose the subset we will do for sure
  3. let's take it to the refinement and we will do this item in the next sprint
It turned out that it was not so easy to express the intent clearly and it also turned out that one person didn't understand what the other wanted to say. Because all the team were suppose to vote they engaged in the discussion so that they could make a handy decision and the energy group was back.
Five people voted on second option and two people on the third. The decision was made.

What kind of structure you can find here?
When: group or just a few people are discussing intensively
Then:
1) notice that you can see not everybody is engaged or the decision far from being made
2) ask for naming the options (it would be great to write it so that everybody can see it)
3) vote on the options (you can do it similarily to the planning poker game)
4) if there is a draw: draw the option (or have any other arbitrary method to choose the option)

Structure: Structuring Planning meeting

When the particular type of meeting tends to be chaotic it is good idea to introduce structure to organize it.
When I thing about Scrum Planning meeting I like to seperate the steps of planning (a few selected steps):
1) The team browses the items that
a) have been refined recently
b) weren't finished in the last sprint
c) are at the top of the backlog
Browse means to remind very shortly intention of the item and not going into details.
2) Product Owner supported by the team prioritetises (expressing why) and chooses the items that are the strongest candidates to be chosen to the current sprint. In many cases it means that the weakest candidates are removed.
We do it so that we will not discuss about things that are not going to be developed in the sprint.
3) Starting from the top (the highest priority item) Product Owner presents (or reminds) acceptance criteria for the item and the team estimates it (supposing that items are refined enough to get estimated). This is also time to talk about details if it is neccessary.
Other version:
Product Owner presents all the items (one by one) and then the team has time on its own to do some brush desing and make estimations.
4) Team chooses how many items they can do so that they can make a reliable commitment.

No matter what kind of structure you use it's important to keep the borders of the steps clear - especially not to talk about details to early (or maybe not to talk at all).

wtorek, 26 stycznia 2016

Tagged under: , , , , , ,

The Hacker Way

.
.
A few days ago Paweł Wrzeszcz sent me an Erik Meijer’s talk  „One Hacker Way” https://www.youtube.com/watch?v=FvMuPtuvP5w from GOTO Conference that took place in Copenhagen. It is a very provocative talk and that is very good. It questions the (mostly) the Scrum method and it is good that such point of view stands out because as Scrum became the main process framework for software development it is very healthy to look at it in a critical way. As a industry we have 20 years of Agile experience, Agile became a big business machine (which I am also part of) and it is very easy to destort the core ideas what really happens especially when doing Agile at Scale (take a look at Dave Thomas’ Agile is Dead talk https://www.youtube.com/watch?v=a-BOSpxYJ9M).
So the Erik’s talk is about ending status quo about Agile.



What I don’t like about it is the form it is presented. It is very manipulative and Erik’s presents one way thinking. Some examples:

  • ·      he compares Scrum to McDonalds (process, average predictible quantity and quality, any teenager can work there) – which programmer wants to work in McDonalds? A biased metaphore;
  • ·      he builds attractive identity – the Hacker identity in opposite to Agile team player;
  • ·      „I prefer build software (coding) than doing standups” – is it in oppoiste?
  • ·      Scrum is about controlling Hacking is about freedom and innovation - really?;
  • ·      „every minute of talking about software is lost” – it reminds me an old programmers antipattern of just going into the code not thinking much about the context.

What kind of antidote Erik wants to recommend? The hacker way:
  •      Focus on impact – solve the most important problem;
  •      Move fast – you can learn only by doing;
  •      Be bold – take risks, experiment;
  •     Be open – be transparent about decisions;
  •     Build social value – bring what you did to community.


What I can see in the above values? Exactely values of Agile and Scrum.
  • Focus on impact is about creating business value;
  • Move fast – inspect and adapt;
  • Be bold – courage;
  • Be open – transparency;
  • Build social value – I can’t see anything directly connected to it, but I think it is very aligned with agile.


What I also don’t like much about the talk is that it lacks of context. Erik’s worked for Microsoft, Facebook and these are the sources of his expriences. He presents a view of software company that has its own product. (I know that he claims that in the future the biggest companies will be the software ones). What about software companies that outsource their services, what about companies that just have their IT deparment with a bunch of developers? The hacker way is a developer-centric idea, which can be applied in companies that are developers-centric and having its own product. Why having its own product? Beacuse hacker way is about doing experiments (more than planning in any way) and taking what was done (Eric Meijer’s says „Be a beekeeper. Let programmers make the honey and take what they did). Experiments are about having a time buffer to do it what is not much possible when you just have a small profit margin from programmers work (when you do B2B services). Developer-centricity also mean that you need very skillful programmers. To summarize up, the context for The Hacker Way is:
  • ·      a developer-centric software development company;
  • ·      having its own product;
  • ·      having top programmers on board;
  • ·      where the core business is about innovation.


What more can we get from this? What is the meta-level message of Erik Meijers?
In my opinion some part of community (industry) is a little bit tired of Agile/Scrum/whatever you call it. It moved towords a management method more than to Software Craftsmanship (and this is also the reason why the Software Craftsmanship emerged). I can hear the voice, that programmers got involved into planning, talking about requirements, micromanaging and are not much happy about it. They want to code. Although the goal of introducing Agile is to ease the process, it is still quite heavy when we come to the meetings (what is also my observation after years of practicing Scrum), especially in Scaled implementation of Agile. And I think that it is important to hear this voice and find the way how to tune it. It is kind of „inspect” message and it is time to adapt.


piątek, 15 stycznia 2016

Tagged under: , , ,

Technical Leadership book is available


It is a great pleasure for me to share the information that today is my "Technical Leadership" book premiere. You can buy it from Helion and I also encourage you to visit book companion site http://technicalleadership.pl . I am going to develop a technical leadership knowledge base there, so be in touch.