Derek Neighbors: Welcome to another edition of the ScrumCast. I’m Derek Neighbors.
Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich.
Community Questions From Twitter
Derek: Today we are just going to take a few questions that we have gotten over twitter in the last few days. The first question up is…Do you have recommendations on particular reading materials that are good for people to learn the basics?
Resources and Reading Materials
Clayton: The basic stuff. I think there’s quite a bit of good information on the Scrum, the Wikipedia entry for Scrum. That gets you some of the glossary and some key terms, and then other than that…What are those two…there are a couple of Mike Cohn books?
Derek: Yeah, I think Add, Estimating, and Planning by Mike Cohn and User Stories Applied by Mike Cohn are both great kind of planning and user story gathering books. James Shore has Agile Practices or Art of Agile Practices, something similar to that that I think is a really good overview of a number of different agile methodologies including Scrum.
The Agile Retrospectives books by Esther Derby/Diana Larsen is another really great book on retrospectives. The good news is, there is much stuff out there from just a pure content blogs and websites, strong just going to ScrumAlliance.com or just ScrumAlliance.org or any of the XP extreme programming site, both have a lot of downloadable content available.
Clayton: Yeah, the interviews and articles, especially the interviews on Infoq.com whenever they do anything with pretty much any technology or methodology.
The person that they interview always has to do some introduction, because you know, under the assumption that whoever is watching this episode may be know what Scrum is so that person always will do a good introduction. I found this would be helpful.
How Do You Recognize a Dysfunctional Team
Derek: The next question. We have got a couple pretty good ones here, so we are trying to target these to be 15 minutes or less, you can catch them right at the end of work or walk around the block.
This one might get a little bit deeper, but I think it is something that is good fodder for discussion and that is…how do you recognize the dysfunctional team?
Clayton: Yeah, that is a good one. There are lots of different things. One of the things at least in my experience is that, a good sign of a dysfunctional team is when you have got lots of…I guess maybe passive aggressiveness is a good way to say it where team members want to either some problem or something that some team member’s having with another, or with a process or something like that.
There is lots of grumbling, all solve your problem and I’ll also make some kind of back handed comment about it and maybe I won’t help you out later when you need something, that kind of stuff. That happens a lot. What about you Derek, what do you think?
Derek: It’s Patrick Lencioni has a great book out there: Five Disfunctions of a Team and you can map those directly across to agile principles as well. Anything that exhibits a lack of trust which is hard for some people to tell, that there really is a lack of trust but the one that I see more often than not are…the two biggest I see are Fear of Conflict.
Nobody wants to say the hard things or to step out or to make any kind of waves, it’s “I think you’re wrong.” “No I’m not wrong.” “OK, I’ll let it go.” To me that’s a red flag that there’s something deeper going on.
The best stuff gets made when people have a healthy debate an argument about how to solve problems. The other piggy bank on to that is the absence of commitment or accountability, like I’ll do anything possible to shirk accountability and all of those are rooted in fear and there rooted in fear because there’s lack of trust for the people around.
Clayton: An important part about the trust aspect especially that book just in general Lack of Trust, a lot of people misinterpret that to mean that, that for instance, either I trust or don’t trust Derek to do his job.
But what the book, what they’re really trying to get to is that you have the trust required to feel vulnerable so that you don’t feel…if I really trust Derek and Derek trusts me then I’m OK saying, “Hey, you know what? I screwed up” or I don’t know what I’m doing or I don’t have the means to solve this problem. It’s really that’s the important part that other team members can trust each other and be vulnerable with each other.
Derek: It’s hard to build that stuff too. I’d like to say that time is one of the only things that can really make that happen. That’s probably one of big things that new adult themes fall into is that they want to gel and to have all of these.
They look at this is what a high functioning high velocity team is made up of and they want that overnight, and truth is that those teams get built over sometimes a matter of years in working with people. That’s a tough one to do.
Next question, this is one that I’m curious to hear. I’d love to hear even outside opinions of this, so when we post this, if people can comment on this, it’d be great. That’s, “I’m facing having a team with wildly differing work schedules, I’m finding this makes estimating and stand‑ups more challenging. How do you handle that”?
Different Working Schedules Makes Things More Difficult
Clayton: Having very different schedules on a team is going to make things difficult. A lot of people have that problem mostly because people have this desire to have different schedules. Maybe they’re used to that, or they want certain things. I don’t know that there’s a really easy way to overcome that problem other than to get people on more similar schedules.
That’s going to be painful, and some people aren’t going to like that, obviously. It is very difficult, especially when the team’s out of sync. We’ve experienced this. If you’ve got people that are coming in much earlier and leaving much later, there’s this overlap for that. You also have people taking lunches or breaks at different times.
You get to a point where the team as a core only has two or three hours out of day where they’re actually all together, working in the same space with the ability to answer and ask questions with each other. That’s really challenging.
Derek: My gut reaction is there’re the legalistic answers, and there’s the more fluid answer. The fluid answer is, “What impact is it having on your team”? If you can work all different schedules, and have virtually no impact on the team, then it’s really not an issue. I’ve yet to see anybody really do that, but I don’t want to be facetious and say, “It’s just not possible.”
It might be possible on some really highly functioning teams. I’ve seen it tackled one of three ways. Either fear of conflict, and nobody deals with it.
The other option is the middle‑of‑the‑road option, the best‑for‑everybody mentality that is to have some form of core hours where you say, “From 10 to 2, or 10 to 3, everybody’s got to be in the office, and everybody goes to lunch at the same time. You can come in earlier, you can come in at 6 and leave at 2, or you can come in at 10 and leave at 7, but you need to be here from 10 to 2.”
That can work depending on what your work environment’s like, the type of work you’re doing, whether you’re doing XP pair programming, and the hours of your customer. Are you doing internal product development? Are you doing consulting? A lot of that has a lot of play into it. If you’re dealing with external teams, you have to get on a schedule with some of those external teams.
The last way I’ve seen it implemented is a much more rigid approach which pretty much says, “This is the time that the entire team works, come hell or high water. Take it or leave it. We work from 7 to 4, 8 to 5, 9 to 6, or 10 to 7, or whatever it is. It’s expected that you’re there within those times.”
There’re pros and cons to each one of those approaches. It depends on what type of work you’re doing, who you’re doing it with, and how you do it. It depends on the pluses and minuses of each of those choices.
Let’s see, two more, and they’re really good questions. The first one is, “What is the agile response to a request for a proposal, i.e. RFP, when the true answer is, we don’t know time or cost until we are done”?
Agile Request For Proposal Responses
Clayton: I’ll let you field that one, Derek. You’ve got more experience in that regard.
Derek: It’s really difficult. In the RFP, you can really document or describe your process, and how you handle that. There’s a few estimating techniques where you can take an RFP, and you can derive some kind of high level guesses or estimates on those.
You can say, “Do we think we can do something like this based on the RFP that’s been put in place”? What you do at that point is you’ve got the Triple Constraint, so you can say, “We can do it for this price with this feature set in this time frame, assuming that you don’t change anything.”
If they’re going to stay completely rigid on that then everything’s good to go, if they need to be able to change, if they need to be able to change the scope, you can do that, but you just have to know that there’s a cost adjustment for that.
What we’ve seen some success in, in responding to RFPs, is our approach of user stories and creating a backlog and responding to the RFP with a backlog of estimates and then having lots of language talking about how that relates to scope change, that’s a much more appealing process for most larger companies than the change‑order requirement hell that they’re normally put in from a contract perspective.
The hard part of that is getting a contract written that speaks to those scope changes without having to have the inordinate amount of documentation around every little scope change.
The last question, what happens when the team is agile but the company is not? What are the first steps to get agile practices at a strategic level?
Communicating Agility Up The Food Chain
Clayton: One thing that a lot of people on a development team or even at a scrum master, project manager level, they see a lot of success with what they’re doing and people can get stuck in a rut where they can’t think of any ways that translates up the food chain.
One of the things, I feel like if you’re on an agile team and you’re developing things and providing lots of good value and doing things in a good amount of time and you’re doing all these things, you’re reaping all these benefits, the benefits that you’re seeing, those directly translate to business goals or some business value.
Those are things I think that it’s just a matter of finding some way in your organization that you could translate the successes that you’re having with your product development into, hey, here are things that we’re doing, and here are the benefits that we’re seeing, and this is how those benefit you.
That’s one way to drive that change, from the bottom up. Here’s all this great success we’re having. If you guys could make these incremental changes, keeping in mind that you have to make baby steps that would be a good way to drive that change up the food chain so that you can start experiencing that more across the organization.
Derek: I’ve yet to meet a CEO that isn’t interested in the fundamental principles of agile. I think the problem that we generally have as practitioners is we have to change the language we use when we talk to C‑level executives. Most of them want to be able to use the word “pivot.” They want to be able to pivot their company in a different direction.
I’ve yet to find one that’s not interested in being an innovator or being able to be ahead of the curve. Agile practices allow them to do that a lot more simply. It’s a matter of getting them to say, hey, the same way that we’re able to take a feature backlog and create that feature backlog and break it down into sprints, and to tackle those sprints, and allow ourselves to change as need be, you can do a very similar thing from a strategy perspective.
You can say, what’s the goal we’re looking for? Can we break that goal down into smaller segments or smaller chunks and still have a long‑term goal? But if two months into our strategic plan, our biggest competitor does something completely different and out of the water, and we need to change course, we’ve got the ability to do that.
A lot of big corporations fall into this. They basically create a five‑year strategic plan and it takes them four years to update it, so they get totally submarined. If you look at a Blockbuster and a Netflix comes along and has a totally different model, the inability to basically pivot and say, can we compete in that market, took them probably three to four years to even get their product out, and at that point, it was so far behind and had become so irrelevant.
They spent so much money trying to get that product to market that they basically submarined their stores. Again, I don’t think there’s a single CEO that’s not interested in being able to be nimble or pivot or you name it, but I think we just have to stop talking in technical terms and start talking in marketing terms or in strategic terms to get them to understand that these very same principles can be applied to the work that they do as well.
That segways in. Hopefully next time we’ll talk a little bit about scrum outside of software. Can you use scrum to manage an organization? And with that, we’ll see you next time.