Motivated or CTOs?

Lately, I am meeting a lot of people that see themselves as CTOs, meaning Chief Troublemaker Officer. When I speak with them, I sense they are motivated, with a lot of energy or drive or innovative ideas or desire or all of the above. Nevertheless, they have a sense of being the "black sheep" on their teams. Usually they think that their managers see them as "people that complain and bring bad vibe to the rest of the team", or "people that live in a bubble and don't understand that things are done in a certain way".
So what to do with these people?

For some managers who control humans, I can see how some of these people are CTO. They are the ones that question decisions, bring up issues, come up with ideas after something is decided, want to try new things when a decision is made on how to execute something, point out issues and make even other people on the team think twice before agreeing to do something or how to do something.
For some other managers that know how to control human energy, I can see how they can use the drive, desire and motivation of these people to create an environment where ideas are welcome even late, where passion and desire is understood as first step toward innovation, where they can use these people as examples to pull and lighten up other people in the team that are more reserved and quiet.

So, the management style does affect these people a lot. Under a manager they shine. Under another manager they are troublemakers. When seen as troublemakers, they usually close up, shut down and check out. They might continue working and finish tasks, but they are just your average employee, with a lot of potential to be a star employee. Who is an outstanding employee, anyway?
Is a motivated person an outstanding employee or just a troublemaker?

To go back to the management style, an outstanding employee might be someone that follows rules, executes what is told, once in a while has good ideas, respects hierarchy and respects others in the team. For another management style, an outstanding employee is someone that looks forward to challenges, is always in touch with the latest of the industry and wants to bring it all in the team, questions decisions in order to make everyone think of the best decision, has open attitude with others in the team and doesn't try to play nice  but rather play strong.

These people are high risk, in the sense that they are talented but when they don't see themselves on the right place, they move on and you lose talent. One trick to lower this risk and keep them around is to keep them motivated, interested and focused on what they like to do even when they feel they are not appreciated. Communication techniques are very helpful here because they might help re-position them in front of their managers. Just by changing the way "the Trouble" is introduced, results might be different. It is important thought to start these healing techniques early, on the first sign of feeling a CTO. If it doesn't get taken care of, just like any other small problem that gets repressed instead of fixed, it becomes a big issue and sometimes not fixable. Humans are easily broken and relationships sometimes go to a point of no return and require drastic changes.

I read somewhere that 60% of the issues in a relationship are unfixable. You think you fixed them, it is all good for a while, but then they come back just like before. By switching to another relationship, you are just exchanging a set of 60% of issues with another set of 60% of issues. Make sure you pick a manager and a team that gives you 60% of the unfixable issues that you can handle. Try to work on your communication skills and stay motivated until a better solution comes easy to you.

2 of my favorite tools

As a person that I have to work with all kind of people on all kind of roles, I have to come up with the right technique or tool at the right time. But just like any other handyman would tell you, there are some tools that are always with you and then there are some other tools that you know you have them but you need to go to the shed and dig down to find them.
The 2 tools that i have been using lately a lot are:
1- Ask "What is the acceptance criteria?". I am finding it amazing how many times I see a team working on a project where everyone understands the goal but very few can articulate the acceptance criteria. Sometimes, nobody. I am finding it very important to get the people to stop and understand what is that thing, that result that when reaches a specific value, we can call the project "Completed successfully". When they do stop and find this, there is usually an Aha moment and I feel my job is done

2- Circle and Soup exercise. I did write a blog before about this but I want to point it out again. It is very interesting to see how an issue is right away set to an outside circle but then when discussed and understood the actions to take, starts moving slowly toward center. It is very good to remove the "victim" stance and feel more in control and powerful on actions.

Finding the True North for Quality Management

My official title during the last year has been " Quality Management Office Analyst". There are different interpretations to it. The word "Quality" does not help because the first thing people have in mind when they hear that word, is "Quality Assurance". When we say "Quality Management", we mean Processes, but it is like saying to someone "Don't think of an elephant" and actually expect that they won't have an elephant in their mind. I am saying all this because we have been struggling for a while to come to a consensus for our team Vision. We all seem to want the same thing and create the same target system, but someone is always coming up with a different variable that when injected in the previous system, it changes the target system. Is related with the theory of system hacking I guess.
On our team site, we have this blurb where we have tried to encapsulate what we are trying to do:

"Our team is devoted to support continuous improvement in (insert here company name) product delivery.Our goal is to improve customer satisfaction with reliable and predictable product deliverables."

 

I guess it is not bad, but there is something there that doesn't make me (and some other people on my team) happy. We can't call this our "True North". 

Last week, I was trying to pick my next book to read. I had two options, Toyota Kata and Management 3.0. While debating over them, Andrew Annett "pulled" me toward Toyota Kata. So, that has been the book I have been reading during the past week and I am somewhere in the middle. For all of you out there that have read this book, you know where my mind is right now. I am now in the process of comparing how we are doing things now in our company, and how Toyota is doing them. I know that Toyota is a Manufacturing company and we are an Insurance company. But Toyota's strength is not on dominating the Manufacturing market. Their strength is on the way they think, and that is a feature that is independent of the market, independent of the service, independent of the product that a company delivers. 

This way of thinking, is drawing me back to the Vision of my team. I guess the easy thing is to take Toyota's vision and apply it to my team's:

Toyota: "Survive long term as a company by improving and evolving how we make good products for the customer"

My team: "Live long as a team that improves and evolves the process delivery of the company"

Although I know that this is just a draft and some cosmetic patting is required, I am still not happy with it. The problem is that we are looking at our team as a permanent team in this company, without an exit strategy. I know that a company needs continuous improvement and from that point of view, I can say that we should always be part of this company. But that statement gives me a sense of failure, not able to ever celebrate success. Makes me think we will never reach a desired target state, because there is always something to improve.I think that part of the continuous improvement is also the fact that my team, at some point, should not be required.

And that's where I got a Eureka! moment. Rather than adding to our Vision what we want our team to be, I thought to add to our Vision what we want the company to be. So, again, in a draft mode, fully aware of the need for cosmetic changes, I came up with something like this:

"Get (insert here company name) to a state where Continuous Improvement is natural element of the Vision of the company and all the structures in this organization"

I am happy!! Why am I happy with this?

I like the fact that we have:

• An end goal
• A way to measure the  Success Criteria.
• A clear set of Recipients that will run with it, on their own, with a clear understanding on what to do
• It's recursive (ok, that's the geek in me!)

I like the fact that we want to create a Sustainable System, where the need for improvement will be organic, not injected from my team or any other external team. The mindset of Managers at any level will be on the Continuous Improvement of the current process, whatever that process is at any point of time.

Now let's see what others think. Feedback appreciated!

Deming's right!

In an environment where teams are not stable and people are considered resources, all the focus of People-Managers is how to juggle around people from one project to another project or to a Severity 1 issue with Production. It gets complicated when you add here roles like Project Managers that have tight deadlines to reach and they have planned to deliver with a certain number of people assigned to their projects. So a conflict is inevitable between these two parties.

On one side you have Projects Managers, with 100% focus to release their deliverables. They have all the training out there (minted by a lot of certificates and organizations with big names and high prestige) to protect the people on their teams and keep them focused on the most important stuff. They have a "big fight" at the beginning of the project to get the right people on their projects and make sure they are allocated 100% or at least 50%. Once they "won" that battle, then they move in protective mode, where they must make sure that these people are not pulled onto other tasks. In some cases, they are so protective, that even when the people on their team are done with their tasks, the PM doesn't let them go, just because they are assigned 100% to that project and there might be some defects coming up. .

On the other side, you have the People-Managers (for developers, testers and analysts), that are faced with all the  requests for what work needs to be done, and they should allocate their people to the right projects and at the right percentage of time, as per their skills. But when another project comes up, or a Severity 1 issue comes up, they are left with the need to ask for someone to put a project on hold and get to this new task.

So the "battle for people" begins. A person that is promised 100% to a Project Manager, can't be pulled to another task. Even if that person is done with the project. The definition of done is a grey area, especially when testing is not done right after the developer has submitted the code. This gives the PM the right to keep this person assigned to his project in order to take care of defects that will be found. But the People-Manager can use the time of this person on another task, until defects are found and prioritized.

Guess what the people feel like?
One synonym I can think of, is like a child that is being pulled on the left arm by his mom and on the right  arm by his dad, while these two parents are fighting with each-other  and are telling the child "I love you more, stay with me".

Nobody is asking "What does this person like to do? In what direction does he/she wants to grow professionally? What is a task that would bring excitement on this person's career?"
So on a setup like this, looks like Deming's brilliant phrase : "A bad system beats a good person all the time" is very true. They are all good people. They're all focused on their goals. All of them want to succeed. But they are all trapped in this environment where people are allocated by time and not by task. Teams that are created for a project rather than bringing the project to a stable team. Environment where trust and collaboration does not exist because the common goal is not clear.  Environment where deadlines are set without asking the people that will actually do the work. Environment where it is not safe to call out a project that is going downhill because it is consider as failure.

I don't have a quick fix for that and I don't think it is an easy one. But rather than try to work with PM and People Manager on how to manage the people better, I'd rather take the long and bumpy road to fix the environment that creates these issues.

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.