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.