Thank you so much Shane. It is so nice to be here. I wish you were here next to me instead of a disembodied voice. But that is just me, so thank you.
I am an author, a consultant and I am a speaker and I have been speaking at the conference. I have done three talks so far, so you were going to ask me about that, right?
3. Yes. What three talks have you given?
I guess I have only done two so far. I have one to go this morning. I did “What is in my Agile suitcase?” as a PechaKucha. That was on Monday. Martin Hider asked me to do that along with four other people. That was a total blast. A PechaKucha is when you talk for 6 minutes, 20 seconds, whatever it is. It is 20 slides in 20 seconds. And the reason I cannot figure that is because you have to do arithmetic. And you know me: I cannot do arithmetic. I can only do math. So, I put my slides together and it’s trending on SlideShare. (It is so exciting.) It is “What is in my Agile suitcase?” and for me it is all about mind set, it is not about tools per say, but it is about how you think about being Agile, not just doing Agile. That was fun to put together and deliver.
4. What are some of the key elements of being Agile rather than doing Agile?
It is partly thinking about how do you experiment and get feedback. How do you take small steps and work in chunks? How do you collaborate with a team? How do you deliver? I had a really terrific image of a pizza delivery shop. It is all about how do you think about working with a team, delivering, doing it again and again and again and retrospecting to see what can you do the same or different the next time.
5. Is that for the individual or for the team?
It is how you think about starting at the individual, growing as a team and continuing to the enterprise.
Shane: I know that one of your sessions is on project and portfolio management.
Yes. You know me. I am huge on managing the project portfolio at the personal level and certainly at the organizational level. That is the talk I am going to do this morning. That is called “Transparent decisions – Managing the project portfolio”. I am huge on not multi-tasking. Multi-tasking is the fastest way to get nothing done. So, I am giving my talk on managing the project portfolio and I hope people are going to come. I have been evolving this talk over several years so I think it is going to be quite fun and I hope people come to it. We will see what happens.
Shane: And the second talk?
Yesterday’s talk was “Agile and teams collaboration. What is new about Agile?” because a lot of people on the boot camp stage are here for the first time. In fact, when Kent asked on – what was it? Monday morning? It is only Wednesday now, but Monday morning – but where there 50% of the people who were new? It was something like that.
Shane: Something like that.
Yes. There are a lot of people who do not really know about Agile teams and how collaboration feels and I try to help them understand what does a team really look like. What does a cross-functional team feel like? What does the buzz in an Agile team sound like? I used the metaphor of a second marriage. You have your first marriage at home, you have your first family at home, but you family at work is this other family. You develop these really personal relationships – I almost said the word intimate, but I do not mean intimate in the same way. But you develop these caring, personal relationships with these people that you spend eight hours a day with and you have fun together, you have a sense of humor. I was talking with Gill Broza who you will talk with later today. We were talking later and he said to me: “I bet you have a side about having fun”. I said: “Yes. I do have a side about having fun with people at work”. So, yes. That was part of my talk.
It should be! If you can’t have a sense of humor about your work, what are you? The kind of person who goes into the basement for a chuckle once a day? No, I don’t think so. I think that work should be fun. Yes, work is serious and they pay us for it, but if you can’t have a little fun with your work – you have to be able to. The serious stuff – you have to take it seriously. But, really, even if you are doing medical devices where people could die because of your work or you are building airplanes and people could die if you are not taking care of your work. That is no reason not to have fun. I am not saying to be flighty about things, but I am saying you need to have a little levity with your work. It is important because otherwise you do not see the really serious stuff, when it is serious.
7. Jumping back to one of the points you made – the dangers of multi-tasking. Why?
Because it is so insidious. You start to pick something up and you get really involved and now if someone taps you on the shoulder for just a question and you have to put it down and you want to answer the question. But when you answer the question you are not a computer. You are not able to swap out state. You try to remember everything that you are doing but when you try to swap out the state you forget things. Not because you do not mean to, but because you are not perfect. So, you go to answer the question and now you have to get back into the thing that you were doing. When I was a developer, even when I was young and had all of my marbles – I only have maybe 99% of my marbles now, because I am older. So, I go back into what I was thinking and I think: “Where the hack was I?” And I only remember 99% of the things, but it takes me half an hour to get back to what I was doing and that is the problem. There is a time cost, there is a delay to getting back to what I was doing and I do not remember everything I was doing. So there is the cost of multi-tasking and we can’t account for that delay. How do we account for that time?
Shane: There is no accounting code on the time sheet.
There is no accounting code. So think about that. If you are supposed to work on project A for 50% of your time and project B for 35% of your time and project C for 15% of your time, where does all the delay get accounted for? It is not. So, you are not really working 50% – 35 % -15%. It is kind of random. This is the problem. Managers multi-task all the time. Makers, creators, product developers – and I do not mean just code writers, programmers. I mean testers, I mean English writers, people who write documentation, I mean UX designers, UI designers, I mean DevOps, I mean anybody who creates. Like product developers. Anyone who is on a cross-functional team who is going to create product in some way, someone who was not a manager, those people are product developers. They are not on a manager’s schedule. Those people are impacted by multi-tasking. This is huge problem and it is so invisible to managers. This is why calling a meeting in the middle of the day - death to projects. It is total death. So this is why if you want to have a stand up meeting you should do it at the beginning of the day, just before lunch or at the end of the day. Any time other than 10 a.m. unless that is the beginning of your day. If that is the beginning of your day, that is fine. But if it is not the beginning of your day, do not do it then.
8. [...] Would you mind telling us a little bit about these three books?
Shane's full question: Johanna, one of the many hats you wear is you are an author and a pretty prolific author. I know that at the moment you have got the “Hiring geeks that fit” book coming up or available in electronic form and I hope you will tell us a little bit about that, “”Manage your job search” you said you were busy with and there is another one on Agile and Lean program management. Would you mind telling us a little bit about these three books?
Sure. “Hiring geeks” came out electronically in 2012 and I dilly-dallied about that: Should I bring it to print? Should I not bring it to print? Then several of my clients said: “I really like this as a print book. Bring it to print!” And I thought: “OK. I will.” So I hired a book designer because a print book is really different than an electronic book and I did not realize how different it was until my book designer said: “You have to make all of these decisions”. And I thought: “Boy, I do not know much about a print book”. So, I started to learn about print books and I have been working with this book designer for a couple of months now. We are pretty close to done and I have actually been blogging about some of my decisions and the first proof of the book came back and I thought: “Oh, this is not quite right. I really need to redo this and make sure I want a book that I can be proud of, because there is no point in having a print book I am not proud of”. We are on the second draft of the print book and I will have a print book I can be proud of.
9. What is the title “Hiring geeks that fit”? Why do we need a book about that?
A lot of people really think that they know everything there is to know about hiring technical people and technical managers because they have all been hired at least once. But a lot of people don’t ask just the right questions. The worst part is they try to do a job analysis by the looking for technical skills and they do not set up the right cultural fit skills. That way lays this kind of death spiral of looking and looking and looking and looking forever for exactly the right person. Well, you can look forever for the right person and never find the right person or you find the right person for a half a million dollars. Well, that is not going to fill your entry-level position, right? An entry-level position does not need three to five years experience and looking for someone with a laundry list of technical skills this long is stupid. Technical skills are not good criteria for someone who needs a lot of empathy or a really good coaching position. You have to really find the right list of qualities, preferences and non-technical skills for the kinds of Agile teams that we are looking for and this is really difficult for people to get through their heads.
Our cultures are so critically key for the kind of people that we are looking for, especially if we are looking or an Agile team. This is hard for people to understand and so “Hiring geeks that fit” is the bridge for people to understand: How do I design a job description? How do I figure out how to interview for people? How do I design questions? How do I make an offer that will be accepted? How do I get people in on the very first day and make that job stick for someone? And then all of my other writing is: How do I keep people in the organization once I have them?
Shane: And then you did the flip side of that in terms of “Manage your job search”.
Well, I was meeting a lot of people who said: “I just can’t find a job. I just can’t find a job” and I thought: “How are you looking for a job?” And they would say: “Well, I am sending my resume at 250 companies” And I say: “There are not 250 companies that really want you. There just are not.” So I was meeting people who were praying and spraying or spraying and praying – that’s it! That is not a useful option. So I would say: “What is on your to-do list?” And they would say: “Well, I spent a week writing my resume”. And I would say: “Wait a minute.
I am a writer. You do not spend a week writing a resume. You do a draft of your resume and send it out for review to a few trusted people. While you send it out for review you work on your LinkedIn profile and you endorse a few people and you ask for recommendations and then you network. And while you are networking you do these other things, but you are not multi-tasking while you do this” And now we are saying to people: What I do is I use personal Kanban and you do all these things that you are doing in small chunks. And they would say: “Small chunks? What do you mean small chunks?” And I said: “Oh, my goodness. I had better write this stuff down” So as I was writing stuff down I actually gave a talk about this at Wednesday is Networking Day in the Boston area and when I was explaining to people how you do this, they were all kind of looking at me and saying: “Johanna, what are you saying? Wait a minute. Go slower so I can write this down” And that is when I said: “I had better start writing some blog posts so people understand what I am saying” because I was frothing at the mouth and saying: “Do this one thing in two hours or less, get some feedback.
Do this next thing in two hours or less, get some feedback. Do a retrospective at the end of the week”. “What is a retrospective?” And then I realized that a lot of these people were 50 something, out of work, did not have any Agile experience. Oh, my goodness! How are they going to get Agile experience? Well, maybe “Manage your job search” can give them a little taste of Agile, a little taste of personal Kanban and now they understand what is like to have it work for them. It is not a team-based experience of Agile, but if they can do it and they understand it, maybe this is just enough to get them over the hurdle so they can land a job and now they have a job they can work themselves out of being out of a job. Did that make sense?
Shane: Yes.
Oh, good!
Shane: Thank you very much. The third one – The Agile and Lean Program Management.
OK. So, you know me. I am blunt and direct. SAFe – the scaled Agile framework – is not Agile. It is a great framework and if it helps people move from Waterfall to RUP on steroids, perfect. But it is not Agile. It has a Gantt chart, for God’s sake. It is not Agile. I am all for people moving from more effective place, from where they are to be more effective. I happen to think that stated delivery is more effective than release trains, but if that is where you can go, that is fine. I happen to think that giving people more autonomy is better than that, but if that is where you can go, that is great. I happen to think that small world networks, which is what I am proposing and what was in my blog post, which I have seen work in programs. I have seen it work in programs of 250 and 300 people. This is what works. And its program management, it is what we know how to do. Now, I am very big on two-week iterations, if you must use iterations. I am very big on small batch sizes.
So, when you do small batch sizes and you use continuous integration and sometimes you might need a small team of people to help move to continuous integration. Because if you have not done continuous integration, you do not know how to do it, right? So you might need that. But when you continue to use release trains and only integrate at the end of a quarter that makes your batch size bigger. So, “Agile and Lean program management” helps you understand how do you move to smaller batch sizes, how do you continuously integrate across the organization using the power of the rumor-mill the power of your small world network as you continue to grow this program. One of the things that happen in organization is that you might not need 300 people. This is what I see all the time in organizations. They say: “Here is our program, Johanna. You got 300 people - day one.” You might not need all those people. So what I often do the very first day of the program – because we do not have a charter, we do not have a backlog – is I say to these people: “OK. Organize yourselves into your first two-week iteration in your feature teams because we do not even know what the architecture is, we do not know what their charter is, but we have our teams. Everybody, your first job for your first two weeks – make stuff happen. Your first job is to learn how to learn. Your job is to take defects from previous projects, make sure that you can check that stuff in. Fix stuff. I do not care what project you are on. Take the defects from previous projects, fix stuff, check it in. Can you actually have a conversation with people all over the world? Anything that is an obstacle you either fix or you report to the core team, the core team which is across the organization. It is our job to fix that and whatever you cannot fix yourselves, you report to us. But your job is to fix defects, your job is to fix defects in your team, your job is to fix defects from the defect tracking system and at the end of two weeks we will have a charter for you, a program charter. We will have an initial backlog for the program, we will have a road map and you will have fixed defects. You will have learned how to work together.
You will have charters for your projects because a program is a program of projects. And you will have learned how to work together. So, the core team gets breathing room and the projects have charters and the project teams, the feature teams, have a shot at working together. We have debugged infrastructure. We have not had iteration zero and if we need, if now we need an iteration zero, now we know what we need.” So, that is the way I start programs. A lot people tell me they find great comfort in knowing that they can actually start working and some of them say: “Well, we do an iteration zero after we start working because sometimes we actually now we need to start working on the architecture, we start need to writing a backlog or we start need to doing some other stuff”. I say: “Yes, but now we’ve debug the infrastructure. We know if we need a new compiler, we know if we need other stuff, but we know how to work together.”
Shane: So that initial learning period - the people in the program, the people in the teams just getting to know how to work, how to learn, how to work together.
Yes, and that actually works really well because we have not tried to set things up before we know what we need to do together and it allows for collaboration. That is how we could start collaborating and we start delivering and that is what sets us up for success. The teams chose how they want to work. They want to work with Kanban, fine. They want to do Scrum, fine. They want to do something else, fine. I do not care. It is autonomy. Because I have set the direction. I, the program manager, I have done this myself which is why I have set the direction. I say: “Your job is to learn.” Set the direction, say what you want and now we can start the program. But the program, of course, has already started.
Shane: Wonderful. Johanna, thank you so much for taking the time to talk to InfoQ today.
Thank you so much, Shane.
Shane: Enjoy the rest of the conference!
Thank you. And you, too.