Repurpose of the Soup exercise

I love it when I can make something useful even more useful. Maybe because efficiency is big for me.
I am working with a team that is in need to improve the client service response and quality. There is an internal team and a couple of vendors outsourced. Of course, the outsourced teams are the ones that deal with phone calls and ticket opening while the internal teams are the ones that actually solve the issues. Their purpose was to slow down the "noise". I suggested calling it "waste" and they seemed to connect better with that :)
While a lot of info is being collected on what the waste is and where the waste is being created, they needed a way to organize them so they could create action items for their team and for the vendors.
Circles and Soup came in my mind.

I have found this technique while back when I was looking for ideas to organize retrospectives in fun ways. But I have to admit that I haven't used it much in retrospectives. In this case, I thought this way of organizing the information might give a sense of how much the internal team has in full control and influence, what issues are lacking one of them (they need "friends" to influence)  and what is out of their control or influence.
After talking about each "waste", they  organized the stickies in the circles like this.

During the exercise, I noticed they were involved but couldn't get a sense if it was being useful to them. At the end, I was waiting to hear their comments, and feedback and I was happy to hear them saying: This was a good exercise! Looks like we have more control than we thought. Now let's plan what can WE do about it before we reach out to our "friends".

Notes from Agile Tour Toronto 2012

Yesterday was Agile Tour Toronto. All my team planned to be there. Some were presenters. The rest just spread on different sessions, as per our interests.
The key note from Jim Carroll (http://www.jimcarroll.com/) was pretty good. The take away: Things are changing so fast, that being slow is what leaves you behind. Science, researchers, health, auto, credit cards, retailers are pushing the bar everyday. Nest (the thermostat with IP), Square (the credit card payer from smart phone), the DNA reader that can tell you what diseases you have a high chance to fight, Google interested in car market. In a nutshell, keep an open mind that in 2 years, you might be doing something that does not exist yet.
I went to 3 sessions. One about the Lean data architecture (ETL? Why? Reports on the fly!). One on TDD with Lego (Bryan rocks! Was a really fun session and that guy is Energizer bunny!). And one on Bounded Context (DDD)  that was an example where they put the developers in each of the bounded contexts of the big schema.
I have to say that I left the day "thirsty" for something new and energizing. I expected the crowd to be more outgoing, exciting, funny. Rather was serious, pushy individuals marketing their services/books/upcoming seminars, and sometimes even just plain dry.
The good thing about it is that after seeing all that, I felt like I was part of something really cool going on at my company. We are using a lot of the concepts that were presented as new and we actually have also improved on some of them.
During one of the breaks, there was a "Lightning talk" session, a 2 minute talk where you can say something about what you are doing, something new you are using that is giving you results or just something that you want to say in the context. There were about 5 people that had signed up for that. I was sitting beside Jason Little that just came back from his classes in Finland and Estonia. He sat for a moment, turned to me and said ; "What's your lightning talk?". I was caught like a deer in headlight. Then he left and he signed himself up, and had a very cool improvised talk about hacking the culture of people and organizations. I thought; Well, he has so much to say after all he has done! But then some others started jumping from their chairs and just went and talked about something.When I heard someone taking about retrospectives once again, I said to myself "You MUST have something to say!". So right there on the spot, I  challenged myself to say something from what I have done so far. Right when they were asking for the last one, I just pinched myself to get up and had my first lightning talk. I was sort of shaking, probably my voice too. I do not remember exactly what I said but what I wanted to say was:
Recently I took the ACP test and when I left the room, the girl at the front desk said to me: "You should be proud of yourself for passing. A lot of people are coming lately to take this exam and unfortunately they are not passing". That made me think that a lot of people think they know all about Agile. On the other side, I am part of a big transformation where I am working with some smart people that have a lot of experience and expertise, and compared to them, I feel like I have so much to learn.  So just like the takeaway from the keynote, keep learning, be fast because things change and there is always a lot of new things to deal with. Everyday we find something new that pushes us a bit further.

I am not sure if I was able to put my thoughts together nicely and get my point through to the people in the room. But the whole point of that was me pushing myself to speak in public without being prepared. Me pushing myself to speak in public about something mine, different. Whooa!
I think I will volunteer next year and try to make that event a bit more exciting. People should leave energized and smiley.

From a deck of Business requirements to Automation testing

Lately I have been heavily involved with preparing BDDs with BIAs and then entering them to Fitnesse as Scenarios with testers. For both teams, these concepts are new.
BIAs, in some cases, are taking BDDs as "Forget what you have learned so far on how to do your work and start doing them in BDD format". In some other cases, they see them as "too technical" when combined with scenarios (test cases). Then, in some other cases, they are saying that all they have to do is "small enhancements" so writing BDDs is not necessary. I had the chance to run a session with them and explain this. I started with the Story Map and explained that as "10K feet view". Then, we zoom in to "1K feet view" and look at MMF (Minimum Marketable Feature). Then we zoom again to "100 feet view" which is one of the stories and finally, zoom really close to a Feature. How do we explain what this feature is? We write requirements! How do we write requirements? In a way that everyone in the team (BIA, Developer, Tester and Client) understand. What would that be? As simple as possible, make it a picture, a drawing, a sentence,  whatever helps you explain but keep it simple and meaningful. Suggested: BDD.
Why BDD? Well, one benefit is that it can become executable, testable. There are different apps for that. One easy to grip on is Fitnesse. Others are more advanced but even more complicated to setup. Since we have a lot of Web testing to do, Selenium was a must. So found a way to connect Fitnesse and Selenium and have one entry point, Fitnesse.
Now we had to prove that a BDD can be executable. So we created some Fitnesse pages for different test cases and tried to "sell" it to BIAs. That didn't go very well. It felt like they had to write scripts, program, develop. It also felt very technical in the sense that they had to put together numbers and create cases of what to enter and what to expect, something that usually is done by testers.
We learned that our BIAs are not ready to write anything that is not pure English (wiki language that Fitnesse uses does not fall in pure English). We learned that our testers at the beginning were scared that Fitnesse will replace them, but after, they didn't like it that they had to write test cases and then change them when ideas were changed.

One thing we won, is a place where we can send testers and BIAs to see how requirements look like when they are done well, with testing in mind and when people work together. All I can hope is that now that they know how the end looks like, they can start a new project in the right way, they can do the right thing at the beginning.

Kanban in traditional environments

I was reading this article in Forbes, that created a lot of etraffic:
http://www.forbes.com/sites/stevedenning/2012/09/25/what-exactly-is-agile-is-kanban-agile/
It is an interesting point of view and I can't say he is completely wrong or completely right. I like the comments a lot, because you can see how some of the Agile community members responded or tried to clarify some areas.
I was trying to figure out how Kanban is helping my current company to move to Agile.
No longer than today, while I was on a meeting with one of the teams I am coaching, I heard ideas like: We can consider a feature done when developers are done, since testing env. has issues. Or the need for consistency on how teams function and consistency on roles on all projects. I know some other project teams decided to cancel daily standups in front of the board when they were in the last sprint to release a project that was running late.

This reminded me the point this article was pushing when saying that "...Kanban is a set of practices that can be implemented even with traditional culture of command-and-control hierarchical bureaucracy.  It doesn’t necessarily challenge the existing culture. It can work within the existing culture, whatever it happens to be."

If I had chosen to agree with the solutions my team was trying to have, would I still be implementing Kanban with them?
Well... the work will continue to be visualized.  WIP will somehow still be limited for developers, and will be 0 for testers. Throughput will be split between dev throughput + test throughput + defect fixing throughput. For a traditional leader, this would be ok. The reports on the project status would probably be something like:
"Developers are progressing well and 80% of the work is done. Waiting for the testing to start when the env. is ready for us. Business is being kept in loop and they are ok with the current design and flow. There is a problem with the testing env. but we are trying to start testing 1 month before release in order to have time for defect fixing, business verification and deployment to production. The project is Yellow"

But would that be ok for a Kanban leader? The report would be something like:
"Developers are working and there is a big QA debt created. Due to the fact that the testing env. is not setup, none of features done by developers is tested, not even smoke test. The team was supposed to deliver 1 feature/week and we are already week 6 with 0 delivered. Business is giving feedback based on mock ups from designers and not the work done. We hope the design will not face issues when developers will start working on it, since we don't have a design B to fall back. Since this is a new team working together, we do not have historical data on the return-of defects per feature. This means we can't predict the amount of defects we will face when testing will start. Testing is not automated so it is expected to be slow. We will be asking Business to work closer with us while we start testing and prioritize defects. Do not have their commitment on this yet....Project is bright Red"

So, although I can see how Kanban can be used in a traditional company, I don't think it can be successful if the people that read the reports will continue to read traditional status reports. It can't be successful until people measure Success in a traditional way. It will be just another case where traditional leaders will expect to "be Agile, deliver earlier and cheaper" but, when will face the need for "Business to be involved frequently, testing should start early, developers should not pile the work done", they will call it "yet another failed Agile project".

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!

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!