Team Space

In the beginning of the week 46 the Team moved into specific area in the office (free-seating policy). I noticed that very quickly people found their own place there. The whole Team has been sitting and working there - also I was there with the Team three days. Great start for the week!

I didn't see one of the Product Owners there but hopefully she joins later. I think I have not yet met her face-to-face at all. Or if I have I have not realized that. I heard once someone saying "she said that there is no room for her and that is why she is staying at the old place". Well - that was not the case none of those days I spent there. Just wondering whether she has something against "sitting in the same place".

In the middle of the week the Team had interesting discussions about the future. The Scrum Master is going to start his 15 weeks paternity leave in February. At the same time one analyst starts working four days per week and at little bit later starts her 3 months leave. Team size is getting smaller.
 

Scrum Master stated later that the Team is going to have "more than one Product Owner per team member".

When discussing who would like to be the new Scrum Master there were no volunteers. One though said that he will do whatever he is told to do. Someone else said that it is not job for all. One said that she has tried that and won't do that ever again. This might lead to situation where the new Scrum Master will be coming outside of this Team. It might be also opportunity if the new Scrum Master would be able to concentrate on to be the Scrum Master and others could be concentrating on their tasks.

I also participated the Sprint Pre-Planning meeting with the Product Owners. One of them was not unfortunately able to participate due to sick leave. (Yes - the same one I have not yet met.)  I was happy to notice that the Product Owners are really committed - they really want to be able to offer enough tasks to the Team and want the Team to be able to concentrate on the tasks belonging to the Team. They want to reduce the amount of tasks coming outside from other teams. How user stories or tasks (that term the Team is using) are brought to Sprint Backlog is still little bit unclear for me. That is something I should understand - otherwise helping the Team might be even more challenging.

Product Owners have good intention to improve their way of working by having common mailbox for issues coming to the team. Currently these are in their personal mailboxes and it is difficult to have in mind what is where. Before they get this mailbox up and running they are considering to create common folder and gather all stuff there.

Unfortunately I see them as separate Product Owner team - either inside the Team or as working sibe-by-side with the Team - but we have to remember that this setup has been up and running only for this Sprint and adjustment is going on. I asked how they see - do they have double "roles" being both Product Owners and Business Developes. Discussion was defending and quite challenging for me - I almost regret to even ask it.

I think this team does not see themselves as Scrum Team. They are group of people working together having "three Product Owners, two developers, three analysts and one tester".

I end this blog post with quotation from the Scrum Guide. Maybe this is exact the thing I need to discuss with the Team.

The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
. . .
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Opportunities of improvements - first try out

It is late Sunday evening and I just can't stop thinking my team. Today I was reading book Agile Coaching (by Rachel Davies and Liz Sedley).  I like the book because it is practical and that is exactly what I need: Practical examples like what kind of questions to ask, which options to try and tips on how to help teams - food for thought and inspiration.

When reading chapter "Introducing Change" and about picking one's battle I got an idea. I had so many challenges in my mind and picking my battle sounded like good idea. I sketched the challenges and looked at that for a while. Actually before sketching I wrote a long list of challenges but I realized that there were many things having something in common, kind of related to each other. And I manage to summarize it all to one small paper (size A6).

How should I pick my battle? Taking this to the team? Listening what the team is telling me - either by themselves or by me asking them questions? Or just picking one and start with it? I need to sleep at least one night and look this sketchnote again either tomorrow or day after that when I am back at office with the team.

I think it is good thing that I created the long list even I then summarized it. On the other by looking these big things I don't restrict my own thinking but  by having the long list I am able to do my own retrospective and see whether I have achieved value by helping the team with the challenges I have noticed.

Task for me for next coming week is to start informal one-to-one discussions with team members. I have had one-to-one discussion with one of the business developer/ product owner, very short 5 minutes discussion after team's Sprint Planning meeting. I was asking some clarifications for issues I didn't understand and I didn't even think at that time to ask questions which could have helped her to reveal challenges she is facing. After discussions I might sketch other kind of challenges.

As an observer in a team

Now I am in a team in role of agile coach. Or so they say but I am still not ready to say "I am agile coach". During this week I have been observing "my team" and trying to find out whether there is something to work with. Team is in my own organization here in Finland and I can spend my time as much as I want in their premises. I can be there where they are. Good starting point I think.

First meeting I participated was their sprint planning. It was their first planning meeting with current setup: 5 development team members in Finland, 1 tester in India and 3 (three!) business developers as Product Owners. Wau - that is interesting setup. And I just have to use this kind of separation of roles because they seem to make it themselves very clear.

Before this meeting I was told that tester never participate these meetings since they prefer to have them conducted in Finnish. This time tester was also on vacation so I am still under the impression that she is not participating. Also two out of three POs were on sick leave so from that angle I didn't get any experience. But for me it was surprise that there was "fourth business developer" from other business area. And so that things get really messy there was "fifth business developer"  who is going to cover one Product Owner during her maternity leave.

You can just imagine that how confused I was after the meeting. I really didn't have any idea how to move forward. But then I thought that I don't have to move forward - yet. I can be confuced for a while and if needed for longer time. So let's continue in observation mode.

Two days later I observed their daily standup. This time neither all team members were present but one manager visited this meeting. The setup was little bit bizar - even it happened naturally - four members of development team were sitting in the middle and others were standing around them. Only ones telling what they have done and what they will do were development team members and the impression was - to be honest - like they were examined.

I was horrified but I decided to take first contact with the team and had short discussion with some of the development team members after the meeting. Not immediately because I just had to gather myself and think what to say. And then I just did it. I went to them and said "Hi team - can we have short talk."

I asked them how I see and feel their meetings. Within few minutes I got feedback - why they conduct these meetings like they do, what they want to keep, what they thought could be tried to be done differently and also what have they tried already. We also discussed that maybe we could organize in near future "scrum refereshment" meeting.

Yes - I did it. No one died. Sky didn't fall. I have no idea whether I handled this good or poorly but for me it was a huge step. I took my first baby step to come closer to the team and really started my journey "agile coach to be".

Later on me and my colleague had a meeting with two "business managers" who originally asked our team to support them in their business area. I showed them my notes and asked whether they see that this kind of documentation would serve them to understand where we are. They were impressed (now I decided not be modest here) and said big yes. Later on I also shared these notes with the team. Let's see what they have to say here.

One thing I need to practice is my sketchnotes technique. I draw all the people to look angry and that is not my intention.

Lyssa Adkins - Coaching Agile Teams

In my team we had a dream: let’s start coaching agile teams. I am sitting in methods team in an ivory tower in our organization and we have not had real connections to our methods user. Now we are driving for more agile development in our organization and we saw our chance there.

 
One of my colleagues got a great idea: let's read a book "Coaching Agile Teams" and have study group around it. Yes - said most of us. There is three separate parts in this book and we took one part at the time. We read it in two weeks and then we met and discussed and reflected. After reading the whole book each of us were supposed to write a blog post or some other way reflect the book.
 

At the same time I get excited about sketchnoting. It was Ru who showed me some of her notes saying “I thought you might like this”. Said and done – I went home and started to practice. So it was very natural choice for me to reflect the book by doing my first sketchnotes.

Part 1 It Starts with You
Me having no experience on coaching and very short experience working agile - I had the feeling that I am now trying to bite off more than I can chew. I got stressed and desperate. I as a person will face too many challenges. And then again - let's try. Maybe my journey just will be longer than other's.

Part 2 Helping the Team Get More for Themselves
Even worse. This part was about different "roles" of coach. Like "Coach as Coach-Mentor", "Coach as Facilitator" and so on. I felt like I am facing high and thick wall. Every chapter started with summary "By the time you finish this chapter, you will be albe to answer these questions." Likewise every chapter ended with a refresher. Structure was good but the content was little bit discouraging for me.

Part 3 Getting more for Yourself
Finally I get the feeling that "Yes, I can do this". Journey will be long but I will reach my goal. The most important is that I have to merciful to myself. It is okay to fail and learn from you failures. Great book and I will be getting back to it certainly.

Now, I need to start my journey - somewhere with someone, either with a team or with  an individual. And I am horrified!