statcount

Wednesday 28 November 2012

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".

Tuesday 27 November 2012

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.


Saturday 3 November 2012

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.