Don't meet to dump a lot, but to solve something

I have noticed that every Thursday, when I go home, I am restless.
Not a good restless tho'. My right and left sides of the brain are in a constant wrestling mode and none of them wins until around Sunday. That's because by then, I have had enough morning sleep on Saturday (no need to catch an early train) and because usually I meet with my friends and I find a way to relax in their conversations. This makes me forget Thursdays, and makes me start Mondays with a more chillaxed stand.
What is going on on Thursdays? Our Team meeting!
There are 3 choices we have had so far for our team meeting format. The standard one, retrospective one and the lean coffee one.
The standard one
- A long agenda presented to us with updates on what higher levels of management are asking for us, doing on their side and company wide updates. Then a round table where everyone talks about their areas of influence, the teams they work and if they have any issue to raise. And then we all noticed that 1 hour or more has passed and is time to wrap up
The retrospective one
- Anyone familiar with retrospectives knows how this is done. What you don't know is that there are tickets that do not make it on the board because someone already has an answer or even better a solution for it!! No need for discussions.
The Lean coffee one
- Anyone familiar with this style should know how is done. But this style either has the same luck as the retrospective style, or, is left as an option "Time permitted", at the end of a Standard meeting.

This has been going for 6 months.
By now, some issues from 6 months ago have found a way to be solved in a way or another.  Some not. Meanwhile new issues come up but they do not find time to be discussed or solved  on our team meetings. If I go back, I can find a lot of issues un-resolved, outstanding and still a problem for the team.
I decided to create a backlog of all of them!
I went to our online tool and created a project. Send a message to my team and asked them to create tickets. Assign the tickets to someone and move them along as they progress.
This is not our Team's backlog of things to do with the teams we work, of lean/agile concepts we are planning to introduce, of project tracking progress, etc. We have a board for that already.
This is our team's meeting backlog.
This is where we will discuss the issues we are concerned about, our Vision, our plan to roll out a new strategy, etc.
So when we meet, on our Thursdays, in stead of just bringing new issues, feel bad about them, hear contradictory directions, we look at the backlog and pick that 1 ticket that is the most painful point on our immediate future and solve THAT one!
Right now is :Define our role in this organization! It will be a good one :)

Feedback me!

While busy working with different teams, either in groups or 1:1, all I can think is how to bring my best experience and make a small (or big) step towards how they think, work, collaborate. Most of the times we are so busy on focusing on fixing something that we forget to see what we have done. I know most of you will scream back to me "That's why you have Retrospectives". I know that, and I do use retrospectives as the place for them to stop and think about what was done right, what improvements were done and all that good stuff. But retrospectives are the place where the team brings their feedback for themselves, what they have seen, what they think, what they feel. Until now, I haven't gotten time to actually stop and point out something good they do, as they do it.

One day, while my team was having the standup, someone made a very good comment about what one of my team members was doing. Without any ill feeling, I started thinking, why wasn't I getting any similar feedback? And I clearly asked "Why am I not getting any of that kind of feedback? Am I doing something wrong or am I working on difficult projects/teams?" Suddenly, I did feel that the person that gave the good feedback, felt bad. And off course, right after the standup, he came by and he did mentioned to me that I was not behind, I was also doing a great job. I felt like a kid that goes home and says "The teacher like Jimmy more than me". Was not what I was looking for. I wanted to know why I didn't earn that comment.

Just like me, everyone wants to hear feedback, especially good feedback. I believe is Anne Klein that said once "Imagine everyone you meet, has a sign on their neck that says "Make me feel important"". Sometimes it is hard to give good feedback when you are so focused on the issues, when you are so focused on getting people to find time to do something right rather than continue doing it over and over again same way with the same results.
Well, last week I decided to stop and tell my team that they are doing a lot of good things. I guess they were doing them but they were not able to connect them with the skills/behaviors we have introduced them, Kanban/Agile tracks, specific skills and behaviors, all grouped in 1 sheet called Character sheet. I wrote to the team this email:

Hi everyone,

I wanted to share with you some of my observations while I work with your team. Acting as an Agile coach for your team, I want to notice your improvements and your achievements toward Agile skills/behaviors.

-          Creating a system to track the "small" tasks. The fact that you thought about these tasks, setup a system in your board to track them, and most of all, you are using this system, is a big step toward Participation and  Transparency. ("Visualize all work ", "Create work tickets according to identified work tickets types ")

-          Working with UAT to synchronize the testing and with Change Management. I do see you are putting efforts into letting Testing team know when something is coming their way. There is still work to do regarding planning and following up with their commitments to Testing dates, but I think you are doing the right steps toward setting up a system where you hand off the work to Testers in a predictable way. This is one of the areas on Relay ("Synchronize handoff without delay").

-          With the new non-paper board in place, you are now planning to build a new board and organize your work in a more meaningful way for your team. This is part of the Design skill ("Design & build new kanban system") and it is a sign that the team is understanding the goal of the board and is maturing to the point to take ownership of how the work is visualized.

-          Another area I see this team improving is Flow ("Facilitate stand up - basic" , "Discuss WIP violations – mitigation / improvement plan"). The rotation of facilitator, the update of the BTS board with the work that is done during the week, the fact that WIP is raising brainstorming discussions, all these count toward you moving to the right direction.

-          For the people that are working on projects, I am sure you have been introduced with concepts like "Decomposition", "MMF", "BDD", etc. These are all skills that you are learning and  they are part of the Requirements track (Agile).

What else am I missing? I am sure you are doing more than this. I would like to encourage you to have another look at the skills and behaviors (attached) and update your character sheets. Soon we will have another retrospective and I would like to know:

- What have you improved on?

- What is the area you want to improve more but you are facing difficulties with?

Great work so far, looking forward to more!

Not only I heard some people from the team telling me "Thank you for that, at least we feel we are doing some progress", but when I forwarded this to the rest of my team as an example to energize a team, I got a lot of good feedback, even from some that have a hard time to admit the success of others. I earned the skill  of "deliberate and explicit feedback by using specific examples".
Yeay for me and for my team!

Why are we here?

As a new team of Agile Coaches, we are in the process of creating our Vision and Mission, the message we send to the other teams, mostly our clients, on what are we here to do for them. During the discussion, the business need came up, more specifically:  "Our IT team was not delivering, that's why we created this team". I thought about it and although I understand that the delivery problem triggered the need for change and the birth of my team, I think there is more to this.
From my point of view, my team was created because " the IT team was not delivering AND this IT team decided to become Lean/Agile".
Recognising a problem, being strong enough to bring it up and make it visible, is the very first step an organisation can do in order to improve. I say "strong enough" because it takes a lot of guts to admit the problem, to admit that somewhere down the road you have made a wrong choice that right now is proving to create some roadblocks.
Some decide to hide it. If you hide it and you try to patch it, maybe you will be able to fix it without others being aware of this problem, without others knowing that you made a mistake. We are humans, and we are evaluated based on our wins, not our mistakes. I know that someone said "I learned so much from my mistakes that I am thinking to make some new ones". But in business, a long trail of mistakes is not on your side when it comes to choosing the next leader. Because of this fear and this thinking, we can go deeper and deeper in defending the first mistake; we make more mistakes. For how long? Nowadays, usually you can't go on like this for too long. People are educated. They read, they are in touch with business, they are in touch with the latest technology and practises. You can't keep people blind for long. They will either leave you (and you will end up without the required talent to run an organisation) or their commitment level and energy will fall down (as result the productivity falls down). At the end, you haven't fixed your problem, you are elongating the trail of your mistakes and you lost some talent or they are bored.
Some others decide to fix it. As my manager reminds us often "There are different ways to skin a cat". Usually, you do not have the luxury where business/clients come to you everyday with a new "cat" and ask "How will you skin this cat today since I didn't like the way you did it yesterday and the day before? I am willing to continue paying you for experimenting on this." So, what to do?
You need to come up with a strategy, with a framework and with the right support for these.

The strategy will help you focus to where you would like to go, how do you want this problem to be in X months (10% less, 50% more client returns, 30% customer satisfaction, 20% increase on ROI, etc, etc). And then you decide on the framework.

Maybe it makes sense to close the door, sell everything and start something new.

Maybe it makes sense to fire some managers, hire some new ones that are presented to you as "rock stars" and give them X-y months to bring some improvements.

Maybe it makes sense to stop offering one of the products and hammer on the other one that seems to be successful.

Maybe it makes sense to hire contractors all over the place and tie them on short leash with some heavy duty PM.

Maybe.. there are so many maybe-s you can come up with. But you have to pick the framework for you, the one that will make sense to your strategy, the one that you see fitting, the one that you see beneficial for a long term. And frankly, I am glad that in the sea of options out there, my organisation chose to become Lean and not something else (like RUP, or SixSigma or ..). Why am I happy?

Because my organisation is in public sector and as a tax payer in this province, I am happy to know that $$ is not wasted in long processes, old management styles and pre-historic expensive technologies. Because I do believe that agility is the key in today's business. I do believe that long are gone the days where IT can operate in long term plans and put down daily fires without making any change to the ongoing projects. Because I believe that people want to improve their career skill set not just in technology but also in business and management. I believe that it is time to consider everyone in the team as a "partner" and not just someone that will do what manager says and how the manager says.

And that's why my team was created, to support this strategy and this framework. Had this organisation chosen another way to "skin this cat", someone else would be doing something else right now. Someone else would be taking this organisation to a different way of thinking, different processes with different values.
While my team is working on the Lean/Agile framework, we are taking this organisation to new processes, new ways of thinking, new ways of collaborating, new technology and IT craftsmanship. While we are doing all this, day by day, we are creating an environment where the same people that were here 6 months ago, will now start delivering IT projects. My team will NOT deliver these projects, my team will not commit to business requirements, my team will not be executing the projects using new tech tools and issue tracking systems. The people in this IT organisation will do all this, the same people that before, in another framework, could not satisfy the business needs.
So, my team is here "Because this IT organisation wants to start delivering IT projects, and they want to deliver them in an Agile way, using Lean practises"

The steps of Mastering

Reading Lyssa Adkins' "Coaching Agile Teams", I read something that helped me understand what I was trying to explain to myself without success.  And this happened just as Lyssa says: 98% of the times, opening a book at a random page, you might find something that is related with what you are going through or preparing for.
She said: The steps to become master at something are "Follow the rule, Break the rule, Be the rule".

During my martial art classes, I was taught this concept but I didn't really grasp it because I was not competing with my Sensei in becoming a Karate Master.
When I started my new role, I thought I am in between Breaking the rule and Be the rule. But there are two groups that expected from me other things though. One team, the experts hired to kick off and get the ball rolling, expected me to Follow the rule. The teams that I was working with, expected me to Be the rule for them. If you notice, nobody expected me to Break the rule, except myself.
I was struggling with fitting myself into this until I read the steps of mastering at Lyssa's book. It makes sense and I Get It!
Once I understood this, I can position myself better and I know at any point where I am and what others are expecting from me. Once I know their expectation, I run an "intention check" technique and I am not irritated anymore. I just know what they expect. I also  know what I can do.

Breaking the rule doesn't have to be noisy and leave behind a mess to clean. It can be done nicely and on a win-win output!
One lesson learnt!

Break your shell or you will stay small

Your pain is the breaking of the shell
that encloses your understanding.
Khalil Gibran.

I loved this image when I first saw it. I stayed for a good couple of minutes just looking at it. Something inside me found a visual way to express itself. And then the words of Gibran just gave mass to it.

It is really painful to break your shell. You have been in that shell for a while, you are comfy, you know where the cracks are so you don't put too much weight on those areas. And then someone, something, somehow, tells you that this shell's got to go. Crabs, when they loose their shell, they go around to find a bigger shell and make that their new house.
Where will you find a new shell for your naked inner self?

As part of the QMO, we are Kanban-izing a Government company that has been in business for a long time, executing and delivering in a very heavy process way and with a lot of people that have been there since the early days. A lot of the systems, solutions and applications used, are their "babies". They had found a comfortable zone where they knew what was expected from them. The hierarchy was clear, they knew who they had to listen and obey. They were releasing applications, keeping lights on and they could see themselves busy for a long time in that system. Busy for a long time, means feeling secure that this job is mine till I retire and I will get the good pension plan I have been waiting for since I started working here.And then, a new CIO came on board. Unable to understand the workload, unable to justify the expenses, he asked for a better way to run the shop. He asked for that organization to grow. 

And that is when the shell started cracking open. Just like with any growing pain, there was a lot of pain with breaking this shell. Some people were let go and that brought a lot of insecurity to the ones that stayed. A lot of people didn't feel good to see their long time friends dealing with "job hunting", a problem they thought they would never need to face. On the same time, they had to pick up some of the work that was being done by the ones that left. On top of that, a team of contractors was hired to "Change the way things are being done". Without any doubt, the spirits were down.

And that is when a brand new team was created. My team, the QMO. We are all new to that company. We have no ropes to hang on to. We are the ray of light burning the eyes of someone just coming out of a long sleep.We want to make friends and take them on a journey where we know the direction but we can't pave the road for them. The road will be bumpy and curvy.

Just like them, we will grow too. We will move from one shell to another without even understanding when and how these shells were created around us. We will know we are doing a good job when we keep feeling the pain of growth. If we do not feel pain, we have created a shell that's got to be broken.

Today, on a retrospective, a senior developer challenged me with "We have tried before different things like Pair Programming and stuff, but our managers told us not to do it. You want us to be Agile, ok, just tell us what do you want us to do and we will do it!". Off course I couldn't start laying down the roadmap for him in that retrospective meeting. But that told me that even though he was hurt before, even though he is not happy with everything that is going on, he WANTS to do it. He tried before when he didn't have support for this. He will try again, but this time he will be supported.  All this shell cracking noise, is music to my ears! 

Why this, now?

Blogging has been a way for me to get things out of my chest and move on. I have always been the kind of person that does things but doesn't advertise them. In a way, I am under representing myself.
Even with this attitude, I have constantly evolved in my career. Moved from web developer to anti-piracy developer. Then moved to project management and decided to stay agile to it. Tried Scrum master and when I was thinking that maybe Product owner would be my next move, I landed on a position that I didn't think I could do. Not that I didn't have the capability for it, but because of my self under evaluation. It came slow to me. First someone introduced me with the idea of being an hands on agile coach, work with a team that had been trained to move to agile but was struggling to remain so. They were fascinated when I asked "Are you Wagile?", meaning Waterfall in small Agile iterations, something they were not able to put together in one word to explain their pain. But at that time, I was at "I can't do it" step.

And then later on, when I was warmed up with the idea and I had moved to "I can do it" step, I accepted to start a job as QMO Analyst, which in simple words means Agile coach. I was that pumped up guy you see going up the "I will do it" step, all full of energy and ideas!
Instead of moving one more step ahead and start  jumping up and down with joy, I am finding myself going back and forth in the steps between "How do I do it?" and "Yes, I did this one!!"

I remember that once, when I was thinking to move from development to project management,  Larry Philps, an IT director that happen to be one of the smartest men I know, asked me out of the blue: "So, what do you want to be when you grow up? :))) A developer? A project manager? A people manager? :)))". I was over 30 but it was the first time I actually found myself thinking about it. Since then, I ask myself this question all the time. When I am on an emotional or professional crossroad, I sit down and ask : "Self, what do you want to be when you grow up?". And that helps me choose a path.

Everything I am learning during these steps, is helping me to grow wise, not just professionally, but also as a Humanoid in this planet. My journey has already started. Hop on board with me if you want to hear what I learn or if you can help me with advise!

ALLLLL AAAAABooooooaaaaardddd!