Community Questions

Episode 6

March 07, 2011




The Agile Weekly Crew discuss questions from Twitter.

Episode Notes

Clayton Lengel-Zigich and Derek Neighbors field questions about SCRUM from Twitter.

Reading recommendations for SCRUM Basics.

How do I recognize a dysfunctional team?

How do I deal with team members with wildly different schedules?

What is the agile response for a Request for Proposal?

What happens when the team is agile but the company is not?


Derek Neighbors:  Welcome to another edition of the ScrumCast. I’m Derek Neighbors.

Clayton Lengel‑Zigich:  And I’m Clayton Lengel‑Zigich.

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?

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 Cone books?

Derek:  Yeah, I think Add, Estimating, and Planning by Mike Cone and User Stories Applied by Mike Cone 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 retrospective books by Esther Derby 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 or just 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 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.

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 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”?

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”?

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&#