Lisa Sieverts was our special guest.
Her Twitter: @lsievert
Her LinkedIn.
Transcript
Yegor: Everybody hello, this is Shift-M podcast and you’re listening to the next episode number thirty one. We have a special guest today—Lisa Sieverts. Did I pronounce the name correctly?
Lisa: That was perfect.
Yegor: Okay. So, Lisa, could you please say a few words about yourself: who you are, what you’re doing, what’s your experience?
Lisa: Sure. I’ve been a project manager since the mid 1990s when I worked at Hewlett Packard Company out in California in the U.S. and like many project managers I fell into the role, I was doing technical work and because I also had some people skills, I became first a tech lead and eventually found out about project management. And so I learned about PMI, took some training courses, passed my PMP in about 2001, and soon after that left Hewlett Packard, started working as a project manager on my own with my own small business. Eventually in New Hampshire I discovered Agile in the mid 2000s, became Agile Certified Practitioner. Soon after that certification was available and I’ve been working freelance ever since then.
Yegor: Sounds like an impressive career. We decided to talk about Waterfall today which is the subject which we’ve never touched in the last 30 episodes of this podcast and it’s really interesting for me because I’m not against Waterfall in general, that’s why most of my questions will be like kind of provocative, so get ready for that.
Lisa: I was expecting no less from you.
Yegor: All right. So first of all can you just, to warm it up a little bit. Was it useful for you to get the PMP certification? Lisa: For me the PMP was essential because as I started my own business working as a project manager, I did that at the same time that I moved across the country from California to New Hampshire and so not only was I starting a new business but I was moving to an area where I didn’t have very many connections. And in fact where I live is relatively rural and so the business community there didn’t even really understand what project management was. So as I was networking, doing speeches, trying to get myself known, the fact that I had this credential and I could point to the fact that it was an internationally recognized credential was essential for me as I got my business started. I would say that now in 2018 it rarely comes up. And I do want to say that I do much of my work is the Agile project management, but I do feel like there is a place for Waterfall and it’s so important for us to understand when to select Agile and when to select Waterfall.
Yegor: You know, I was on one project management conference a few years ago, and said to someone that I have a PMP certification, and the answer was: “The PMP is dead. All this traditional management is dead, Agile is now, so throw it away.” So what do you think about that?
Lisa: I think, as you’ll hear as we talk today, I think that there is a place for Waterfall and it’s just that we have to make a very informed decision about whether Waterfall is the right way to go or whether Agile is the right way to go. I have both certifications. I have the PMP, I have the ACP. It makes me feel that I have a big tool box and so based on what it is that my customer needs I can go into my tool box and pull out the right tool to help them reach their goals.
Yegor: But people think that things from traditional management, project management like scope control, quality control, risk management, we just don’t need them in Agile because Agile is just better. Do you also think so, like there are two separate, completely separate, not overlapped areas, or we still need these traditional management tools and instruments inside Agile?
Lisa: I think it really depends and it depends on what tools we’re talking about. And it also depends on the method in which we are applying those tools. I do feel that one thing that we can throw away to a great extent is that true command and control type of management especially when we’re working with teams of knowledgeable people doing work that’s based on their intellect and so I think that idea from Agile is very important and we can apply it almost across the board. At the same time I think that there are great tools and techniques from the PMP, from more traditional project management that can be useful on Agile teams as well.
Yegor: Yeah, but look, for example, you’re saying command and control is dead or it has to be dead. But the PMP suggests that we break down the scope into work packages and their inside work packages we have like job orders. So orders means that we order some want to do something for the project so it is command and control somehow. So do we completely need to remove that from Agile or we still have people who are supposed to do something for the project and we have orders for them.
Lisa: Well let’s get into my definition of when Waterfall is the appropriate project management style and when Agile is the appropriate project management style. And so I’m going to be talking about extremes. You know, what is a project that absolutely needs Waterfall versus what is a project that absolutely needs Agile. The truth is that most projects are going to fall somewhere in between on that continuum but I think it’s important for us to talk about the difference and the way I like to start this conversation is to remind everybody about the iron triangle, the constraints of project management. You know when we talk about the the iron triangle we’re talking about the balance between scope, time and resources. You know we’ve always kind of joked around and said: “Well you can either have it fast, or you can have it good, or you can have it cheap, but you can’t have all three.” So we’ve always told our teams that they need to emphasize which one of those is most important. But I think that iron triangle also tells us what style of project management is needed. So here’s my first possibly controversial statement, which is that Waterfall is the appropriate project management style. When scope is the most important driver, that is when 100 percent of the identified up front scope must be delivered, so often these are construction type projects. certain types of engineering type projects, where the scope is the most important thing. Where Agile should be chosen, if time and money are the most important drivers, so I pause there and ask, Yegor, what your thoughts are? Yegor: Well no thinking, I’m imagining myself standing in front of a potential client and asking the client: “What do you want more—the scope, or the time, or the resources? And I can imagine in most cases the answer will be “All of the three of them” because I can’t imagine a customer saying “Sure I don’t care about time and money, I only care about the scope.” So can you really imagine a project or a customer who can actually specify which one of these three items are the most important?
Lisa: Absolutely. And I usually try to help my clients out by giving them an example. So I say “Let’s imagine a project where time would be the most important thing. So for example maybe we’re doing a product and we have to be able to show it at a trade show that’s coming up and that trade show is only going to happen over a 48 hour period on a defined date. Absolutely. The most important thing for that project is that we are present with a demo at that trade show and therefore we may make changes to the scope. We may spend more in other words those other two parts of the Triangle are more flexible in order to optimize for time. On the other side if we’re imagining a project where absolutely the scope and when I say the scope I mean the planned scope. So what did we define upfront as the boundaries of this project. The deliverables, the things that we’re going to create. If the identified upfront scope is the most important thing and there’s no flexibility in that scope, then we have to let time and resources be more flexible and of course this is what we’ve seen in most Waterfall projects which is why Agile was developed in the first place because what we saw was when we were committing to a hundred percent of the identified upfront scope. And our job was to fight scope change all the way through, what we usually saw was that the budget had to increase and the schedule had to increase in order to deliver 100 percent of that identified upfront scope. Now Agile lets the scope be almost entirely flexible. And so that’s the difference there. We let the scope be flexible, we optimize for time and money.
Yegor: And you think it’s possible to switch that style of management for the same team, for the same people, we’ll do Agile and then we say “You know what guys, starting tomorrow we have a Waterfall. So get ready for the command and control and all this fighting for the scope and all that.” They will say “No problem”. Do you think it’s possible?
Lisa: I think that’s a leading question. I think neither you nor I think that an individual team will be able to easily switch back and forth between the two different sets of tools and techniques.
Yegor: So we need to switch teams, we cannot just use the same team for different management style, right?
Lisa: I don’t think you’d want to because Agile projects need a different approach, a different way of thinking, a different set of tools and techniques. It’s possible that you could have a very mature team that would eventually develop both sets of skills but it’s not going to happen overnight.
Yegor: And you think the Agile team is like the next-level after Waterfall or they are just different levels and different, you know, different areas?
Lisa: I would see them as equal but different
Yegor: Because most people say different, they say “Agile is the next step after Waterfall”. So we used to do Waterfall. We were you know stupid and incompetent but now we are way better because we have Agile, we know how to manage things better. But you’re saying it’s not true.
Lisa: I would say it’s not true and I would say that in many ways Waterfall is harder. And especially it’s harder to do well. Agile has so many places where the system is self correcting and therefore even as you’re learning, you are able to do better work and discover problems early and fix them.
Yegor: You know people say about Agile, it’s not… like you said Waterfall is more difficult. But I’ve heard many opinions about Agile, that Agile is just way a loser comparing to waterfall, so Waterfall is something more disciplined and regulated. While Agile is sort of a chaos where everybody does whatever they want and in the end, maybe, if we are lucky we get the result.
Lisa: I’ll definitely argue with you there because I feel that Agile definitely has structure. It has tremendous discipline to it and of course we know that Agile does include basically all of the steps that we do in a Waterfall project. It’s just that we do all of those steps in much shorter cycles of time in much smaller chunks of work. But there’s a tremendous amount of discipline to Agile as well as discipline to Waterfall.
Yegor: Okay let me ask you a personal question. Have you ever experienced people blaming Agile for the failures of software projects or any projects?
Lisa: I have definitely seen teams, heard teams… I would say teams love to blame the the overhead processes in general. So whether we’re talking Agile or Waterfall, we can definitely find teams that will blame whatever overhead process we’re using for the failures of the project.
Yegor: Because maybe I was too young when Waterfall was on the market but now I hear a lot of people who are blaming Agile for their failures. They are just saying that maybe it’s the wrong implementation of Agile. Maybe that’s why I think that maybe there are managers who just didn’t understand it correctly and they just understood that there is no control anymore, like you said, no command, no control, means like let little programmers go as they like and that’s it. And in the end the whole team suffers.
Lisa: Yes, I do think that one of the big challenges of Agile is the amount of culture change that is required up the management ladder within organizations. It’s not enough to wave a magic wand and say “Okay development teams, you are now Agile”. The whole planning process within the organization has to change as well, and my understanding is that organizations that make that change which shift their whole planning process to a more Agile planning process are seeing much more success with Agile.
Yegor: Well that’s true. You know I’ve heard people saying that what’s the most important for the success of a software project is people, not the process. So when you get the right people no matter what is the process, you will get the result. What do you think about this statement?
Lisa: That’s asking a lot of the team, I think that it is true that an excellent team, knowledgeable people, who all want to achieve a great result, that team is capable of figuring out a process that works for them to deliver those great results. But it’s going to take some time for a team starting from scratch to come up with processes that work for them, for them to decide for example to start with Scrum and learn Scrum and implement Scrum. That’s like a kick start. It gets them going much more quickly. And then of course once they’re fully knowledgeable then they can make modifications to the process in a way that really works for them. You know as you and I both know, the big goal is to deliver value to our customers. And so we want to give our teams the tools that they need to be able to deliver value quickly.
Yegor: I really liked that you said that no matter what, but the team will figure out the process and there will be the process, even if it didn’t exist in the beginning, they will create it by themselves, right?
Lisa: Yes, I think any team, any good team is capable of figuring out a process that works for them. It’s just that if you don’t give them anything to start from, that’s going to be time consuming on its own, while they figure out a good process. I’d rather start with an already documented process. You know, Scrum if it’s going to be an agile team. More PMP based if it’s going to be a waterfall team, you know give them a foundation, so they don’t have to start by digging a hole in the ground and building the whole thing out from scratch.
Yegor: But you know people who are really agile advocates, they sometimes claim that just you know software development is something which requires a lot of creativity and sort of artistic work. And that’s why we need less and less rules, discipline, principles of work, regulations. So let us work the way we want let us do the work because we’re good specialists, we’re good experts. So let us work without any rules. You think… well you know my question is do you think Agile means no rules?
Lisa: I do not think that Agile means no rules. I think that the rules of agile are good rules and that they are designed to help teams be as creative and productive as possible. But there are definitely rules. There’s definitely discipline in agile projects and I think any good agile team will agree with that statement at 100 percent.
Yegor: All right. We’re on the same page here. And another question: right now in 2018 do you still see teams and programmers and technical people who don’t know about agile and they still work in only waterfall model. Do they exist?
Lisa: Yes.
Yegor: And are they planning to change their work model or they want to stay in the Waterfall?
Lisa: Most of the teams that I come across in that situation are wanting to move to Agile and I’m going to see that because that’s part of what I do. I do a lot of training and mentoring to help Waterfall teams move to Agile and so it’s a self-selected population because that’s generally why I’m being brought in to do a training session with the group.
Yegor: And what are the key problems you face when you upgrade… when you help people move from waterfall to Agile, what are the key psychological or I don’t know some fundamental issues you face when you do that with people?
Lisa: Definitely one of the things that comes up every time is looking for the right balance in terms of the architecture of the software product that’s being built. Typically there are experienced architects on the team, and their identity has been based in doing that big upfront planning activity to develop the overarching architecture for the product and it can be very hard for them to let go of some of that planning and to realize that moving to a more emergent software architecture can often be a more productive, more efficient, more effective way to go, but it can be very hard for them to let go, and because there tend to be the most experienced people on the team, it leads to a lot of internal discussion before we decide to go ahead and give it a try.
Yegor: So they are afraid to change their mind or what’s the fear? What’s wrong with them?
Lisa: It’s definitely not fear. It’s a sense that they know best. You know these are tend to be very smart people. They’ve been in software development for 10-20 years and their job has been seeing the big picture all the way through. And so it’s very hard for them to let go and to be willing to say “You know what, maybe we don’t have to perfectly specify the entire architecture upfront”. And usually the way I’m able to get through to them is to focus on the topic of waste, because what happens with that big upfront planning activity is that we often get well into the project, and then discover that there’s some element of that architecture that has to change, and we may end up throwing out quite a bit of what was planned upfront and usually as I go through that, even these kind of hard boiled engineers and software architects start to remember all the times when parts and pieces of the architecture had to be thrown out or changed, and then they start to say “Okay we’ll give it a try. We’ll try it one time, we’ll try it on the next project ,and we’ll see if your way works.” And that’s all I’m asking for. It’s not a commitment to be Agile for the rest of your lives. It’s just a commitment to try it once and then see if you like it better. Most of the times teams like it better.
Yegor: So most of the time they convert from…
Lisa: Yes, in terms of the software development teams that most of the time it really is the case that Agile is the better choice for software development because scope is not the most important thing, but time and money are the most important thing. In those situations Agile is better. I did want to mention… I think well I have a second here. There are two other things that I like to add on to my definition of when should we use Waterfall and when should we use Agile. And one of those is the concept of the cost of change and the other is the concept of the cost of delay. So when the cost of change is high and the cost of delay is low, then we’ll be safe in a waterfall environment. So you know it could take longer. And the main thing we’re trying to avoid is scope change because any change is so expensive. I mean think back to software development in the 1960s, when cycle time on a mainframe processor might have cost you a million dollars, you know, in that situation the cost of change is very high. And so it makes sense to use our waterfall processes to identify everything upfront. But in most software development today the cost of change is very low. When we talk about cloud services working in AWS, you know we can spin up servers with just a few clicks of a mouse. So cost of change is very low and for many software projects the cost of delay is very high and therefore we want to be able to get a product out as quickly as possible.
Yegor: So it sounds like we were not technically able to apply Agile, say, 30 years ago, is that what you’re saying?
Lisa: That’s what I’m saying. And now we can.
Yegor: Yes you know when I was working, I took a participation on start up a few years ago and they were designing a product which included a hardware part and a software part and for the hardware the production cycle, for the piece of hardware was like 3 months or so. So for them it was… I’m just giving probably a good example for what you said… and for them it was difficult to do agile with that part because you cannot you know experiment a little bit and then spend three months for waiting of the hardware and then see that it doesn’t work. Experiment again and wait for another three months. You have to do everything up front in the right way because otherwise you will waste a lot of time. So maybe this is a good example for what you said.
Lisa: So yes, many hardware type products have this limitation where the cost of change is high, though it’s also interesting to note that sometimes we can reduce that cost of change by changing the way we build that piece of hardware. Some teams have found that it’s worth it to purchase a 3D printer because once they have a 3D printer in-house they can essentially print the mockups, print the prototypes, print working versions of the hardware. And in that way they can shorten their cycles or sometimes it’s a case of changing the relationship with vendors, so that the turnaround time becomes much shorter. You know sometimes there’s nothing you can do and it’s just a three month turnaround. So such that the cost of change is high but sometimes there are things you can do to shorten that time and reduce the cost of change.
Yegor: Going a little bit back to what you said about your experience. It’s sounds like you have the biggest problems with the most experienced people in software teams.
Lisa: I would say that’s a reasonable rule of thumb and extends to the management team as well.
Yegor: So they are the problem? The bosses..
Lisa: I think it’s it’s too glib to just say that they’re the problem. They’re bringing valuable knowledge. And for me it’s a challenge on my side to think of a way to tell the story to kind of help them to think about these tools and techniques differently, to be a little more open minded and just willing to try it out. As I said before I’m not asking them to commit to Agile for the rest of their lives. I just want them to try it on one project and see what they think. The reality is that most of the time they try it on one project and it’s enough better, that they want to try it again, and try it again, until finally you’re you’re getting to the point where it’s moving throughout the organization.
Yegor: And how long it takes for one project, a one team to realize that agile is better?
Lisa: That’s sort of difficult to answer, you know, in a way that says for every team it’s always going to be. But my experience is that for most teams within three or four sprints they’re starting to really see the benefit of working this way. Now there are a lot of assumptions built into that statement and one assumption is that they’re getting good information. So if we’re talking about scrum, it’s you know that they have a good product owner who is providing them with accurate information about what’s valuable about this product and what’s the appropriate prioritization. So without that kind of partnership on the product side it’s more difficult for a team to feel like they are doing good work.
Yegor: And do they have to work more or less after transition to Agile? Personally these people, programmers.
Lisa: Yeah I would say overall, it’s not so much working last but working much more sustainably so that rather than periods where you spent a lot of time waiting, waiting on other people and then other times when you find yourself working around the clock, working weekends, pulling all nighters. You know that’s sudden are not sustainable pace of work. Where agile, it’s much more steady year. You spend much less time waiting and much more time doing the work but you don’t see those crazy all nighter week working weekends and nobody taking a vacation type of situation.
Yegor: Interesting. But what you said that some people sometimes have to… I mean we have to let them go because they can not transform, they can not get used to the new system. It happens, right?
Lisa: I didn’t say that but I definitely agree that some people will probably self select to say that they just can’t work in an Agile environment. And I think that will be true on any team, no matter what you’re doing. You know someone some people will say “Well I can’t work in a Waterfall environment.” So we do have to understand that there may be change in personnel as part of any transition.
Yegor: And what do you think are the qualities a good programmer should have to be a good player in an Agile environment? What are the key most important characteristics. I’m not talking about Java skills or programming skills but what are the soft skills so called?
Lisa: Ok yeah, because I was definitely going to start with the technical skills. So I think the skill that I think helps people to be the most successful in Agile is the skill of self awareness the ability to observe one’s own reactions to the events taking place around that person. And so part of that is understanding for each person understand well what are the things that frustrate me? What are the things that make me happy? What are the things where I feel that everybody’s out to get me. What are the things that make me feel supported by my teammates? And so some of that just doing that personal internal work of developing your self awareness is what will help you the most on an Agile team. And I would argue that it’s definitely a useful investment to do this because it will help you not only in your work but also in your personal life.
Yegor: I’m not sure I understood completely, so you were saying that I as a developer have to know exactly where my faults are, where my competences are, and somehow deliver that information to the team or what exactly should they do, you know, to be a good team player.
Lisa: It’s more so imagine that we’re saying we’re in a retrospective meeting and something has come up. So maybe I’m a programmer A, and it’s a retrospective and something that I coded had a problem this time, so the self-awareness piece is for programmer A, as we’re talking about this, to be thinking to themselves: “Oh I’m noticing that I’m feeling defensive” and that’s the most important thing is to be able to say to yourself: “I notice that I’m feeling defensive, or I notice that I’m feeling angry, or I notice that I’m feeling uncertain”, so that you have this moment of self-awareness before you react before you say anything. You know it’s a skill that we learn if for people who are doing a little meditation, a little mindfulness. It’s really a skill your brain is a muscle and you have to exercise that muscle in order to learn how to do these things. But once you learn it, it’s just a tremendous skill and it gives you a lot more control over your life, your emotions, and your reactions.
Yegor: So it’s not about Agile only, right?
Lisa: It’s not about Agile only, but it becomes more apparent in Agile because we do things like the retrospectives, even the daily scrum. You know we’re always looking at not only what we created, but also the way in which we did the work, and when we look at the way in which we did the work, that’s going to touch on the human to human interactions that we had, the way we communicated with each other, the spoken and unspoken messages that we sent to each other. So agile is a kind of poking, it’s poking at us all the time and asking us to be more mindful and more self aware.
Yegor: And you think we could be dangerous to each other with our emotions if we don’t control them.
Lisa: It’s not so much a matter of controlling our emotions as being aware of our emotions. You know you can be angry. But I’m just kind of saying, put a little bit of a filter in front of it, where you’re noting to yourself: “Ah, I’m angry right now.” And there’s a way of sharing that with your teammates, where it’s your informing your teammates without trying to hurt your teammates.
Yegor: I get what you’re saying but maybe, I’m just suggesting, maybe it’s better to place everybody into different rooms, or different cities, or different countries and let them communicate virtually, and that will solve the problem because they will not be able to show to each other that they’re angry, they will just be creating the code and communicating via some online chat where you can be angry.
Lisa: Yeah but I think that you run into the danger of people checking out from the project no longer being fully invested in the success of the project to the point where they’re they’re just putting in the time without caring about the result. And I would argue that in order to do good work we actually do need to care about the result, which means we need to care about each other as teammates, you know it doesn’t mean we all have to sit in a circle and sing Kumbaya together. But I think even on virtual teams you need to have open and honest communication with each other and you can’t just wave a magic wand and say “Okay guys, have open and honest communication with each other”, there’s a level of trust that has to be built up and team members who have this self-awareness will be better able to move into that position of mutual trust more quickly.
Yegor: Do you think it’s possible to train people to do that? Or it’s something which have naturally, or we don’t have?
Lisa: I think absolutely, it’s something that for most of us comes from training. I know for myself the first time somebody told me that my brain was a muscle and I had to exercise it in order to recognize my emotions, I just thought that was crazy talk. You know, I mean it’s your brain, you can’t control your brain it’s just going to think whatever thought it wants to think, there’s a great saying, that the Buddhists say, which is “Don’t believe everything you think.” And the first time I heard that, I just couldn’t even take it in. But through training, through reading, through talking to others, developing knowledge I came to really believe that that’s the case. You can’t believe everything you think, your brain is a monkey and it just will think all kinds of crazy things. And so by adding this muscle which is developing your filter of self-awareness, you can kind of say to yourself: “Do I want to think that thought, is that thought useful to me? Well, maybe not. Okay, let’s move on.”
Yegor: Can you recommend some you know training skills, training hints for how to do that, aside from meditation, I think meditation is number one, right.
Lisa: Yeah, definitely there’s a lot of Buddhist literature mindfulness meditation literature that is a great place to start. And I just want to make it clear to everybody listening that what I’m talking about is not Buddhism as a religion but instead a method of basically training your mind. And there’s a whole way of approaching Buddhism that isn’t religious at all. So the ribs is there and there are many other places even in the Agile community where you’ll find a lot of good information. About how to be a good team member in this way.
Yegor: So maybe companies should check those skills on the job interviews before they get people on board? Because it seems like according to what you’re saying, and I start to believe that, is that those skills are way more important ability to write Java code.
Lisa: All right. And I know you had an interesting conversation with Johannah Rathmann about hiring folks. Johanna is definitely a guru of mine. I just think she’s one of the smartest people in Agile and you know she would definitely say that you want to be hiring people for much more than just their technical skills.
Yegor: Yeah, that’s what people are saying now, that we have the soft skills so-called not difficult to define what exactly the soft skills are. But I hear that very often, the companies are looking for great set of soft skills and it’s difficult to define what they are. You just defined them and I like that self-awareness is one of them, definitely. Lisa: Yeah and there’s so much that comes from self awareness. When we talk about many of the kind of classic soft skills, if you’ve already got that foundation of self awareness then the other parts and pieces are easy and follow along naturally.
Yegor: What do you think about conflict resolution? Is it difficult to do them in Waterfall set up or in Agile? Because people do have conflicts, technical conflicts, interpersonal conflicts, all different sorts. So where, in which model it’s easier to resolve conflicts?
Lisa: I feel that it’s easier to resolve conflicts in an Agile environment in part because it’s the way things are set up. We expect, we understand that conflict will occur and we expect and understand that creative disagreements can actually be very good for the product. Because with some contention we can often come up with a more creative solution than otherwise. I think one of the downfalls of Waterfall is the way it’s designed to often try to prevent conflict, or prevent disagreement, because sometimes they’re just things we can’t talk about, like we can’t talk about changing the scope, because we have to deliver 100 percent of the identified upfront scope and…
Yegor: So let’s just not discuss that.
Lisa: Let’s just not discuss that, right.
Yegor: But on the other side, I’ve seen many discussions, and many meetings and many hours of time spent on things which are not important at all, and people still discuss them. They enjoy these meetings. They burn time on those activities and they call it Agile. So maybe it’s another extreme, maybe it’s wrong as well. To just you know discuss for the sake of discussion.
Lisa: I think I understand some of what you’re getting at. And you know we may decide in an Agile team that there is an aspect of inner team communication that we want to spend some time on. But the way I would say “Let’s do that” is “Let’s use a retrospective or perhaps set up an additional meeting.” But timebox it, so it can’t take more time than we think the problem is worth and also make sure that someone is going to facilitate that meeting so that we have good processes to follow and so that it’s not just a bunch of guys and gals sitting around a table talking.
Yegor: And what do you think about the role of a project manager or a leader or I don’t know how do you call them in specific Agile teams, but I’ve heard a lot of opinions saying that the large amount of falls, or the majority of falls are the responsibility of the project manager. Do you agree with that, according to your experience, or you don’t think so.
Lisa: Well, first I would argue to at least with Agile to say that you know we don’t have project managers on Agile teams. We have product owners and scrum masters but they are not hierarchically above the team. They are part of the team and they are with the team, so the classic Waterfall role of project manager just doesn’t exist on a textbook Agile team.
Yegor: Then who is responsible for the failures?
Lisa: The team.
Yegor: So who’s to blame. I mean I’m not talking about like blaming blaming but still if the press the project fails and we lose the money, or we lose the customer, we need to find someone who should have some responsibility, should have to pay something for it. No?
Lisa: Why?
Yegor: To learn the lesson, not to make the mistake in the future, to not repeat the mistake.
Lisa: I agree 100 percent and I would say that’s the team’s lesson that needs to be learned.
Yegor: And don’t you think that if 10 people are responsible for the failure, in most cases it means nobody’s responsible for the failure?
Lisa: I disagree. If a team is working in an Agile way and again remember we’re talking about teams of ideal size, five to seven people, the team is responsible for delivering value or not delivering value on the project, and a team of five to seven people can take responsibility for that. The flip side is we also need to reward that team when the team is successful.
Yegor: Yeah, I totally understand that rewards and this punishment you know side they have to be go and balance. But my major concern is that when it’s a group of people then each particular person will always try to blame the neighbor, to try to blame the colleague, not to blame, but expect in other words somebody else to be responsible for the result. So if that’s a group of people responsible for everything, it means that every single person in the team will feel less responsible. I think so, no?
Lisa: And that’s kind of I mean the secret sauce of Agile is that a team collectively cares about the product that they’re creating. And that they’re not looking to a neighbor and saying well that guy’s to blame. I saw my fault. I was just sitting back doing my job. You know that’s the piece, you have to fully engage. You have to bring your whole human selves to the project, to the product and that’s what’s hard about Agile and frankly I think younger workers are better at this than people my age. Because in my experience a lot of people have been taught to just do the minimum, you know don’t fully engage, don’t bring your whole self to work. And so they’re more willing to just blame their teammates, where the younger people coming into the workforce, are willing to go into it with both feet and work really hard to have a team that works together to deliver great results.
Yegor: In your teams do they fire people sometimes? Like let people go?
Lisa: Yes.
Yegor: And how this decision is made? Who makes the decision?
Lisa: So we still have resource managers and Agile. In my experience the team that I’m thinking about, it’s a situation where the team has spent a lot of time working with an individual to help them to be better at the work that they’re doing and the way that they work with the team. But if someone is really dragging down the team and it’s happening over a repeated period of time there’s still reasons to have to fire someone. Though sometimes, I’ve also seen where someone just needs to be in a different role, and maybe they’re not successful in a certain role but somewhere else they’re super successful. So I think there is a place for that kind of conversation about you know “Hey person, what is it that you really enjoy doing? What do you feel your best at?” And maybe we want to try one other position before this person is actually let go.
Yegor: Yeah. My question is who’s starting with conversation or it just happens like on this pirate ship? They sit together and say “Okay, now it’s time to discuss Jeffrey”, and Jeffrey comes, stands in the middle of the circle and we all discuss Jeffrey’s behavior or how it’s happening. Because in traditional team we have a manager and the manager called Jeffrey out of the room and they discuss and manager says “You know your metrics, KPI’s are low you’re not producing enough. You’re fired, see you later.” What happens in an Agile team when there is no manager?
Lisa: So it all starts with the team. And so they’re the ones who are going to be talking to the resource managers. So I mean in most companies there are still resource managers who deal with the HR type responsibilities of management. And so at a certain point the team needs to bring in their resource manager to deal with this from an HR point of view. I would argue that the team has to do the first hard piece of the work. Which is really seeking to understand from that person’s point of view. You know, how did how did they perceive their own work. What did they see as their own strengths and weaknesses. What’s their own action plan for improving their results. So the team needs to do that before they get a resource manager involved.
Yegor: So if I’m a programmer in Agile team, I’m supposed to be afraid of the entire team in a traditional team I’m afraid of a manager. Now I am supposed to be afraid of all seven people around me.
Lisa: Wrong! We’re supposed to love our entire team and welcome the way that our team has our best interests at heart. And the way our team is helping each one of us to be the best person we can be.
Yegor: Ok, so it sounds like a good final thought for this podcast, so it seems like Agile is more about love comparing to Waterfall which is more about something else, right?
Lisa: Okay, yeah, I’ll take that. That’s a decent summing up.
Yegor: All right. Thanks for the conversation, that was really interesting indeed.
Lisa: You’re very welcome. Thank you so much for reaching out to me.
Yegor: Absolutely. See you maybe next time.
Lisa: Ok.
Yegor: Bye-bye.
Lisa:Thank you. Bye bye.
