All posts by tdabrowski

after_a_while

Time as Scrum Master’s poison

I believe that, as Scrum Master, you can’t create a high-performing team in one or two weeks. Let’s imagine that after laborious months of your work a team is stable, aware of its dysfunctions and moving towards self-organization. People know one another, they collaborate well and delivery product frequently. What about you Scrum Master? How would you feel after being part of a team for 12, 18 months?

In this post, I would like to raise an issue which is being part of a team for too long is a poisoning situation for Scrum Master.

Someone could start asking what is the reason for saying this if you still have lots to do as Scrum Master…

Looking at your team…
… there is a still room for a team improvement,
… there is a still way to speed up a product delivery,
… there is a still possibility to raise a technical quality.

This person could be probably right while mentioning those arguments. So why „time factor” sound as a poison for Scrum Master in my opinion? I would like to refer to the theory of System Thinking to help to understand this point of view. Peter M. Senge said:

System Thinking is a discipline of seeing whole

In discussed topic, when you join a team as Scrum Master everything is new for you. You are asking lots of questions, you are trying to understand dependencies (both technical and product-wise) and a relationship between people. Your goal is to gather as much information as you could to have a high-level understanding of a current situation. So what you are aiming to is to create a picture of a whole. You are fresh-minded, not influenced by your work environment, not blinded by anything. All of these help you to propose relevant actions and introduce your agility plan. You strongly believe that it is the proper way. It sounds so exciting, you are stimulated by new surroundings, you have lots of positive attitude in your activities. Wouldn’t it be perfect if such case stayed for a long time?

The reality is that after a few months working with a team, you are becoming part of the system, you would be only „system component”. You are losing an external point of view. You start ignoring obvious things that influence and slow down a team. They could prevent people from a continuous learning. What worse is that you stop developing your skills. It could be very difficult to step out from this situation as you could not be even aware of it. You live in a comfort zone, you are safe inside a team, which is working well but not as much effective as it could be. That’s why I’m saying the longer you stay in the same team the less you support them. In such case “time” is a poison for being Scrum Master.

So how to avoid it? What antidotes Scrum Master should take to recover? I’ll tell you my secret medicines in the next post.

*Image source: Gwendolyn Knapp book’s cover

antiagile

Agility insights

I’ve been talking recently lots with people from different companies to understand how they are moving towards agility. Many of them are saying – yes we are fully doing Agile right now. When I’m hearing this “magic” sentence I always ask – please tell me more… tell me what do you mean by “doing Agile”, how it works for you…

So here is a summary of Agile perspective that is evolving inside those companies:

  • Agile equals iterative delivery,
  • Scrum Master is a report manager,
  • Scrum Master is responsible for assigning tasks to developer,
  • Scrum Master acts as project manager,
  • Product Owner assigns stories to sprints,
  • Two roles exists inside a team: Project Manager & Product Owner,
  • Agile ceremonies make company agile,
  • Developer is mostly interested in his tasks,
  • Agile means writing requirement as User Story.

Does it sound familiar to you? Is it one of the companies that you know? Those are typical Agile Anti-patterns in my opinions and in fact most of them are against an agile mindset. Understanding how companies imagine agility helps me realise how much work still need to be done to create the right meaning of it. After fixing it inside your working environment you could start to create a people-oriented organisation based on learnings and transparency.

IMG_20160424_193418782_HDR

London Lean Kanban Days – key takeways

There was London Lean Kanban Days conference last week. Thanks to HolidayCheck I had a pleasure to participate in this event. As well as being excited by announced speakers (Pawel Brodzinski, Tobbe Gyllebring, Gitte Klitgaard) I was really looking to meet British Lean community to get a different perspective. In this post, I would like to share with you key takeaways from this conference.

  • Visualize a problem rather solve it – creating an awareness is often enough, then let people fix it – as a coach you don’t have to do everything by your own.
  • Lean = LeaRn – we sometimes forget about the main concept of lean which is continuous learning while focusing on other Lean principles like establishing flow, implementing pull approach or defining value from a customer perspective. Take your time for reflection, analyze what you achieved and learned.
  • Acknowledge yourself – you need to take advantage of the imposter syndrome by things like realizing that your experience is unique, fear indicates growth and keeping pushing your boundaries, improving where you have a passion.
  • Traditional project management is much closer to Agile mindset nowadays. The most needed skill for a project manager is leadership and an organization should aim to be adaptable.
  • Extreme self-organization at the company level is doable – it takes a time, it is not one-day shift and probably part of people will decide to leave your company.
  • While doing a change you need to have someone responsible for delivering value, and facilitating the risk assessment, you need to focus on organizational goals instead of local targets.

Journey to T-Shape team

t-shapeThere is a trend on the IT market to be software developer who has expertise in one specific technology (vertical line in “T”) and knows others at levels that don’t stop him from understanding a full code (horizontal line in “T”). This whole idea seems to help building cross-functional team, one of core thing in Agile world.

Currently the team that I’m working with has decided to try to become T-Shape one. There have been a few discussions how to tackle it, what should be assumptions and how we can manage dependencies. We have used brainstorming session to create a plan that all of us would support. Here is our approach:

  1. Create skill matrix to get knowledge what kind of expertise team has.
  2. Identify skills that should be strengthened.
  3. Verify in which directions team member would like to develop.
  4. Each team member proposes plan of skill’s development with clearly stated goals.
  5. Scrum Master facilitates and challenges progress on skills’ learning plan on monthly basis.

On top of this, the whole team has agreed that during transformation into T-Shape developer we still need to follow principles mentioned as below:

  • Each team member has main focus on core skill/-s.
  • We will plan how to grow individual horizontal skills during sprint planning so we could forecast more accurate sprint deliverable.
  • Each team member is responsible for his/her skill’s development.
  • Each team member seeks actively new ways of skills’ learning.

As you can see the team has decided to move closer to be cross-functional team in structured way, doing it step by step. Such approach gives them a chance to adjust it if needed and to validate their progress (see points 4. & 5.). Additionally it should help minimizing an influence on sprint deliverables. Keep finger crossed!

If you have any experience in creating T-Shape team let me know. I’m curious to find out how you have transitioned to it and I’m open for your advice!