The agile manifesto was written 15 years ago and many agree the principles reflect the true nature of software development. Despite that, we continue to face challenges in making and maintaining the transition. The low-level details of the implementation are often poorly understood, the organizational buy-in can be challenging and the result is a sort ofÂ “worst of both worlds” mashup of waterfall and agile; “Scrummerfall” as our guest John Borys like to call it.
This week I was able to sit down with veteran developer-turned-fulltime-scrummaster John Borys and we reflect on the realities of agile in the workplace and discuss the solutions to several “Scrum antipatterns.”
If you’ve long suspected your process was out of whack this episode is well worth a listen. I’d also recommend checking out our latest offering, ScaledConfÂ if you’re interested in refining and scaling these tools and best practices in your organization.
You’re listening to the "No Fluff Just Stuff" podcast, the JVM conference series. With dozens of dates around the country, there will be one near you. Check out our tour dates at nofluffjuststuff.com.
Hey, everybody. This is your host, Michael Carducci. This week we are talking about Agile, what might be the most maligned principle in modern software development. Everybody seems to be doing…
…and if you’re out there practicing in the real world, everybody seems to be doing it wrong. Where is all this going wrong? I’m sitting down with John Borys. He’s an experienced software engineer, software architect who’s turned full-time Scrum master.
We’re going to talk at length about reflections on Agile practice, where these things start to go wrong, and where we can go from here. This is particularly timely, because it underscores a lot of what we’re going to be talking about at ScaledConf.
We’re spinning up an entirely new conference this year. It’s geared around exactly that, shattering that glass ceiling that limits an organization’s agility. Finding, learning, and teaching the secrets of high-performing teams and all the tools they use, properly implemented and properly practiced. Agile certainly is one of those tools at our disposal.
In addition to that, all the tools in the systems that we have to build around this to make it work, continuous delivery, continuous integration. In addition to learning these practices, dispelling these myths that prevent organizations from achieving the highest levels of enterprise agility.
It’s definitely worth checking out. Registrations are open. Early bird rates are available. Go to scaledconf.com and check it out. But let’s dive in with John Borys and see what he has to say.
We are here in New York City at the No Fluff event on tour. I’m joined here by John Borys. John’s specialty, you’ve been an architect, you’ve been a lead Java developer, but now, you’re focusing entirely on Agile.
Yes, and Scrum Master duties.
That’s a full-time job.
You wouldn’t think so, would you? Some teams, it actually is. I read something recently, somebody said, "An Adequate Scrum Master can handle two to three teams."
Is that right?
"But great Scrum Master handles one." I’m shooting for great, plus it leaves me a lot more time for lunch.
I’m a fan of long lunches. I wanted to talk to you because it’s one of those things. If we had a software engineer, Career Bingo card, "We’re Agile," would be the free space. Almost everybody I’ve interviewed with, everywhere I’ve worked, they like to wave their, "We’re Agile" flag. They are waterfall with daily stand-up meetings that last 45 minutes.
You captured this in your talk, "The Scrummerfall Zone." It’s almost endemic. Is Agile maybe…
It’s an epidemic. I’ve seen it pretty much everywhere, with the exception of one small start-up back in 2008. I’ve also seen Agile work at a large organization, too, but there were some very special circumstances surrounding it.
One of my slides in the Scrummerfall Zone is IÃ±igo Montoya, "You keep using that word. I do not think it means what you think it means." [laughs] The word obviously is Agile, because everybody says that we’re Agile.
I think Van Camp put it really well. Every time that somebody says that to him, he says, "Great. I’m glad we got that out of the way."
Now, how can you improve? I had somebody in the talk today. I asked usually in my talks, "What do you want to get out of this talk?" I do a little Agile approach to the seminar site.
What’s your acceptance criteria for walking out of here saying I didn’t waste your time and you got the most bang for your buck? This gentleman said, "Well, we’ve been Agile for about three years now."
For those who can’t see because you’re listening, I made air quotes.
Nice job, by the way. "We’ve been Agile for three years," he tells me, "But I’d like to get some tips on the QA process and how we can do QA better." He says, "Well, explain that process to me."
As we got to talking, I got to find out that the systems engineers were what they were calling a business analyst. The UX person was a UX person, did wireframes. The program manager was equivalent of their product owner.
This other team would talk and interface with the actual end users, the clients. They would create stories and throw them over the wall to the five developers.
There’s plenty of things wrong with that scenario in terms of the whole reason for our user’s story is a placeholder for a conversation with the business. They were cutting that with the dev team. The dev team was cut out from that. We’re doing hand-off.
The other thing was, they’d spend a sprint doing analysis and design. They’d go into the next sprint and do development. [laughs] They’d go into the third sprint and do QA and testing.
These are like milestones. If you were to plot this all out in some chart, the end of each sprint, they would have this dependency where the first task, the first sprint waterfalls into the second one.
Waterfalls, that’s a good explanation.
Everything is flowing down.
They go sequentially. One is dependent on the one before it.
If you imagine a journey, it’s almost like you’re making this journey and you see these milestones. It’s like, "Oh, I’ve gotten to this point. I’ve gotten to that point."
It reminds me of something, but I can’t quite put my finger on it.
It was like a methodology or something.
Basically, it’s the cargo cult thing. They knew that they wanted to do daily stand-ups. They knew that they wanted to work in iterations.
They knew they wanted to do these things because they were told that that would make them Agile. They even had a certified Scrum Master who, apparently on further digging, didn’t know much about actually building software using the Scrum framework. I hear that a lot. I get that a lot from people.
Even after the course?
No. They want to hire me after the course.
No, the Scrum Master course. We could cut that whole joke that fell flat out. You were saying?
Even if you do cut it out, that’s actually a good point. I went to, after having done Agile, or after practicing Agile principles is what I should say, for seven years in several different places, it was suggested to me by the folks at my company that knew that I wanted to start an Agile practice, that I get the Scrum Master certification.
I went with Mike Beedle, who’s actually one of the original 17 members from the original Agile summit, or whatever you want to call that ski trip they took. Mike said, "At the end of two days, you’ll be able to lead a Scrum team."
The people that were in there, and I’m talking about I have a ton of respect for Mike. If you’re listening to this, Mike, I got ton of respect for him. He’s awesome.
After having worked and seen all the mistakes that I’d seen over the last seven years, and everything I’d learned my own mistakes during that process, I was very skeptical that a two-day course could possibly prepare anybody to take over a development team and lead them in Scrum.
He swore that, you got that certification after two days if you take the test, you’ll be good to go. Obviously, I spent time in the class talking where we had little workshops, and we had lunch, and stuff, and got to know what some of the other people did.
They were fantastic people, don’t get me wrong, and very intelligent as most people in our industry are. Some of them come from a project management background. Some of them were UX people.
They had no experience or background in a short feedback loop iteration development, delivering shippable software at the end of every two weeks. There was no way they could possibly anticipate the questions and the challenges that would come up in leading a Scrum team.
By challenges, I mean actual challenges to their authority. They didn’t have enough experience or enough confidence to sit back and say, "I’ve got a senior developer who’s telling me that user stories are total crap." I don’t have the knowledge to tell them why they can be of help."
I don’t even have the knowledge to tell them that, "You know what? We don’t have to use user’s stories, use cases work," because they don’t know enough about Scrum and Scrum framework. You can’t pack it into a two-day course.
There’s a lot of big picture stuff that…Would you say that maybe the problem is that there’s an assumption of prior knowledge going into that?
No, I’m going to be honest here. I think there’s an assumption of checks clearing going into that. I’m not the first one to say it. Schwaber sold out. Bob Martin has a great video. I wish I could remember the name of it. I know I have it bookmarked at home, but it’s on YouTube. It’s a talk he gave a few years ago. I’m pretty sure it’s overseas.
In the 20-minute mark he starts talking about how project managers have ruined Scrum, which I’ve felt for a long time in some of these companies where I’m working with project managers, because they have this. If you read the Agile coaching book that was written by Lyssa Adkins, I might have that name wrong, but it’s a fantastic book.
She talks about the switch from project manager to Scrum Master, and how you have to really abandon everything you’ve learned, because project management as a practice is so command and control and date driven. They need to feel like they’re in control. They need to…
Well, and also just to share the blame a little bit, they become this intermediary between the software engineers and the business. The business is saying, "We need a date. We’re going to prepare marketing or we need to promise the customer, so what is the date that this is all going to be done?" If you come back with, "Probably quarter one based on current estimates."
I think the problem with that is that you’re even insulating that discussion that really needs to happen. I don’t mean to take this on a tangent, but the business owners don’t understand that there are consequences to every little thing that they throw in there. If they pull you off because, "Oh this is a critical 911 emergency now."
That’s going to cost to sprint, or if they say, "Actually, you know what? I had a new idea. We’re going to do this." That’s fine, and you want to embrace that. It seems like upper management, they want the power to be capricious, but they don’t want the responsibility of understanding that that’s going to affect the timeline.
Right and maybe we’ll come back to Uncle Bob. On that point, you’re exactly right, and Agile improperly taught, or coached, or adopted into an organization gives them what they see as an out. For decades, we’ve been training them as IT people to say, "Look, we have to define the scope up front and then we’ll tell you how long it’s just going to take to build something."
Two very reasonable propositions, and," This this is how long it’ll take us and this is how much it’s going to cost." Then we’ve trained them that, "Hey, if you want to change anything, you have to go through a change of scope request." That change of scope first is going to come to the dev team, and the dev team is going to tell you whether or not it can be done at all.
Then most likely it can be done, so they’re going to tell you how long it’s going to take. Then everybody knows that there’s a cost associated with that and that the date is going to move. It has to go, one organization [inaudible 13:31] all the way up to the CIO to get signed off on that change of scope. Then the date moves out, and the budget expands to cover the people working through that date.
That’s one of the reasons that make change so arduous because it would cost them both time and money. Well now, you’re Agile. If you come to me as a coach and say or as a Scrum Master and say, "You know John, we want to add this new feature and we just saw your sprint review and it brought to mind several new things that we didn’t cover, and then thought you know, hey we need to add them."
I’m cool. I’m a Scrum master, throw it in the product backlog. Well, so we add it to the product backlog. Somehow they now think that because we’re Agile that that won’t expand the time and the budget.
If you ask me what date is something that can be done or we need something done by this date, I have no problem hitting the date, and no problem hitting the budget because we know how many hours a week we’re going to work and how many people we have working. I’ll nail the date. The question is, and this happens in almost every Agile project, the product backlog grows.
As more people see stuff, more stuff gets added. More things come up, things that we forgot about, new requirements to come in from the business. All these things add new items to the product backlog. What we try and do in Agile is tell you to prioritize. You’re going to get the same number of things that we originally agreed to by that date.
That’s a very big generality. It might not be the same number, but you’re going to get the same quantity of work. We’re only going to do what we can do in the time we can do it. You’re going to tell us what’s most important to get by that date.
If you sit there as a business person and go, "Well I want everything." I would refer you back to the previous waterfall scenario and say, "Would you get everything if you brought a change to me in waterfall, or wouldn’t that impact the time and the budget?"
At the risk of going wildly off topic, that seems to be…being able to get the full transition, let me just put it this way, the full transition from waterfall to adopting some variation of Scrum, for example. We’re using story points now. We’re not estimating in hours.
We have our backlog. We estimate the backlog, but we don’t even have velocity yet. Management is grudgingly going along with this and you say, "When is this going to be done?" "Well give us a couple of sprints because we want to get a good velocity number, that…"
No, I would go back to, "When do you want it done?" I had an example with another client where the client asked us to do an estimate. First of all they asked us to estimate something that, we didn’t…they freely admitted they didn’t have the entire scope yet, which is good, because in most cases the scope never ends. It’s always changing. It’s one reason for…
Yeah, the product is a living thing.
Right, they knew that even what they thought they wanted, they hadn’t nailed down yet. "But give us an estimate and let’s do a sprint zero to spend three weeks doing this estimate." Fine, whatever. I think that we could have spent four hours looking at the stuff that they wanted to build and give them just as accurate a estimate as three weeks.
They made us go through this analysis period. We come up with an estimate, and this is March, and we say, "We can have this done by October." The reaction we get from the business when we give them the estimate is, "That’s not going to work." [laughs] Like, "Why did you ask me for an estimate?"
Long story short, they end up telling us they want it done in August. Then, of course, they say, "We’ll just throw a couple more teams at it." We try to explain that in throwing more teams at it isn’t going to solve the problem, but they don’t believe us. They throw a couple more teams at it. August comes and goes.
October comes and goes, because all this whole time changes are coming in. They’re not doing change of scope request because we’re Agile, but they still want everything done. Now we’re past date, which should have been August. Finally, we get done with the project and it’s gone into past Thanksgiving.
We’re doing after-action retrospective with management. I asked this director, "Why did you do that to us? We told you it was going to be at least October. You said, ‘No, August.’ Then, you set our date and told everybody that it was going to be August."
Her response to me was, "Because if I would’ve let you stick with your October, and you could have got it done by mid-September, you wouldn’t have because you gave us an October date."
That’s management’s thinking. They knew August the 15th was impossible. They want to give us the impossible date to make sure that they get whatever they think they’re getting at the soonest possible moment, even though they keep throwing new stuff into the hopper that they want to come out the other end. That’s a fundamental distrust of who you’re employing to write your software.
I’ve run into that numerous times. I finally got to the point where I flat out say to upper management, when you get into these situations, they’ll say, "Look, candidly, you are the least qualified person in the room to have an opinion on this matter."
You’ve hired experts to take care of these matters for you, and you can either trust your experts or hire somebody that you trust.
Exactly. First of all, you have to trust them. They are experts. You’re paying them a lot of money. The other thing is, and this is what I told her. I said, "Well, why don’t you just tell us the day you wanted it done by?"
She looked at me. She was like, "I don’t know." I said, "If you give us the date, and then we’ll do whatever we can, and we’re going to check with you every two weeks to make sure that as your priorities change, and as these new requirements that you’re even unaware of when we started come in, we’re going to add them and then let you prioritize them, and then get as much done by the date as we possibly can." We ended up not finishing and cutting this off anyway.
Which is ultimately what you’d have to do. As you go through this project, "Here’s our backlog. Here’s our velocity. Here’s how many points we can deliver by your deadline. You’re going to get a clearer and clearer picture as you go through the project."
That forces the question, "What is a higher priority?" There were a couple of things you said telling that story that remind me of instances from my past where I know we’re doomed. I know we’re immediately doomed.
One of them was a sprint zero. Every time somebody says, "Well, let’s have a sprint zero," I feel like somebody somewhere hasn’t explained how this works properly. The other one is when the same people who are making demands, the same management that are making demands about deadlines and new features aren’t in the sprint planning. They will not participate.
What are your thoughts on that? If you’re in a situation where the stakeholders won’t participate in the meetings essentially, ceremonies I guess is the word.
They have to. The bottom-line is, let’s take it to the extreme. You’re not going to get up and walk out, quit. That would be the extreme. By not getting up and walking out, you’re conceding that you have to put up with a situation.
What is the next best possible solution? That is to get a representative from them. It’s not the ideal solution. The ideal solution would be to either walk away and go find somebody who’s willing to understand that if they want a good product, they have to be involved with developing that product, even if it’s just to answer questions or make decisions.
The other option is to convince them somehow to change their mind. Let them know that it’s not going to be a lot of time, or show them other companies’ success stories.
I don’t think like a manager or a C-level executive. I don’t know what would prompt them to not want to get the most for their dollar. We’re some of the highest paid people in the food chain.
Wouldn’t you want to make sure that if somebody was building a house for you, and I hate to use that analogy with software, but I’m saying that relationship, a contractual relationship, and you were paying them a lot of money to do something that’s pretty much custom for you, wouldn’t you want to continually have conversations on your huge multi-hundred thousand dollar investment to make sure that they’re getting the layouts right?
That when they’re putting stuff in, to be able to check and make sure that the walls are in the right places, that things are progressing? Not from a "Follow-up on you to make sure that you’re not cheating me" standpoint so much. Although, you want to do that as well, but also to make sure that they didn’t get something wrong, that they didn’t misinterpret what your thoughts were.
On a huge investment like that, I know when my wife and I had our first home built, we went by the construction site all the time. We were so disappointed when we didn’t see a change due to weather or whatever else we didn’t see something that we didn’t see a few weeks before.
Driving by that construction site, especially, we were living with my parents for those three or four months which was horrible because…
Is it done yet? [laughs]
…we had a kid. We wanted to see all the constant improvements. You want to know that that money that you’re spending is being spent wisely. More importantly, we wanted to see the progress to make sure they weren’t screwing up and we were getting what we thought we were getting.
Ultimately, we could have left it alone, I guess. If something would’ve went wrong, or if we would have seen that wall wasn’t in the right place, or the fireplace wasn’t there, we could have done something about it right away.
To take the analogy further, if something came up that somehow affected their budget, and we had to make a choice, I’d rather know at a point before the decision is made that, "You know what? We’re going to have to say no to the fireplace, so that we can get something else," rather than have them tell me afterwards and ask for forgiveness.
"We didn’t have time to put the fireplace in there, sorry." That goes back to this mentality. I don’t understand why it’s not clear that you can’t have it both ways. You can’t be completely hands off to a project as a manager, as a product owner, especially.
At the same time, you can’t blame people if you decide to be hands off. You can’t blame people for making decisions as your proxy, because you haven’t given us a choice.
I want to take it full circle, because we covered a lot of grounds. The main thing I wanted to talk about was this chasm between being "Agile" and being truly Agile. What can we do to get better?
That’s the real question. The one thing that I loved about Mike’s class was he asked us, "Out of all the Scrum ceremonies, what’s the most important?" You could tell instantly who of us in that group had experience.
I knew right away, at least in my opinion and in Mike Beedle’s opinion, what the most important one was. It’s the retrospective.
Which is probably the least practiced.
The first thing that they dump. It’s the first thing that teams dump in my experience…
…if they start it at all.
I’ve always done a few good faith stop-start-continue type things. It’s like, "Yeah," but that brings the onus…We’ve talked a lot about where management is making poor decisions or project management making poor decisions.
This is where it comes back to the team. The onus is on the team to build their process around this philosophy.
Or at least bake in their philosophy into their development process. Even people who do retrospectives focus on the wrong things. It’s essential to have a coach and a Scrum Master.
I happened to play both roles. Ideally, they’d be separate roles because they see things from a different perspective as Scrum Master. While a coach, they’re coaching you towards the objective, which is to deliver whatever you promise during that sprint to the product owner at the end of the sprint. That’s their main focus. Then they get the team to improve incrementally via retrospectives.
A coach, though, is maybe teaching some the same things. There’s definitely overlap there, but their perspective isn’t worrying necessarily about what’s happening in that particular sprint, but the overall direction of the team and the growth of the individuals in the team, and then also coaching at multiple levels so management understands that Agile isn’t a thing that those software developers do.
Agile is not something that’s done at all. It’s a way of being right kind of thing. I hate to get all Zen-y and Yoda, but it’s got to be an organization thing from the top-down and the bottom-up.
This person was talking about this retrospective that they were doing. They said, "Well, we decided that we needed to add a QA environment. That’s what came out of it." I said, "Tell me about some of the things you do in your retrospective."
In his opinion, adding another environment somehow helped them. What actually it was doing was reinforcing the wall between development and QA. It didn’t address anything inward at the team. The key is in the retrospective is, yes, maybe there’s a process or two we can tweak if there’s something that’s drastically wrong.
The main focus should be inward, not on outside development environments for crying out loud, but maybe on XP practices, or collaboration, or communication, or things that we can look honestly at ourselves in the mirror as developers and say, "We can directly change this. I think we should do this to make us better."
Starting a code freeze the Monday before the end of a sprint isn’t necessarily something that might be my top priority coming out of a retrospective. To me, that’s more of an administration thing.
I’m not sure that I agree with it, but I also know that as a Scrum Master, I’m going to let the team make a decision like that and live with it. Even if I think they’re dead wrong in those kinds of decisions, the only way for them to learn is to try it. We have sprints. They’re only two to three weeks depending on what pace you guys pick.
If you have a retrospective.
Right. If you have a retrospective, you can see and talk about, "Did it work? Let’s try this for this sprint. Did it work?" Even those are kinds of things you often get out on retrospective, you need to keep pushing them to look more inward at what their practices are.
By that, I mean the XP coding practices. That takes us full circle back to the thing that I was going to talk about with Uncle Bob in project management ruining Scrum.
He created this certified Scrum Master thing. Project managers who are basically eliminated from an Agile team now have found something to jump on to. You’ll see if you go on LinkedIn and look up any of the Scrum discussion boards, you’ll see people that have CSM, PMP, PMI, whatever, all these things after their name, like they’re collecting acronyms.
They all have the same background. They all came from project management. They were all doing CMMI, or PMP, or something and now, they’ve latched on to Scrum.
Now, you’ve got this shift where Scrum is now becoming something that’s owned by former project managers who immediately want to do what most humans want to do, which is conform things to what you know. They want to change the process a little bit rather than change themselves.
They don’t want to let go of everything that they’ve known for the last 10 years. Scrum started based on XP and coding practices, test driven development. J unit testing test-driven development, first writing test, red green refactor, para programming for code quality, story boards and tasks.
Stuff that we could collaborate on and talk about in turn in a co-located spot instead of putting your headphones on like I used to do when going into a cube somewhere and working in a silo for four hours pounding out code and then dealing with the integration issues later. All those things, those were the things that gave Agile its agility.
Now Agile is turning into something that’s got a certification, and a price tag on it, and a sticker, and it’s more about how I can help you do a better retrospective and how I can help you do this, that and the other thing. None of them have to do with the code. That’s what it really boils down to.
The whole thing had flipped over?
Yes, because the people who are certified Scrum masters and Agile coaches come from a world where they managed programmers. They managed a process. Now we have a self-organizing team. Well that takes power from them. That’s fear, right? They have to find a way to get that power back in order to maintain their level in the organization.
Truly Agile teams, self-organized, or self-led, self-managed, they don’t need somebody managing their process. One of the reasons I’ve done this and I’m trying to do this is because I’ve been a developer for the last 17 years. I just switched full time to Scrum last month. I’m working with developers and they’ve all developed with me before.
They know that I know what I’m talking about and I’ve sat in their chair. I’m not trying to manage them. Sometimes, they’ll try and push that responsibility onto me and say, "Well, you can do that." I said, "That sounds like a project management thing." "Yeah, it does but you’re the Scrum Master, so you’re sitting in that seat." "No, no I’m not."
It takes the courage to say those things.
Right, "You guys need to manage this now. All I’m here to do is help you when you stray, when you start falling into those old waterfall habits, I have to help you back.
When we’re having a sprint planning meeting and you’re spending way too much time on details that don’t matter because you’ll uncover all that stuff once you get into the code anyway, those are the kinds of things I’m there to help you with, stay focused and coach you on improving yourselves.
I’m not here to manage your project, or handle all your dependencies, or do any of those things. You guys have to figure out solutions for that." A project manager who’s a Scrum Master wants to do all those things.
It’s counter to the whole idea. That brings up a really important point. If I look back on my career, there’s definitely a line from when before and after I had the courage to lead. That, "Oh, well I just have a crappy job. This is the culture of the company." Cultures are not inherited they are created and…
…sustained. It’s when I had the courage to say to the manager, the only person in the room willing to stand up and say, "You are the least qualified person in this room to have an opinion. You either need to trust your experts or get new experts if this entire project is going to succeed."
In a lot of places, they could show you the door after a stunt like that. That’s why it takes courage.
Maybe that’s not where you want to be then. But that’s a big example. A smaller example is having the courage to say no to things like that and be in that role, or take on the role as a Scrum Master. I worked somewhere and we desperately needed to change how we were doing things.
Nobody else was going to do it. It’s this attitude of, "Well, it’s not that type of company." No, you make the company that you want it to be. That’s how I’ve developed this philosophy that if you’re working more than 40 hours a week…this is what I decided for myself, if I’m working more than 40 hours a week, I screwed up somewhere.
It means I over committed. It means that I allowed the culture to progress, or to trend towards a churn and burn shop, or I chose a bad job.
I had this scenario where…the one I talked about, where we took the three weeks at the beginning to do the estimation and then she gave us that impossible deadline of August 15th. The weekend after Labor Day in September, my boss is asking me and the rest team, if we’ll work through the weekend.
It went around, "Are you in? Are you in?" I said, "Absolutely not." She said, "What? You’re not committed to the team?" I said, "No, first of all I have plans. It’s a weekend and I have a family. Second of all, if we had those three weeks back that you’ve made me waste, when I told you it was a waste of time at the beginning and you refused to listen to your expert.
Instead we spent three weeks in a sprint zero which is just a total pile of crap in my opinion, if we wouldn’t have wasted those three weeks doing an estimate, instead came up with an estimate that you were going to reject anyway, by the way, in six hours, you wouldn’t be asking any of us to work this weekend."
The people who said, yes, they were in and they did. I did not go. I did not lose my job, but when we did the review I was talking about, I got invited to that thing with the upper management. They knew that I refused to put myself out there for that to do the death march thing. They wanted to know why. Maybe if I didn’t answer that correctly things would have been different.
Once I explained to them the point of view and then asked her the question about, "Why didn’t you just tell us when you wanted it done?" I got a "Thanks for your candor," thing. I’m not saying that that’s always going to happen, but I think, like you said, if you give the candor and somebody shows you the door because of it, then you should say, "You know thank you for letting me out of here now."
I’ve worked myself half to death and I’m not going to do that.
At No Fluff Just Stuff, we bring the best technologists to you on a road show format. Early bird discounts are available for the 2016 season. Check out the entire show lineup and tour dates at nofluffjuststuff.com. I’m your host Michael Carducci. Thanks for listening and stay subscribed.