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!