Try it out!

Proving a concept is very important step when jumping to something new. I like it and I often suggest it to Agile teams. Call it POC, Spike, Proof of Installation and Verification, these are details. The thing is that you try it, you see how it works and either you keep it, you build on top of it or you throw it away, it's up to results and to the final goal.
I know that in Chinese, you either do something or you don't. The word "try" doesn't exist. But I like to put an equal sign between try and do. While you try, even if you do not succeed or you decide to throw away what you did, you learnt something along the way.

Today I decided to do a POC on my wardrobe.
Until 6 months ago, I have worked in companies where people were not evaluated by what they were wearing. Some of the people used to wear one red snicker and one blue one. Shorts at work during summer were normal for boys and girls. Some of the designers had their hair coloured in bright red or green. I have always been wearing jeans, t-shirts and once in a while, when I bought a nice piece of cloth, I have dressed formal. This changed at my new work. This is an institution where people have a business dress code. There is an un-official Jeans-Friday and some of the people do wear jeans. I tried to do that but I was called and pointed out that I shouldn't.
Today was Friday and some people were on vacation. So I decided to run a POC and see how much of my morning time I would save by wearing jeans. It sounds like I was doing something behind the back, but things need to be proven!

Believe it or not, I made it to get out of the door 20 minutes earlier than usual!
Someone asked me: Why do you take 20 minutes to dress in morning? Well, let's say I like to look good. And if I have to look business like, I want to make business look good. This means I need to put some thinking into matching clothes and then the right shoes. Sometimes I have just done laundry and I have a lot of choices to pick. But when I wear jeans, all I have to chose is a nice top. Anything goes with jeans so whatever I chose it will be ok. The only thinking will be on matching shoes.
The other thing I noticed is that none of the people I work with (my internal clients) had a problem. Some of them were wearing jeans too.
So, in short, I tried and proved that by wearing jeans at work, I saved time in the morning. I felt comfortable during the day and nobody pointed out my jeans as a a sign of  being unprofessional.
That does not mean that I will be wearing jeans again. At the end, I accepted to work at this company and I knew from start that there was a dress code. Changing this rule is not a must at this point. There is so much more to do and this is down on the list. So it is a test that will be thrown away. The take away is " Wearing something easy at work saves time, and creates a more comfortable working place"

Talent needs backup!

If someone would ask me "What would you attempt to do if you knew you couldn't fail" I would pick different things from time to time.
Right now, I would like to: Upgrade the technology of my company, from "2000 and late" to "the latest of 2012".
I might have a good chance because the company is aiming to be a leader in IT. So, I started thinking, what would it take to make that happen?
Sure, some better process around how things are done, adding collaboration between different areas of the company, setting the foundation for Agile development, have a mind set of improving constantly and continuously on every area, they all help. But then it comes to a point where you need technology to support this momentum, to keep the desire going, to look beyond the necessity and to bring in innovation. What would it take to get there?

1. Good Development Machines
In our days, people are developing, building, deploying from their cell phones! Continuously! Technology is at a point where all you have to do is ask for it and it is all there for you. Price of machines and memory don't cost an arm and a leg anymore. Why do you skim on the Developer machines? From a revenue point of view, better machines bring higher performance and higher productivity. From the agile development point of view, they bring faster results and faster feedback. From the developer(read: geeky) point of view they bring joy, desire to work and, eventually innovation. To become a leader in IT, you need super star developers and super star network admins. Would be hard to find them! But then, if you do not back them up with the right technology and mindset to push the usage of technology to the limit, it would be the same as the Russian team on 1980 Olympics, http://en.wikipedia.org/wiki/Miracle_on_Ice.

Here the picture of the US team. THIS is what you want to see!

There is a whole bunch of machines that are lined up against a wall and they are called "The Lab". Those are machines where developers can download, install and test ideas. Guess what? They have the same problem as the Dev machines. The computers at my daughter's elementary school are better machines than those.VM can't run.Only Remote Desktop.

2. Permission access
Because of a bad negotiation on help desk support, Dev environment  have restricted access on their own machines. Things like no access to their C drive, not allowed to download/install/test applications that are not part of the default Dev image (or the support will be revoked!!), limited access to internal environments, etc. They have found ways around these issues, they have created shortcuts and downloaded cmd.exe (was missing from the default image!!). But why would you want to spent Dev time in hacking around for something they should have? The best place to put the $ when it comes to Dev time is Development, exploration of new techniques, upgrade of system architecture, test improvements, roll updates/upgrades.

Talent is hard to find. If you find it, you need to keep it close, keep it happy, don't limit it with old technology, old applications and old ways of controlling permissions.

When past experience starts to bring value

At this point of the transformation, this organization needs some Development growth attention. A lot has been said, explained over and over on the practices, work visualization, limiting the WIP, measuring throughput and so on. Now it's time to get hands dirty and talk CODING.
The last time I touched code is some time in April of 2009. At that time, I accepted the new role as Project Manager for Maya and Mudbox (2 GREAT 3D applications from Alias/Autodesk). The condition was that I had to close all the work at my plate at that point. My previous role was Software Developer (C++) and what I was developing the anti-piracy module that was linked with applications and made sure that nobody was running the software without proper license. At least made it hard to do so, because,we all know that in real world, anything can be hacked.
Since then, I have tried to clean up the shelves on my brain and make room for Project Management stuff, Scrum Master stuff,  Agile/Scrum/Lean stuff. I have to admit that Lean is the new Love of my professional life right now. But then, at some point, when the discussion comes on how to improve the development and delivery, I find myself still connected with my first professional love, development.
I am very lucky to have worked at Alias/AliasWavefront for 11 years. When I started there, I was pretty green into development thinking and practices. And then I found myself in the middle of a very smart, mature, passionate and intelligent group of developers and  network administrators. All I had to do is listen, notice and LEARN from their experience and maturity. That is where I have seen how a good team of developers is setup, works and delivers. Discussions were constructive, new ideas and experiences shared and welcomed, a very healthy competition between developers and a very helpful Infrastructure team that supported new ideas and positive improvements.
That is a picture that I want to take with me and bring it everywhere I work. That is the kind of environment I want to see everywhere where there are developers and network people working together. So when the transformation hit this need, I volunteered to be part of this project, Tooling strategy. I have to admit that getting back into development mode after so long, it is scary. But my daring and challenging nature always pushes me toward scary areas. so I can prove myself to myself more than to others.
In 4 days, I was able to setup my machine with the right environment, install Java 5 times, started/stopped Glassfish server 10 times, started/stopped MySQL server 6 times, ran ANT n times, deployed to Glassfish n-10 times, installed Jenkins 2 times, started/stopped Jenkins 5 times, ran Jenkins Build job 42 times, ran Jenkins deploy job 8 times. At the end, I had a basic example of Petcatalog, all up and running, automated build and deployment build all set.
It was 1:30 am when the deployment script ran successfully and a sunny icon showed up beside the Jenkins job. WHAT A FEELING!! Really proud of myself for a while.
And then, the next step is to move this to Maven. and then will be the addition of linking with WebSphere. And then... a lot to come.

Looking back in retrospective, everything I have done in my life, is gluing together in the Coach role.  Development is helping me to help developers, teaching is helping me explain things in a simple way, Program Management and Scrum Master-ing are helping me to translate Agile to traditional PMs, my personal interest in psychology is helping me model the way I talk with people and my personal experience as a mother helps me forgive everyone frustrated with the transformation process. 

I feel that merging all these together will be the key of my role. I just have to get very good at it. Lots of road ahead of me, and it is NOT on a dark tunnel!

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!