Meeting Protocol and Context switching games

My team is going through a big integration stage and it is showing to be really complex situation. A lot of people are involved, they make plans and have meetings.
I am seeing a couple of problems:
- Meetings becoming a big waste of time
- Everyone multitasking

So we had a Lunch&Learn today and I played two games. One of them, The Meeting protocol, is something I came up with Gino Marckx, after his "Core protocols" session he had with the coaches last Friday. I put down here the plot and personas we came up with. It ended up really fun and they actually thought that Alignment Check was a good idea. Check-out did feel a bit rude for them (!) so they think they should rather say "I am ok now and got what I needed out of this meeting " not "I'm checking out". Also, when someone starts using phone or laptop during the meeting, they either say "I'm checking out" or someone will ask "Have you checked out?".
One thing was interesting during the acting. The guy that picked the Martin persona, did not get on the role at all. He continued being himself. So someone else jumped and asked: Can I act your role?. They agreed and I have to say that the second actor did a better job at the end.
According to some statistics about meetings, they have found that 55% of meeting is dominated by 2 people. This was really clear, Mary and Sam were constantly talking while Barb and Jane were more vocal during Alignment check. So Alignment check is a good technique to get the feedback from the quiet people during the meeting.

The other game was the Context Switching game.  We did not have much time for the Context switching so we played only the multiplication by 3 and Alphabet (skipped the multiplication by 5). I think even that was good enough to bring up the point and see the time spent between switching the tasks. It felt painful for the non participants to see how much the participants were trying to get back to where they left, so they started helping! Still, some parents with teenagers, think that listening music and doing home work, might not be bad. Maybe. At the end listening music does not request your envolvment/response/act on something. It's between texting and studying that the problem is. Let's see how this game will be received when they go home and play it with their teenagers. At least, parents are getting some learning out of it (and that's what I really care :) )

At the end, everyone enjoyed it and I heard one comment saying "This is the most fun I have had since I started this project"

MEETING PROTOCOL GAME

Plot:

Will ask for 4 people to volunteer and pick one piece of paper where there is a profile of the person they will act. Will give them some time to read their personas and answer any question, without revealing much of the plot

Facilitator will start the meeting with a quick check-in.

         -    “I am a bit tired but glad that holidays are almost here. How about you?”  

-  Give time to everyone to do a check-in quickly

Facilitator will continue with:

          -  We are having this meeting to come up with a solution about a team party for holidays. I have no ideas so far so I need your help.

Expected that at this point Susan will start talking.

Around minute 10, Facilitator to remind Mary to bring up the new idea about photo booth, by pushing a piece of paper to her: “Mary realizes that a positive event like the one she wants to have is a great opportunity for capturing 'fun times' with the team. So she adds an objective to her desired outcomes. Mary adds something like: I want a photo booth (or something similar) to allow people to take a souvenir of the party home. 

Facilitator keeps track of conversation and whenever notices that people are stuck/not aligning with resolution will do an alignment check by saying:

         -   On a scale from 1 to 10, how do you feel so far with the objectives you have for this meeting?

- Ask the person with the lowest score “How can we help you to get closer to 10?”

Meeting will be timeboxed to 20 minutes.

At the end of the exercise, Facilitator will point out the techniques used:

-          Check-in

-          Stating the meeting objective

-          Alignment check

More details: http://liveingreatness.com/additional-protocols/meet/

Personas  

Personas are created with two names, to cover cases when a female picks up the persona belonging to a male and vice versa.

 

Susan (or Sam)

She is extrovert by nature, always looking for ways to generate energy. She is usually the first to start a discussion and has strong opinions on how things should be done/ resolved. Sometimes, when people are proposing solutions that do not match her thinking, she might interrupt and point out what might be wrong with that thinking and what else can be done.

Susan needs to manage the budget, so she wants this party to cost as little as possible. She is adamant that there needs to be a party, though, even though to her it's just a must-do thing, she is not terribly passionate about it. But not having a party is not an option. 

 When people bring up ideas that will increase the cost for the party, she comes up with options that are more economic (like potluck, or order pizza).

Susan reaches her objectives when there is a party and she is confident that it can be done at a reasonable cost.

Susan’s objective for this meeting:

"I want a team event where everyone shows up and the party doesn't cost us too much."

Bill (or Barb)

He is quiet, smart and very detail oriented. He wants to have a perfect party, where everything is taken care off and there will be something for everyone. Bill is always keen on helping other people organize things, so he will likely end up volunteering to find a venue, order food, drinks, name it... but in order to do so, he wants to have everything carefully planned out.

For every idea that comes on the table, he asks details like what food to order to consider allergies, what drinks to have, from what time until when, will there be dress code, etc. 

Bill reaches his objectives when he has a clear plan with sufficient detail for him to walk away and organize the party, either alone or with help. 

Bill’s outcome for this meeting:

I want to come out of this meeting with a good understanding of the party plan and some action items where to begin with the party organization tasks.

Mary (or Martin)

She is an introvert by nature. She doesn't speak often, but when she does, her opinions are strong and show a ton of wisdom. She really cares about the team and feels that the event needs to be fun for everyone. She does not see value in a party for the sake of a party, she wants the team to walk away feeling they spend valuable time together and come out as a stronger team. 

After about 10 minutes, Mary realizes that a positive event like the one she wants to have is a great opportunity for capturing 'fun times' with the team. So she adds an objective to her desired outcomes. Mary adds something like: I want a photo booth or something like that to allow people to take a souvenir of the party home. 

Mary reaches her objectives when she feels there is a plan for an event where everyone can have fun and can take a souvenir back home. 

Mary's objective for the meeting is:

I want the event to allow us to really connect as a team and be fun for everyone. 

John (or Jane)

He is a social guy, he is interested in an event, but doesn't really have a strong opinion on what needs to happen. He supports everyone in getting their objectives and just wants to get this party organized so he can hangout with everyone in a non-work related setting. He realizes that all other participants need to buy in to make it happen. 

John reaches his objectives when all other meeting participants have reached theirs.

John's meeting objective is:

I want Susan, Bill and Mary to get what they want. 

 

Back at Agile Tour Toronto

Agile Tour Toronto 2012 is probably the first Agile conference I attended fully aware of my purpose to learn, share, steal ideas and use everything I could hear around.
One year after, I decided to attend as a speaker. I submitted two sessions and one of them got selected, the one where I would present solo. The idea I had submitted was not new and for some,  the concept of T shaped people was quite familiar. I had about 2 months to prepare the slides and refine the game I had in mind to play. The very fist slide I created for this presentation had this picture.

I find this photo very funny but also captures the message I wanted to pass to people that are "thrown" into Agile teams and feel like they lost their identity by becoming "just" a team member. And off course I was tweaking the deck till last minute, trying to make it better. I am pleased to report that the session went well and I got some really good feedback in the grade of "9 out of 10". Off course some criticism too, but nothing lower than "6 out of 10".
 What made a difference this time, was that I changed my participation from "Attending" to "Presenting". I also decided to help with reviews of the submissions, twitting about it, paired up on CoachClinic, etc. This year I wanted to make Agile Tour Toronto better experience. What I learned, in no particular order:

- It is pretty much a full time job to put together an event like that. Considering that the guys and girls doing the work are volunteers, Kudos to all of them for the extra time, effort and passion they put into making things happen!
- Gift bags have awesome chocolates! So good, I didn't want to share them with my family
- It's a great event to hang out with other Agilistas in Toronto. I feel now part of this "Agile family" where a number of familiar faces have found ways to stay connected and have a beer together once in a while.
- There is always something new to learn. Not just for beginners, but also for the experienced ones. The trick is to use it right away when you go back to work.
- There are quite a few technical people in Toronto and together they make a fine group of Software crafters
- Projectors of the hotel do not work with my laptop. I really appreciate the previous speaker in my room and also my colleague Gino Marckx for leaving his laptop back so I could use it for my presentation.
- A good keynote speaker sets the stage properly and pumps up the blood in the right way. Gojko did a really good job with his "Make impact" message.
- The number of people that want to participate on these events gets higher every year.
- Sponsors on booths are not all about selling. Some want to "buy" you
- There is always room for improvements
- There are about 5 Firkin pubs downtown Toronto and sometimes you might book your event on the wrong one (or they might forget that you booked)

MVP-BFF, Tomato-Tomato

While the transformation is progressing well with Agile thinking being integrated in all areas of the Enterprise, Continuous Integration and Continuous Delivery are a sore area that my client is trying to work out.
Because of the draw of the sticks, usually QA is the team that is pointed as the bottle neck on the delivery. Why? Because it is last on the process. Why? Because the feature work doesn't start with testing in mind. Why? Because the features are still being designed and built with very little input from QA. Why? Because the system is complex and testing end to end for a small change is very expensive.
So the ball ends into QA's port. In order for QA to do something about being called bottleneck, the feature delivery should start with the end in mind, with a thin slice of functionality. And the QA manager at my client, came up with this idea on his own, after a long week of thinking stuff over, on his way to Sunday golfing. His thinking was to start working on "Basic Functionality First". The way he explains this is:
If the goal of the project is to create an online store, start with setting up a way for a client to order a sprinkler using only Visa. Client should be able to go online, select the only item available (a sprinkler), pay for it with Visa and have it delivered home in 3 days. This is the BFF. Once this is proven, start adding more items, more ways of payments, etc,

For a mature Agile ear, this is the concept of MVP, where you deliver to the client the Minimum Viable Product and then based on the feedback expand and add more features.
When I heard him explaining BFF, MVP came to mind but I decided not to ask him to use MVP. He liked BFF, it is original, makes sense on that company and it is THEIRS. It is not something that someone else is talking about, and maybe on a different context.
So BFF is now something everyone talks about and everyone wants to see it happening. In the spirit of making BFF work, the need for Automation Testing and a Continuous Integration system is identified. You can't have BFF without a good CI system, right?! But to have a CI system in place, you need Dev team to work with Ops team. Guess what? DevOps is now on the table and is being considered!
It is amazing what the intrinsic motivation can do! Way more than I was thinking and how I was thinking to run with it. Pfffff.. my plan sucked! My plan was not a BFF.
I am well aware that setting up a CI and DevOps on an Enterprise organization that is complex and sort of behind in technology is not an easy bite. But once again, I am experiencing, an agile transformation hitting the technical wall. There is so much you can do with only Agile thinking. Technology has to step it up and support all that. Call it MPV, call it BFF it is the same need over and over.
No offense to Eric Reis, but I like BFF better than MVP. Has a more collaborative and amicable tone! I imagine Developers, Testers and Business holding hands and running together on green fields, with a cycadelic tune behind it!
BFF FTW!

My first Agile 20xx conference

Yes, was my first and I went as a speaker! The proof is on the shiny gold letters.
Well, co-speaker really. I presented with Jason Little  on what we have been working on during last year, Transforming a Public sector company  to Agile. It was definitely an experience that I had to go through and feel it by myself, while working with a PRO on presentation like Jason.
I am very happy that our presentation went really good. I was impressed that our talk got the attention of some really cool names in Agile circles like Ellen Gottesdiener,  Jeff Morgan (aka Cheezy), Diane Zajac-Woodie, Leslie J. Morse, Mike Bowler, Alexis Hui, Raj Mudhar, Jake Calabrese, etc. Receiving a positive feedback from them meant A LOT!
It was really good that our session was on the first block. After that, I could enjoy the rest of the conference. And there were a lot to enjoy there. As a first timer, I didn't know how to maximize my time there. I tried to pick a session where I would benefit the most, but I don't think I did well. There were so many good sessions and I know I missed a lot. The other thing I missed were the non-official sessions going on outside the rooms. I kick myself for not spending more time there. The one time I stopped by, I laughed the most. Matt Barcomb and Bryan Beecham started a game on how to best use the estimation cards. A lot of people joined the circle after we started and a lot of rules were set and re-set. The game at the end was called "Promiscuous Poker" (don't ask why) and we intend to publish it as Plan H for our early retirement.   
I was really proud to see Alias on one of the slides from Jeff Patton. I have worked at that company for 11 years and I know that what we did there was special and unique, until was acquired.
The session with Sue Johnston and Andrew Annett was great too. People like me, that think while talking, have a lot to learn from them.
The surprise of the conference for me was Andrew Shafer.  First he surprised me by reading "The commitment" book at the party, on the boat. Then he surprised me for keeping me awake on the very first session in the morning, after a long party. I really enjoyed his point of view and I proposed him to be the keynote speaker for next year. He ended his presentation with something like "You are awesome. Continue learning. Go!" that would have been the right message to open the conference.
Another session I enjoyed was Ron Jeffries and Chet Hendrickson. They work together like Dean Martin and Frank Sinatra, beautiful harmony, fun and entertainment.
The best story I heard: after a presentation, Mike Cohn and his assistance discussed about the next venue and decided on the hotel where to hold the venue. Mike went home and next day he gets a message from her saying "Mike, the hotel is booked". Happy with the results, Mike considered this venue all set up and ready to go. 2 weeks before the venue, he gets an email from her saying "Mike, what are gonna do about the next venue. We don't have a hotel yet and there is no time left". He writes back and calms her down, reminding the email where she told him that the hotel was booked. To which she replied "Yes Mike, the hotel is booked as: There is a wedding and the hotel is booked!". Oops!
I have a lot of things to remember from this conference. Nashville, the huge hotel Opryland, Tootsies, first time to try fried green tomatoes, 3 hour naps during the day, Bourbon beer, meeting all these "agile rock stars" that I knew from books or Tweeter, feeling comfortable in the crowd that spoke my language, got a hairy LeanDog hat, first karaoke (duet with Declan Whelan) "Superstitious", awesome guacamole made fresh in front of us, and the feeling like I was on a different planet without gravity.

Disconnect the tool from the mindset shift

The team I am working with is new to Agile. They are fully aware of being for a long time on Waterfall environment and moving to Agile is something they are struggling with.
One the things they are struggling a lot is the tracking of the project.
Working with MS Project, tracking activities, tracking the time spent to the project to the minute, is so deep on their way of thinking, planning, doing and behaving that over and over I find myself pulling them up a level to get them to track stories, value and deliverables.
On the same time that they are asked to shift the thinking and what they track, they are presented with a new tool. It can be any tool but everyone know about Jira, Rally, VersionOne, etc. So I'm not gonna say what is the tool here, let's just call it StoryTtacker.
What I constantly hear is the blame about this tool. How will we enter the stories to StoryTracker? How will we break the stories to StoryTracker? How will we track in StoryTracker the big stories that we can't break into smaller chunks that fit in one sprint? I need to create a story in StoryTracker about the meeting I have next week with another group. Testing should be a story in StoryTracker because is really big.
I have heard the same complains before on another place where instead of the StoryTracker we used just stickies on the board. Exactly the same issues.

So today I got an AHA!! moment. It's not the tool to blame, it's the story tracking thinking.
They are struggling with working with stories, with giving value to a story, with understanding what the story is for a user, with understanding who the user is for the work that is being done, with understanding what the GOAL is for the story that will be done on the next sprint.

I'm thinking that I might suggest to them to use MSProject as story tracker if they think they will do a better job with that. The conditions will be that we will not track activities and meeting. Continue to track stories, but let's see if the problem is the tool or the mind set.
First thing I'm gonna challenge them when I get back to work after the Agile 2013 conference in Nashville.

Let's Play!!

I am a true believer that people learn more by doing than reading or listening. So I try to make my teaching more interactive. That is also good for me. English is not my mother tongue language so sometimes, some "big" words that would explain something really good and precise, they just don't come to me at the right time. But if I tell stories, play games, engage others, have eye contact and discuss, I am a better presenter. Another coach that I have great respect, Griffin Jones, pointed these out to me at the Open Space back in April and I think he hit the nail in the head in 2 minutes.

Recently I feel I am writing a lot of presentations. Not sure how I ended up here, but I am really spending a lot of time with PowerPoint and formatting slides. I will tell about 2 sessions because I think both my audience and myself enjoyed. Read this as a retrospective of good sessions, but never forget that there is always lessons to learn from those too.

1. A new team in Agile was struggling with how to work in Scrum
I am the Scrum Master/Coach for this team. I joined the team when they had passed the business decision to work on this project and they were into the initial design discussions. I knew that some Agile training was done but didn't know that only some of them had participated. So on our first retrospective, the number one frustration was "we do not know what is next in this Agile process. We knew before what to do and what to expect, but now we are not confident". Clearly, there was need to explain not just Agile thinking, but more of agile mechanics.  I prepared 6 slides to explain how Agile fits into System thinking/Lean, the 9 rules of scrum and then, we plaid. I decided to play "Build me a city" with Lego. You can find the material here: http://scrumalliance.org/resource_download/2757 
The game in itself is fun. We found some Lego talents and they had to do the whole scrum process end to end. We did back log, sprint planning, demos and retrospectives, burndown reports and also added a spin with remote team members (working far from the table) and a 50% allocated person (switching between the two teams).
One team started asking me early on some decision they had to make like "Is the bridge for people or cars, or both?". At the end of the first sprint, they had some building prototypes to show me and I gave them feedback so they could fix it later. After all, that team did really well. They did what I asked, made changes after my feedback on demos and added also some delights since they loved playing with Lego :)
The other team did not interact with me between sprints. I met them and their Product Owner only at demo. The did not present me any prototype for buildings during the iterations, but at the end showed me 1 of each. Clearly, they did not understand my requirement to have several buildings of each type. The very first thing one of the team members did, was to draw a blue line on the paper and say "here is the river" without asking the others. They all jumped in alarm and told him to stop until they draw a concept of the city first. And then the whole design was around the river being where was drawn. They also did not organize well the work between the team members and the level of collaboration was more on the chaotic side. After all, they built only 1 type of building, added some delights when my main requirements were not completed and felt like pointing the finger to the product owner after all.
Here the pictures of what they built

Guess who learned more? The second one!
After the game we had some good discussion and I was there just to ask questions. The answers were somewhere in them, or the other team. Was really good and fun and we still use it as reference when we are in similar situations in real software development.

2. Working with Executive leaders
I volunteered to hold a session with my team of coaches about the pain of presenting to executives. Someone asked "Who are we considering Executives?" and the best answer he got was from Gino Marckx across the table saying "When it gets scary :)". The model I proposed was Insights Discovery because this model is used for Customer Service Representative training. After all, I think, talking with an Executive is like serving a client what they are looking for. After I explained the model, I got everyone in the room to build their personality tower, again using Lego blocks. This was easy, just a group of 4 colored blocks per each (red, blue, green, yellow) but they all felt engaged and "IN" the presentation. To make it more real, I gave them the task to prepare to present the status of project to an Executive sponsor. I made up a project that was in really bad shape and I split them in team A and B. Team A will present to a Red executive and Team B will present to a Blue executive. I had prepare a 1pager for a real Executive leader of the company to explain to him what was going on. After both teams had about 30 minutes of preparation time, the executive came in the room and took a seat. Both teams presented to him in 10 minutes each and at the end, we had a chat with him.
Here is them preparing. Guess which team is writing things down and preparing detailed report? :)

Team A didn't do very well. They took it easy and relaxed and "told" him what they were planning to do. He fired them on the spot :). The "PM" was literally sweating even-thought that was all staged.
Team B learned from Team A and started well (with introduction), presented better and supported with material. They "offered" options for next step.
Funny thing is that, the Exec said that none of the teams did a good job to convince him that they will get the project on track. The plan was 10 minutes chat after the presentations, but he went really above and beyond to explain to us real life situations with some really scary executives. Was really good and very fruitful 60 minutes of everybody's time.  Ended up being a talk that I wish I had recorded and listen over and over. Funny thing is, that he had been sleeping for 2 hours every night in the last couple of days. Imagine if his energy tank was fully loaded!

Toronto Agile Coach Camp

So what do agilistats of Toronto do on Father's day weekend? They decide to have a kick-ass Coach Camp.
I didn't want to organise any session, I was really thirsty to hear new stuff. So I only put a sheet of paper at the door and asked everyone to write Agile movies :) I liked that hashtag on Twitter and I thought would be fun. Some people did write some movies, but I forgot to take a picture of it at the last day :( Oh well, was meant for fun so I hope some people read it and had a smile.
Friday evening was really easy with some lightning talks and some games. Then Saturday and Sunday were busy with some really good sessions. A lot of times, I couldn't decide between 3 good sessions at the same time.
Here a picture of the wall with sessions.

My favs:
1- Declan and Paul Whelan. Two brothers, Paul architect "with bricks and mortar" . Declan with computers and debuggers. Nice to see some commonalities, especially during the pre-delivery of a software. I know that there is a big discussion that "software development is not like building a house", so i won't get there. I got two ideas from that session : 1.Crits- people of different areas that come and critique the architecture proposed. 2. Cost contractor - people that come and prepare the cost budget based on the architecture proposed. I like the second one a lot because right now, I am working with a "project team", so a bunch of people that are gathered to finish a project. One of the pain points is the cost calculation. The sense of 'service' does not exist and there is no predictability on the cost for a certain work. If work is offered as services with a known cost, then budgeting would be easy. The best would be to have stable teams, but that is a bigger battle right now.
2- Michael Spayd. He is a Jedi! Love his style and his laud laugh! His session was about the "Spiral dynamics". It is about the level of a society, how things are done based on certain governance and then compare that with organisations, or at least this is how I understood it. He lined them up with colours beside each and focused on Red, Blue, Orange, Green and Yellow.

At the end, we had an improv where in split in groups per each colour and discussed which one was better, off course, making a case for the colour of the group. I was Blue! That meant that I had to make sure people do things as per the book, as per the rules and follow the process rigorously. Was not hard at all to improv that role. I have seen so many people like that! :)
3- Mike Bowler. Continuous Delivery. Eh, that little geek left in me needed a bit of fuel! Good conversation, good ideas and good direction on not to fall back on the old way of doing things.
One thing I remembered is that to have high technical standarts, you must have a strong understanding of the consequences that you have to deal with in case you do not take 5 extra minutes to do things right. We are so "lazy" sometimes and we think we are wasting time, but we forget the quality of the code, the need for a good automation system and the need for deployment in small batches.

I have to say that the session of Simon on SOLID gave me the same familiar feeling. Geek talk! I loved the fact that Alistair McKinnell was there and participated in the discussion. It was great to see him "in action". Not just about what he was talking, but also how he was directing Simon to lead his session in a better way. Master coach!

At the end, I managed to put up a session. I did it more for myself, was a ask for help. Practically hired Michael Spayd, Alexey Zheglov, Declan and some other people that were interested on he painful budgeting of an Agile project on a non agile organization. I have to say that the best thing of that session was this twitt: "We want to be agile. We bought Jira".

Temenos was another session I went and I understood I have a clean slate. I missed so many good sessions, but what can I do :(

At the end, a long rope was thrown all across the room and made a big web. Everyone that touched it, was thanked for something and thanked someone.
A lot of people referred to the group as their "other family". I am starting to feel like that too now. A lot of familiar faces, a lot of people that share the same point of view and understand jokes like "How many agile coaches you need to change a light bulb". I was fascinated by some people, by their courgae and by what they have done with their lives. Good examples and good source of inspiration.

Run your project like a train

Every day I take the train to go to work. I notice how groups of people start creating in areas where the doors of the train are expected to open. It must be funny if you look from up above. Imagine a long train platform and groups of people spread in 4-5 meters distance between each-other, all long the platform. Why? Because they expect the train to arrive soon, and based on previous days, they expect the doors to be open at a very short distance from where they start forming groups. The first that gets in, might find a place to sit!
So I made a Mind Map to organize the lessons learned from riding a train, and map them to running software development project.

I can go as literal as I want to, but there are some good areas to learn:

1. Even though a train can go very fast, the speed is limited, to control the timing at each station. It is almost like limiting WIP to have a good pace and be predictable, without extra effort
2. The Project team can be kept at the required minimum (there are 2 staff on the train and some staff at the stations to deal with ticket issuing).  Operations are there to make sure everything runs smoothly.
3. There is a good Communication system for emergencies, updates, notifications, etc.
4. There is a map of the route and clear understanding of destination
5. If there are issues, buses run as backup strategy
6. There is a clear Cost strategy, based on the distance
7. Good strategy on Dependencies (a train stops when the train ahead has problems)

And this is from a Canadian train. Imagine how much we can learn from the German train system!!

How would I run an Agile transformation: Hamburger style!

I can't say I am "an experienced Agile coach" but I have seen three of them in big scale. In all three, the initiative has been from the Top (CTO, CIO, Department VP) as "Agile is the solution of the issues we are facing". Issues can be different but more or less are always around expenses, ROI, fast delivery and also as a peer pressure since all the successful CIO/CTOs out there are benefiting from Agile tools and practices. So far so good.
Usually, the way it gets executed, it is with project/product teams.They are the first to attack since they deliver what we produce. An outside or internal person that knows about Agile, is assigned to work with delivery teams. There is some work done with Managers as well, to help them understand the new language the people will start using now on.
What I notice is, that after a while, the Top and the Bottom layers are running Agile in their own way with their own expectations, but the layers in between, Managers/Directors/AVPs, are stuck. They are still Managing details, day-to-day operations, Severity 1 issues, approve Gatings, control communications top-bottom and bottom -top, run performance improvements, .....They become bottlenecks and get very busy at it. 
I think that the Top layer, needs to understand Agile delivery before they ask for it. As a rule, in an Agile delivery, you hit first the most visible/riskiest feature and then improve/add functionality on it. In an Agile transformation, this feature is seen to be Delivery process and that's why, the whole work of the transformation is done around improving the process, making the process agile.
When I make two steps back, improving the delivery process, is the whole "product" you are delivering in a transformation. Some analysis, story mapping and story breaking need to be done, to understand what is the most visible/riskiest feature of this delivery process you will produce.
 And from what I see, it is the Management layer. At the end, even the end delivery process will need to be managed!
 So, I would start my Transformation with the Management layer.
 At the end, even in an hamburger "the meaty part" is in the middle!

 

 I would :

1- train  managers with Agile principles and thinking

2- train managers on how to identify issues in an Agile environment

3- make sure managers understand Trust (they have to go through that themselves before)

4- train managers on how to manager people

5- train managers to have their personal Kanban to control their work

6- give managers chances to test all of the above without dropping the Agile hammer all over the place

       And then....

Ask managers to run the Transformation with their teams, starting with organizing the teams according to work flow.

Maybe this approach will not see the BIG impact right away, but is the incremental way to run a full Agile transformation. By starting with the Management layer, the highest risk "feature" is done first. During that process, we will learn, improve, progress and evolve as per the context of the organization. Then, the rest of the Transformation value comes, incremental and with purpose in mind. By now, managers should know how to manager people, how to create a trusting environment, how to allow test/try/experiments and how to empower people.

Delivering in an Agile way is the side effect that will come naturally and managed properly.

Big Bang, Inflation theory and Leading an Agile Transformation

Astronomy is one of those areas that always amazes me. I admit shamelessly that when my husband is watching a show at Discovery channel about Universe and theories related to cosmos, I never complain about changing the channel to watch something else.

One of the interesting theories is the Inflation theory. In a nutshell, Inflation theory tries to explain the rapid expansion of the Universe right after the Big Bang and how all of that slowed down to a more gradual expansion and start cooling down. The amazing part is that Inflation covers only the first seconds after Big Bang, because, as per the theory, the Universe doubled itself 100 times in 10³² of a second. To put it in perspective, it's like having a piece 10²⁰ times smaller than a proton, and inflate it to a sphere about 10 cm across in about 15 x 10³³ seconds. Because everything happens so fast, matter "freezes" and has no time to change, it just moves along.  Amazing right?!!
That's where my simple brain stops understanding, so don't ask me more.
All this reminded me a Big Bang Agile Transformation on a relatively big organization. As my friend Anirban would say, "the point is made, no need to go on with the story anymore". But I want to write a bit more.
The first couple of months after the Big Boss comes up with the "need for Transformation", a lot of things happen very fast.  Some people are let go. People kept behind go through a lot of trainings, meetings, contractors that don't know the current system come and start telling how to do things instead of the "old way". All this is so fast that "the matter" like projects, deliverables, people's mindset, technology, "old tools" and management style, have no time to catch up, so they just move along, without changing shape too much (maybe just a little bit). And then, the cooling down starts. Transformation continues but is not so strong and fast. Is more gradual and cool. This is the time when "old world" starts facing the "new world". This is where the changes happen, where mindset starts shifting, where teams start to create, where Gravity kicks in. The phase after this, is very important.
 To go back to Universe, there are different theories where we will go from here. Look at 3 of them:

Any of these could happen on a Transformation process, and maybe more. At the end, we are on a Complex system where we can only progress with hypothesis.
I think that the Leaders of the organization are Accountable and Responsible for the next step. By now, their mindset, leadership style and organization Vision, must have followed all the steps as well. By now, they should be well aware of the Gravity they have created and  what choices will keep the Transformation "Continue Forever" versus other options. This is where their maturity is put to test. This is where they will prove if they are strong leaders or just followers. Tough choices are required to make sure that the Transformation doesn't get timeboxed and put a deadline. Being soft, forgetting about the organization's Vision will only make all the effort a Fairytale, rather than a Successful story.

We are a big coloring book

In the last couple of weeks I have:

- Resigned from my current job after going through some interviews and  accepted one of the offers
- Heard the ninja song a lot of times
- Finally got a chance to take the Management 3.0, a 2 day training presented by Jason Little!
- Crashed Star Canada one evening and had dinner with some interesting people
- Went to Open Space Toronto and decided to lead a session
- Went for lunch/coffee with a lot of people that wanted to wish me farewell 
- Went for dinner with some old friends

All of this, made me meet new people and connect closer with the people I already knew.  Everyone new I met, has something new to bring in my life, something that not just will help me with what I do everyday, but also understand myself better. With everyone, I build relationships.

If we take a step back, all we do in our life is, we build relationships. I'd like to see a relationship as an outlined figure where both parties decide on the contouring and on the colors to use. I am sure that there are some people out there that do not want to have anything to do with me. We have probably outlined a difficult image and used a lot of black and blue inside. Adding some bright colors might be the next thing to do. I am also sure that there are some people out there that would like to spend more time with me, because we have painted our figure with a lot of pastel colors (do NOT add black and blue on these relationships, that's NOT the point!).
Every time we meet new people, we are faced with a new outlined figure and with options on what colors to use. Relationships are built with our family, people we work, people that prepare our coffee every morning at Tim Horton's, people we see everyday on the train, digital people we meet on Twitter or LinkedIn ....
All these relationships we have in our life, make us a big coloring book. It's up to us what figure to outline and what colors to use. Choose wisely, learn from the ones where you used black and blue, add to the ones with bright colors and your coloring book might become a great collection of beautiful figures.

Smarter, not faster

Last November, I was partially working on a "crazy" project. I say crazy  because:
1- The initial scope of that project was presented as "Take this Excel spreadsheet and make it a web form.By the way, there are some macros"
2- 2 weeks in the project we found that the scope was much bigger. "By the way, we want to make some enhancements!". There was no Solution Designer looking into it, just developers.  Nobody was doing anything to change the delivery date
While Business Analysts were trying to figure out what had to be done and trying to solve a lot of questions, Developers started coding. A lot of developers were contractors and we were paying them by hour. There was the need to keep them busy to justify their time. No matter what they were doing.

I asked the team to agree for a 3 days "developer hiatus" while Analyst could catch up with the requirements. My point was that developers were making technical and architectural decisions in a time when we didn't even know what was being asked. In the same time, we wanted to introduce Git as a new tool so, I thought, would be a good usage of the 3 days for developers to move the code to Git, set it up properly, get familiar with it and then pick up with what Analysts would have found.

 

It was a big NO from the Dev lead. Under the pressure to use the contractor's time on writing code for the project, he just couldn't accept the fact that developers would stop writing code. "They are developers, they write code, they don't wait for requirements. This is against being Agile!". Despite my argument that the decisions they were making now would create problems if the requirements would be asking for different technical decisions, despite the fact that Analysts asked for 3 days to catch up with where developers where, the "3 days hiatus" didn't go very far. What I was proposing (some sort of TDD) was never done before, was just unacceptable!
Fast forward, end of March, after pushing the deadline 2 times, having a lot of people joining that team and then moving on to other projects after a while, I was talking just the other day with one of the Analysts that has been on this project from the start. Here what she said:
-OMG Ardita, that 3 days that you asked for developers to stop, we should have asked for 1 week!! You have no idea how much trouble we have been going through. The requirements were not anymore what client was asking for, but what developers had already done. We were being pushed back and forth between client and developers to figure out how to get the maximum of what client was looking for on a feature that developers had already closed. They were so worried to spend some contractor hours, but they spent so much of our hours that were wasted in this ping-pong. We should not aim to be faster anymore, we should aim to be smarter on how we do things!

I thought my job was done!!
Yes, true, I did not really help them with that project, but, as far as I'm concerned, they now know how to think differently and sometime consider to Stop! TDD is the best Agile practice that my company needs now. It's not about coding fast, is about coding what is needed, is about being smart on what to code and when.

Trip and Beyond

Last weekend I went to Agile and Beyond on Dearborn. Was good to go there with friends! Not just because it makes it easy to blend in the crowd with someone you know, but the road trip was fun too. I will talk a lot about the speakers here, but you should know I feel sort of hip to be friend with these guys (Jason Little (check out his LeanDog picture at the bottom), Andrew Annett and Sue Johnston). If there were sessions that I didn't vote high, it is their fault for being so up to date with things and make everything sound as something I had heard before. End Of Disclaimer.
(Here is us packed like sardines on a Mazda. You can see a bit of my shoulder here)

I want to write down some of the things I heard on the sessions I went, before I forget them.

Key note from Jim Benson rocked! I have to admit, one of the main reasons I went there was because Jim Benson was there :) I didn't expect him to be that tall!!And he IS like a puppet :))) He said a lot during the key note but here what I took away :

• Rules kill awesome 
• Optimize don't standardize 
• Be nice
• DONE means it never comes back!
• Metrics are temporary convenience to prove a point 
• Subjective well being of people is a metric
• For any bad feedback, write to David :)))

 I really enjoyed listening to him so I didn't want to lose focus by keeping notes. I had a chance to invite him to Toronto soon. Maybe will happen! ;)

The first session I took was Matt Barcomb and Diane Zajac-Woodie. Really enjoyed it! I think Matt is a supernova, so keep an eye on him (I mean follow him on twitter @mattbarcomb or something, not literally look at him). Some of the key takeaways:

• Fund capacity from past spending. 95% of the spending can be predictable if teams are stable
• Lines of Value (instead of Line of Business). They are multi-role groups and need to have a form of team identity
• You might get an IT guy on the line of value (Devops idea)
• MVPs are not just code written that does nothing. They are like Zombies! They move and function, not very well but they do! :)
• To decide which option to chose for the next project/product, line up ~4 key factors that are important for a choice. Put some weight into each. Then give a weight to each option per each key factor, do some math and you will get the option that scores the highest based on the key factors. The funny thing is that the option that will float on top, might not be at all what we want to do, so we might decide to go with the second option anyway. 
• To size stories, line them up on a long line as per their relative size. Then divide them in groups. 7 is a lot of groups. 3 are usually where to start, but when you mature, you can move to Big and Little groups.

I missed most of his session on coaching. Went there at the end when he said that both coach and the person being coached should set some objectives when they work together, some steps to get there, what is next and by when do you expect to get there.

Then I did an hop'n pop between Bill Wagne session's and Carol Treat Morton and Renee Pinter.
From Bill Wagne:

• They decided to track these key metrics: Total cards, Current velocity, Average card siz. Start calculation on first iteration
• After 2-3 iterations they found : nr of cards X average card size is what was delivered by almost every team. Outliers are the 40/ and up
• Key questions to ask: When will we finish? What is the cost?
• Start see the nr of new cards added per iteration
• Get product owners to look at the new additions, the trend and the effect. Start the conversation based on those
• Let Business Owners own the goals: Keep budget or Keep Features?

 Really enjoyed the energy from Renee and Carol.
 Here is a picture of the exercise from their session

To understand this image, we first created a whole bunch of personas. Each card had a picture and some details about that person. Then, some of us pretended they were the client and decided to categorize which of these personas is the most important client to them. For us was Randy. From now on, every decision about the product is based on Randy's liking. If CEO comes and asks for changes, you tell them: Well, you might like purple font, but Randy doesn't!! It is a tool to keep focus and have everyone focused on the right outcome.

And then was Cheezy (Jeff Morgan is how the city of Cleveland taxes him and his boat). I have to say was the most animated session. He got 4 people (product owner, developer, tester and designer) all dressed up in fake hair, hats, glasses, boas and they got to play a bit of theater. They were boiling under all those accessories but you could tell they loved it!

• Product owner is there to take the team to the highest possible value delivered AND decide what NOT to do!
• Team is there to deliver what Product owner asked, continue improving (Kaizen) and make sure the code is clean
• What do we do when we find a defect? We put it on a big defect system? NOOOO! We FIX it!
• Put the weight of the Earned Business Value on the card and we see how much value we add when we deliver same amount of points on the same time
• Experiment: Business analyst to report to Product owner. Product owner stays with team and answers questions and works on the backlog. Analysts go to meetings and bring info
• Specifications in Gherkin help with testing
• Developer comes on Validation stage, after Testing is written. What we Validate is not the code that developer wrote but the test cases that tester and PO wrote!

I got to talk with Cheezy and some other people afterwards for dinner (Maria Matarelli, Chris Gow and Paul from LeanDog). He let me have a picture with his hat. For all of you that know about LeanDogs, you should know about their hats!! :))

The last session I could attend was Jean Tabaka. Loved it! She talked about the Mad World we live in (we actually heard the song), about the chaos we work at and Cynefin.

Two things I got from her:

• Are you a chef or a receipt follower?
• Abductive logic

And then we watched a movie :))

Update: a picture of Jason with a LeanDog hat!

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.