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!