- What is a code retreat
- Sometimes wrong is better
- Mocking, flow and learning new languages
- Microsoft cloud offerrings and exposure to new tools
Clayton Lengel-Zigich, Jade Meskill, Derek Neighbors and William Price III sit down to discuss design in agile software development.
- Challenges of design in iterative development
- Pace and lead time
- Mutual respect
- Everyone’s a designer
- Design tools suck
- Backlog overwhelms
- Ship early and often
- Crossfunctional teams
- Style guides
- Light weight wireframes
The Mike Cohn’s “I’m always right card” is a joke from a training session with Mike.
Derek Neighbors: Welcome to another episode of ScrumCast. I’m Derek Neighbors.
Jade Meskill: I’m Jade Meskill.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
William Price III: And I’m William Price.
Derek: Today we want to talk about…
Jade: The third.
William: The third.
Derek: Design in Agile Software Development. I just want to start an open dialog on, what are some of the challenges, of implementing design in an iterative methodology.
Jade: We are talking web design specifically.
Derek: Lets start with web design and if you want to go beyond that we can. But lets start there.
Jade: It sucks.
William: I think my experience with design for a website or whatever is that a designer comes up with some idea of something. It’ like a waterfall. Everyone’s used to the designer comes up with something and makes this nice pretty PSD. Somebody else slices the PSD up and it turns it into HTML and CSS at some point in time, and then that becomes your web app.
I think that’s probably like 90 percent of the people out there, their experience with doing design. When you take than and try to put that into Agile, it makes it really difficult to say, “Well, this week we’re working on this set of features, and we need to design for that now or soon or whatever,” because I don’t think that’s how most traditional designers work. They need more lead time than that.
Clayton: Yeah, I think from a designer’s perspective the lead time is typically considered the biggest challenge, just the pace. I think a bigger challenge is knowledge and appreciation that overlaps as much as possible between developer and designer.
You often hear people say, “Everyone is a designer.” That makes me kind of uneasy, because I think design is a craft. It’s a skill that you have to hone over time. Anyone can hone it. Anyone can learn it. Anyone can learn to draw. Anyone can learn to think well and design. The thing that makes me uneasy about everyone is a designer is that when you say that it’s like, “Oh, so now I’m a designer today, instantly.”
As a designer that makes me uneasy, but what I need to do is develop relationships with developers and with product owners where I can appreciate their input and work with them as fully as possible. As a developer, being involved in that process and considering it meaningful I think is often missing.
There are some developers that will say, “Oh, yeah. I think that’s important.” But do you spend time learning the fundamentals of design and things like that? Or do you just go by what you think looks good?
Then as a designer, appreciating the developer’s input and not just thinking, “Whatever sexy pretty thing I come up with, is the best solution” because it may not be the best solution for the process.
It may be a huge nightmare for everyone involved. It may be far more expensive than it’s worth. You might be developing something that looks great, feels great, to the product owner but gets torn out a month later because users don’t use it. Working together and having a tight relationship, that’s the biggest challenge in my opinion.
Jade: Well, I think to address something you said. You’re talking about everyone is a designer. Some of that came from a Thoughtbot article that we read as a team and had some discussion about. What I think he’s…
Clayton: Or is it, Derek who said as a team like three years ago?
Jade: Yeah, yeah, yeah. Where’s your Mike Cohen I‑know‑everything card? Can you pull that out right now?
Jade: Now I just lost my train of thought. Thanks.
Jade: Yes, Thoughtbot. So I think what they’re trying to drive at is not that everyone is a professional designer in the sense that we think but that everyone plays a role and should be conscientious of design, right? It’s not acceptable for developers to just say, “Well, I don’t know anything about that because I just write code” and crank out some really crappy‑looking interface.
We should be at least conscientious of the basics of what we’re doing and that it should be professional and not, like I said, some hack job that you know a developer put together because you can just tell. I think that’s what they’re driving at.
Clayton: Yeah, so I think an analogy would be I wouldn’t be able to figure out a good color scheme and whatnot for, say, my house. I’d probably paint the walls white and leave them some stupid color, and I wouldn’t bother decorating. But when it came to arranging the furniture, I wouldn’t put the couch in the middle of the room facing away from the TV or something stupid.
So I think there’s something to be said for maybe you’re not very good with the design theory or color theory or some of the things that may be more traditional design when you think of design are. But in terms of maybe the user interface or how things flow or just sensible decisions, I think that’s the kind of designer that everyone could be. Just take a step back and say, “Does this make sense? Yes or no.”
Derek: Analogy wise maybe it’s similar to, I expect most adults to be able to drive a car. I don’t necessarily expect most adults to be able to race formula one, or race NASCAR, or race the Baja 500.
I think that there’s definitely a difference of level of, and I think there should be expectation of people who are developing software to understand, like you said Clayto, to not put the couch facing the opposite direction of the TV in a functional living room space where 90 percent of the time people will be watching TV.
I think we see developers do that every single day, do things that make absolute no sense. I think to me I’ve got two additional questions on a design in iterative fashion.
One is we start to see iterations become shorter and shorter. I know one time in a Scrum that was pretty much a given that a sprint was a 30 day or month long function or iteration, and now we’re seeing sprints down to, a week are pretty normal. Two weeks are probably now the standard.
In some days we’re pushing more towards Kanban where it really is a sprint might be, an iteration might be, in a day, or less than a day. How’s it feasible to, not even talking about coming up with the design, but how’s it even functional to implement the design in that quick of a time frame.
What are some of the challenges? We’re starting a sprint on Monday, we’re ending a sprint on Friday and we’ve got to go from design implantation in five days. What are some of the challenges around that?
William: I think one of the challenges is the tools. Just to make an excuse for designers, that I think is legitimate, is that the tools suck. There’s been a push to do all your design and development in the browser. Then there’s this push to handle it all CSS3.
Do everything you possibly can CSS3. Granted the great designers out there are able to be really involved in the front end development and do minimal stuff in Photoshop. In general to work fast is difficult with the tools that we have. I would love to see that improved.
One thing I’ve been trying to get in a project that we would do here from a designer is to as much as possible think on a feature oriented level, instead of a site wide level. To design just for what needs to be designed, you don’t need to design a whole page.
If you’re developing a feature and it’s a widget in the corner of a page, the whole page could be a wire‑frame and that widget could be designed. The challenge there is to be consistent throughout, to have a good vision of where you’re going.
I think a designer that has good skills should be able to do that, should be able to stay consistent throughout, to keep going within the same vein of things. To keep the look and feel going but be able to turn around a widget fairly quickly and not to get so concerned about the whole page.
I’d be really interested to see a project go from conception to launch with that whole process. So far it’s been a challenge to see that. I think that could be a potential solution.
Jade: That’s one of the complaints that I’ve heard from a lot of designers. I need to understand the big picture. I need to understand the world before we can start implementing some of these designs. If we start on sprint one, let’s just say with no design in place, we didn’t do a design iteration or anything like that.
How do you see that developing? How do you maintain that vision of the bigger picture and the bigger idea when you’re doing it week long sprints?
William: That’s not a rhetorical question? You want me to actually answer that?
Jade: No I want you to.
William: [laughs] That’s a difficult thing to ask. I think there’s different scenarios. Are we talking about sprint one is a true sprint one and there isn’t this backlog of things that have been predetermined. I think that’s one thing that weighs designers down is when there’s already a whole bunch of stuff predetermined, and they’re saying, “Wait, I can’t think about this. If this is going to happen, I need to think about this.”
I think a great example of success is Tumblr, which is founded by two guys who had a division of labor between them, but they had a major overlap. They were both very invested. One was a developer and one did business and design and stuff like that as far as I know.
And they worked iteratively. I think Tumblr has a beautiful interface. It’s very usable. It’s very simple. I don’t know what their sprints were, but they worked a portion at a time. They kept maintaining. I think whenever they came to a big impasse, as far as I can tell, where there’s going to be a major shift, that’s where you look at, “Do we refactor design?”
I think there has to be a willingness to say, “OK. We’re going along. We’re consistent. We’re going a certain direction. OK now, we’re going to make a big leap in a different direction, or a change. We’re doing something we never foresaw doing, and so that means that we need to go back and rethink what we’ve already done.”
I think the big fear is, “We’ll never get a chance to do that, and if we don’t got it right the first time, we’ll never be able to improve.”
Jade: I think that’s a little bit easier to accomplish when it’s a couple of people, and you’re personally invested in…You’re not only just the developer. You’re also a stakeholder and product owner and all those things. It’s easier to manage that relationship because the relationship is with yourself.
In a typical scrum team of five to nine people, that gets a lot messier and a lot harder to deal with. I don’t know what the answer is to try to do design at the same time as development. You see a lot of people trying to run design ahead of the game, but that leaves some opportunity for mistakes and waste.
“If we don’t do that story next sprint, now what?” The world changes, and we’ve got to re‑prioritize the backlog because some new business requirement came up or some new opportunity showed up, and now, there’s no design for that. Now, it’s chaos and panic.
Clayton: I think that as we get towards the shorter iterations, the idea of doing work in Photoshop and then slicing it and chopping them off into a lot of stuff, I think that totally goes out the window.
The same way that I don’t think you can go forward from, today, being a developer who just writes code, you have to have other skill sets. I don’t think that you can be a designer who doesn’t know HTML and CSS.
I think that if you can get to a point where you are getting out of Photoshop as early as possible, that gives you the ability…I think there’s something to be said for having a Photoshop mockup of something to show people because people think that way or they like that stuff.
If you can do design upfront or at least do a week ahead, whatever sprint ahead, where you’re not designing specific features that you might not do, but if you’re doing things where you say, “Here is the overall look and feel of the site…”
Personally, I think that if we got towards where people are using style guides where you could say, “Here is the overall look and feel of the site, and here’s the style guide for 80 percent of what you’re going to run into as you’re developing the feature,” then the developers can hit the ground running with their iteration, not having specific design for every single feature, but they could have enough to get by where they’re not going to get hung up on something.
And if they do, it’s probably just a quick fix. They could just talk to the designer about what’s the best way to handle this. Then, now that that frees up the designer to work on…If there are specific feature things, you could do something where they’re one step ahead of you where the world isn’t going to change that much perhaps.
William: Yeah, I think a style guide is a great way going back to what I’m saying later about keeping that consistency. You could spend that time upfront developing that style guide of colors and padding and margins and things like that, grid, all that kind of stuff, and then live inside that model, that framework.
Designers do great inside a framework. I don’t know a single designer that resents having a framework to work with within. It’s actually freeing. I think another thing that can speed up the process is, I agree with Clayton totally. That you ought to have that ability to be a front‑end developer at least the HTML and CSS and to do that.
But instead of spending all your time in Photoshop, maybe spend more time with pencil and paper. One of the first things that they’ll teach you in your design fundamentals class in art college is your first idea usually seems great and almost always sucks. Sometimes your first 10 ideas suck.
One of the first assignments I ever did was I had to do a logo of my initials a hundred times, a hundred different logos. It was bang your head against the wall annoying. After 50, 60, 70 of them, you can’t think of any new way to do it.
As a designer, you learn to be that way. So if you go straight to Photoshop, it’s a struggle to do that because it takes time. But if you go straight to the browser, it’s even more frightening because it’s like, “Well, if I do all these and I get it but it’s not the best solution, I have to rip it all out and start over and rip it all out and start over.”
But maybe if we spend more time as designers with pencil and paper going through that mental process of bad idea, bad idea, bad idea, decent idea, bad idea, bad idea, bad idea, there’s the one, and then go straight to the browser and implement. Or like you said, minimal time in Photoshop creating an element like a tiled background image or an icon or something like that, and then get that in there.
I think that could be a great process for a designer where they know their style guide. They know their framework. They hash through all the ideas on pencil and paper. Then they get to the browser as quickly as possible.
Derek: One thing I thought that was interesting at the beginning, as you said, it’s really difficult when you see the entire backlog and to not think about everything in that backlog. I think that developers fall in that same trap. “We’ve got an architect for the 491st thing in the backlog even though we’re on sprint one.”
In the back of my head, I’m wondering, “Is this one of the reasons that maybe Kanban has taken a little bit of frontrunner approach, and that a lot of people are liking it is that it tries to move so quick and obfuscate more than the next 10 items? Does it give a calming effect to designers and developers that they’re only worrying about the next two or three things as opposed to item number 391?”
I think it’s part of a different discussion but interesting nonetheless. So product owners hide as much of your backlog from your developers and your designers, and you might see their velocities go up perhaps. It’s a theory. You might try it out, but you might try it out.
The next question I have, and this starts to go into a different element of design and what we’ve been talking about here which is probably more of the visual design and that is…I hear a lot of people say and really talk about, “How do you do usability or discovery?”
“How are you going to ask an audience of people? How do you really get these questions answered about what the product is really supposed to do and how it’s supposed to work?” I think a lot of people even ask, “What happens to the business analyst?”
We used to have this business analyst. Now, we’re in this Scrum team. How does a business analyst go gather data for a particular user story during the actual sprint?
If I’ve got a 5‑day sprint, how do we do discovery on what the best way to solve this problem is within a 5‑day sprint or a 10‑day sprint, opposed to being able to gather some of that information up front to understand that? Maybe talk a little bit about some of the challenges or some of the things that we lose by not doing that as much anymore as we used to, or how we can incorporate that into a shorter sprint length or sprint cycle.
Clayton: I guess I’ve never really been convinced that…Even if you had a business analyst and you had people that were out doing a bunch of research and interviewing potential users and blah‑blah‑blah, you’re never going to come up with a great solution on the first go anyway. It seems like you have to go take that leap of faith into Scrum or Agile or whatever and say, “I’m not going to get it right the first time, but I’m going to get something out there that we can start working with and gathering feedback on.”
I feel like it’s like an “emperor has no clothes” thing, because there’s a lot of people that are probably thinking, “That might work for your project, but, trust me, I really need to know all these details for my project.” I don’t think that is the case in almost any instance.
Derek: Let me, maybe, rephrase it to make sure I’m understanding. You’re suggesting a way to combat this is to actually release shippable software as often as possible and use the shipped project as the way to collect that information. Once you get that information, reiterate and make the changes necessary, based on the feedback you got from real customers.
Clayton: Right. Yeah. Actually use the point of Scrum or some other process.
Jade: I think that’s pretty interesting. Maybe that is some of the source of the problem. We’re OK with not getting development exactly right, right out of the gate, but a lot of the projects I’ve worked with, they’re obsessed with the design being correct the first time out of the gate.
“We’ve got to get it right. We can’t afford to mess this up, because then nobody will ever come back and use the system again.” We’re psyching ourselves out, because we feel like we’ve got to nail this thing the first time around. We completely forget to be Agile about the design itself.
William: Yeah. It’s a lot like the whole Flash mentality of, what, the early 2000s, which was, come out with this Flash app that’s your whole site, that’s so fun and there’s things flying and noise being made. The Internet was so new to people that they went and used it and were like, “Oh, my…You can do this on the computer? This is amazing!”
Then, it lost luster because people were like, “I just need to get this data. I just need to know how to get there. I just want to know what the hours are. Just tell me.” Now, obviously, with mobile, everyone knows the implications of that.
Point being is there was this ability that people had, developers and designers to shock and awe people and to get them really thrilled. That was mostly because the Internet was so new to most people. That’s over now. It’s done. You’re rarely going to put something out that is going to excite someone just because they looked at it.
If you’re a designer, you’re going to look at design and be excited by people’s good work. If you’re a developer, you’re going to look at ideas and concepts in development and be excited by their elegant solutions and things like…
William: And APIs. Yes.
Jade: [laughs] Their sexy, sexy APIs.
William: And their fables.
William: But your common user doesn’t care. I mean, they do but they don’t. It’s really a combination of everything that matters to them. Can they get what they want quickly? Can they get through it easily? Is it confusing or not? Does it look good? Meaning, good to the layman, decent, not look bad. Does it look broken? Does it look inviting? Does it communicate the brand?
Those kind of things are the big pile of influence on whether or not a user wants to keep using it. The big temptation, I think, with design is that a lot of times, product owners that have an eye for design and designers want it to be so attractive and so exciting that anyone who looks at it is going to be really impressed.
I don’t even think it’s an ego thing most of the time. It is sometimes, but most of the time, it’s a business value thing. It’s like, “I think that if this gets perfect, then people will be thrilled and excited and think it’s the best thing that’s ever happened.” But it’s not that simple. Users don’t work that way.
Clayton: I think another big part of it is that if you’re the product owner for some start‑up or even just a product owner, maybe you don’t understand the technical details, but you know what looks good and what doesn’t, according to you. I think that’s why everyone gets so caught up on the design stuff.
It’s like, “I don’t really know how this workflow should work, and I don’t really understand what you’re doing in the ‘backend,’ but I can look at this and say, ‘Wow, that’s really pretty.’ There’s other websites that I like, and they look kind of like this, too. The people that I want to attract on my website, they look at those websites, too.”
It’s just something…It’s simple. It’s a high‑level thing, but everyone has an opinion about it. Product owners generally don’t have an opinion about how you implemented that technical thing, but they have an opinion about how it looks.
Jade: I think it’s a trap, too, because it might look really good, and it’s a total disaster from a functional standpoint. It might look shiny and pretty, but when you go to implement it, users just can’t understand it. “But, man, it looked so good on that comp that I got.”
Derek: I think the biggest trap that people fall into is, everything was an overnight success. If you look at ‑‑ I use an example of Twitter. If you were to look at Twitter today, it looks pretty reasonable. It’s got some pretty sexy UI elements. It’s got some nice UX layouts, where they’ve got some sliding drawers and some techniques that are a little bit more cutting‑edge.
If I were to try to create something that competed with Twitter or had functionality similar to Twitter, I wanted a timeline feed, perhaps. And I said, “I need my timeline feed to look just like Twitter, because people will not accept a timeline feed that’s not as good as Twitter’s timeline feed.” What we forget is, rewind back five, six years to when Twitter started and look at what Twitter’s timeline…
Jade: Look at the first release of Twitter. Ugh. [laughs]
Derek: The new, and I’m doing air quotes here, Twitter didn’t come out until a few years ago, after or, not even a few years ago. Less than 12 months ago, after they’d already taken almost $60 million in funding.
I think, with it, that people get obsessed on, “I have to compare myself to the thing that is fully funded and has been out for a better part of five, six years and has hundreds of millions of users on it. That’s my benchmark.” Instead of saying, “We’ve been working on something for three months, and we want to release the first version within the next quarter. We need to iterate over how our users use this product.”
I think you’re absolutely right. People get way too fixated on, “We have to ship finished, and we can’t iterate, but code wise, you can do whatever you want. If we need to add a feature here and there, that’s great.
But the minute we put a feature out the door, it has to be perfect, because we can never come back and visually make it different, functionally make it different, or aesthetically make it different, or people are going to say that we failed and we didn’t work.” I think that that’s a mistake.
Jade: I think there is some challenge in that, though. Because the Internet is moving at such a fast pace, there are some pretty revolutionary things that come out, that do become almost mandatory, that do become expectations of how things should work. I think that is a challenge that we’re always going to be faced with, is how to keep up with the things that are now mandatory, that six months ago were nice‑to‑haves.
William: I agree with you, Derek. I think, I would challenge a little bit the idea that people, product owners in particular are comfortable with not having all the functionality as well.
Derek: Yeah, I agree that a lot of them don’t do that.
William: You go, “I want to go up against this x thing that’s been around for six years.” They’ve had six years to develop all their features. When I come out of the gate, I want to be at par with them, in six months.
I think that’s a major issue for design, because what you end up doing is just, as quickly as you can, designing everything. It over‑accelerates the pace of development. You shouldn’t be trying to develop. The one that product owners love to reference, Facebook.
Jade: Facebook. Yup.
William: In six months.
Jade: But it’s already been done, Billy.
William: “But it’s already been done.” Yeah. So why are you doing it again?
Derek: My idea’s different.
William: Here’s the thing about really great design. Going beyond the skin of it, going beyond even the couch analogy, is, it takes time to really understand whatever your problem is ‑‑ however you want to look at it. Your problem, your problem‑solution analogy, your friend, your creation, whatever. It takes time to sit with it.
Going from an iterative perspective, allowing things to come out of the gate less than perfect, and building from the ground up. I’m not talking about slowing down development or doing it deliberately more slowly, but increasing the amount of releases you have, and accepting that you’re not going to make a world‑changing design on day one.
What that does is, it allows your design team to really get to know the brand the way the users encounter it, to get to know the way the users want to use it. You get that time to realize, what people are doing with Twitter is not what we thought they were going to do with it. The way people are using this or that product, this was not what we expected, but this is what they believe we are and what they want us to be for.
Then, it allows you to go back and do what new Twitter did when they said, “We’re not a social network. We’re an information network. From now on, that’s what we’re focusing on. We’re going to design for that.” Then, you can come out with something that’s sexy and impressive and great.
Jade: And functional, and accomplishes the business goals.
William: Yeah. It’s not contingent on success, that you come out of the gate at that point. Which is the big fear, is that if we don’t come out of the gate at this level that’s way up here, then we’re going to fail, because no one is going to want to look at it. But you don’t even know where people are at with it yet.
Derek: Thank you, guys, for your time. I think, hopefully, in the next quarter or so, we’ll do another one of these on design and talk about some of what we’ve learned and where we’re going with it and maybe invite in a couple of outside guests and see how some other shops are doing it. Until next time, we’ll see you. Thanks.
- What is done?
- Works on my machine.
- Real data.
- Workflow verification.
- UI/UX completeness.
- Whole product thinking.
- Planning Meetings & Acceptance Criteria
Derek Neighbors: Welcome to another Scrumcast. I’m Derek Neighbors.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
Derek: Today we want to talk about something that a lot of teams struggle with, and that’s the concept of “Done is done”. I guess to start off with Clayton, what do we mean when we say “Done is done.”?
Clayton: That’s a hard one to sum up in one phrase. There’re a lot of things that go into it, but I would say that it’s basically, if you want to go with more of a book answer, you want to delivery potentially shippable software. That’s an easy definition for that. Obviously you need to expand on it.
Derek: There’re a lot of exceptions depending on the size of your team, and what team functionality is. You might draw a different line in the sand of what is done. Meaning, maybe I’ve got a Q and A team that is entirely separate from my team so done is done for. My team would be making sure that we’ve done A, B and C, and we’ve handed it off to the Q and A team, and when we’ve handed it off to the Q and A team it’s thereby done.
For today’s conversation we want to talk about “Done is done,”, is that a single team is responsible for the entire chain all the way to deployment. What does it mean to be done in order to deploy? What we see a lot is a developer will say “Oh, this is done.”
“Mrs. Product Owner, it’s out there. It’s totally ready to go. Go check it out.”, and a product owner comes in and they go to the website and say “I don’t see how to…Where do I get to this”? “Oh. Well, you have to enter like this super magic URL to get there.” “OK.” They go in and they pull out some data, and they press a button, and boom the software blows up, and then there’s a defect.
Obviously not done, but thought it was done. Today maybe let’s go over what are some things that hold developers back from being able to give product owners features that are actually done the first time.
Clayton: Take your maybe less savvy, what you want to call it, developer not doing any automated testing. Those people in my experience…I got into the industry. I’m going to do some feature, and I’m going to spend a lot of time manually going through their entire process. I know how to make a testing, but one way that people go wrong with that is they choose the golden paths. It’s a phrase I’ve heard before.
I know that I need to fill in on these fields, and I know that if I put a two highway number in this field, it doesn’t going to work, so I normally put ten in that field. I know that I need to press the submit button, and I know that when I get to the next page, there’s a bunch of [indecipherable 03:18] , but there’s this little link down here. If I click on that, “OK, sweep, it’s done.”
They’re just lazy in that regard. They don’t think about it in terms of how someone actually is going to use it. I would say for the more savvy developer, that’s actually writing automated test.
It’s really easy to do the same thing when you’re testing. You have different test cases, but you still do the golden path for a lot of those. You don’t think to put in much crazy test cases, maybe you shouldn’t. You don’t necessarily wanting to catch every single edge case, but it’s still easy to do that.
Also, you get the false sense of security of while this feature is tested when you actually maybe deployed of that. The product owner is looking at it. They don’t do the same except that you did in your test obviously. You get the ball of the software.
Derek: I definitely think that that’s one of the biggest things that…at least in web development. I don’t even say we see this slot in mobile development. It’s not actually deploying to target platforms and do the testing.
It’s the classic, “Hey! This works in my environment. Everything is great,” the works on my machine syndrome, so going along, blistering along, everything is great, and I handed off, and the product owner complaints that it just doesn’t function at all. You scratch your head and say, “How the hell? I’ve worked on this for four hours, and I’ve not seen anything remotely close to what you’re talking about.” You’re completely crazy.
You go to the diversion of the operating system on the mobile device or their particular mobile device where you go to their web browser and you go, “Oh, oh, oh. I forget about that dependency or whatever.” That is probably one of the lowest hanging pieces of fruit that developers can do to get a better done is done and that is, make sure that you’re deploying to a solid target platform.
If it’s multiple platforms, we see this as mobile, if you have to support multiple versions of the operating system or multiple versions of a browser, they are actually doing deployment and a test with those and before you ask that product owner, do the same thing. Because invariably, they will pick the one platform that you did not choose to look at, in order to do their testing.
Clayton: Going along with that would be appropriate data set. It’s really easy when you’re developing some feature, and you’ve got your two dummy users in your system, and everything’s kosher. Then you’ve got to deploy it to the target platform, or the staging server, even in production. Everything goes great when I looked at it, all the functionality works, but it’s unusable.
A big part of done is done, is that from beginning to end of the whole feature, it needs to be usable in a reasonable way. Not something that requires tricks, excessive waiting, or all those kind of things. You really have to be sensible in that regard.
Derek: That’s a big part. Even automated testing sometimes even makes it worse, but regardless, it exists even without automated testing. That’s the whole sensible workflow chain. What does this feature look like from cradle to grave?
We get too hellbent on, “We’ve got these great regression tests, so when I go add this new piece of functionality, a feature that builds upon new feature, I’ve already tested the original feature. I’m testing the feature that I’m building that piggybacks on top of this feature, I don’t need to go walk through the visual workflow.”
In reality, the product owner gets to it, and they say, “I did this, and I did that, but there’s no way to get to this other thing short of having to go the long way around the fence.”
The other one I see a lot of times is missing roles. It works great as an admin, but as a guest it doesn’t work. It’s supposed to work because you’ve built this funky thing on. Making sure the UI and the UX are reasonable is a big part of making sure that things don’t come back.
Clayton: A lot of that, the UI, UX stuff…A lot of developers probably put on their I’m‑a‑developer hat, and they don’t want to get into the front end or UX mentality. Even if you read some basic stuff about UX or information architecture, or whatever those people call themselves these days, even if you knew basic stuff about that, it’s really just a common sense thing.
I know common sense isn’t very common, but there’s a lot you can without really having to exert a lot of effort on your part while you’re developing the feature. Most of those things, in terms of the UX stuff especially, and the workflow, comes from communication with the product owner, and planning. That’s probably one of the biggest ones that prevent developers from delivering something that is actually what the product owner wanted.
Derek: What I see a lot, especially with people who don’t have as much experience or don’t have confidence, is they’ll have a planning meeting with the product owner, they’ll get some reasonably good wireframe, UX, UI, the designer would get involved to do that.
They’ll go to start implementing the feature, and they’ll know the workflow is broken when they’re doing it. Instead of raising the red flag back up to the product owner, or to somebody else on the team who’s responsible for UX or UI, and saying, “This feels really clumsy. You’re asking me to select 100 items here, but if you try to select more than 5, it takes forever. Isn’t there a better way we can do it”?
A lot of times, developers shirk that responsibility, and say, “I’m not the designer, I’m not a UX guy. I’m just going to implement what was given to me, and what was discussed.” The first thing that happens is the product owner or the designer might even sign off and say, “Yeah, it looks great.” Then they give it to the first user who actually has to select 100 things out of that 1000, and goes, “This is the worst piece of software, I can’t use this.”
The developer instinct is, “I knew that.” If you knew that, you need to speak up. That’s a big part of it as well.
Clayton: More often than not, you probably run into a situation where you don’t wireframes necessarily or lots of well thought out interface elements, and things like that.
When you get into that mentality, especially when people feel like they’re crunched for time, they try and use the simplest possible solution. Going back to the Web application example, if you don’t really have a whole lot of design elements in place, or a style guide for instance, and you’re just winging it, it’s really easy to crap out a bunch of stuff on this page. And it totally doesn’t make any sense. Submit button is this thin little thing that’s way off on the right‑hand side.
When developers use a site like that, you tell them, “Go use this antiquated government website,” all they have to say are all these terrible things. “Oh, I’m so much better, and I would never do this.”
But when they’re crunch for time or even when they’re not crunch for time, when they’re just trying to get the feature done, they say, “Hey sweet, I got the feature done. It totally works. I can click through it,” even though for the product owner or maybe a not so technical person or especially a user, it’s like, “What’s this huge thing I’m staring at? I have no idea how to do anything. I don’t know how to start.”
Derek: Yeah. Another part that comes along that is, sometimes we get such tunnel visioned on doing iterative development that we only think about the current iteration, the current feature set that we’re on. We forget those entry and exit points and some of those workflows along it.
Maybe I’ve got some form of object that’s got some attributes on it. It goes through some form of a process to do calculations or to do something, and somebody asked for this brand new piece of functionality. He says, “Hey, I need to be able to calculate this new thing. I need a new attribute, and based on that attribute, I need to calculate new values. After 30 days, you need to go check this other attribute and re‑tally something.”
So we go, and we add the attribute to the table. We update the calculation. We write this really fantastic test. We ran all of our regression test, and we say, “This is awesome. The feature’s implemented. We’re golden.”
Then the product owner goes and says, “Look, I’ll go and check that.” And the first thing they do is, “Um, there’s no way to add the new value to the attribute.” We’ve totally forgotten that, “Oh yeah, we inserted that in the database, and we inserted that in our test without ever having a screen going and updating the screen for that object to allow for that attribute.”
Sometimes it’s as simple as asking another person on the team that’s not part of that process and say, “Hey, can you just take a look at this and run through it really quick.” And you find that kind of stuff right away because the first thing they say is, “Where do I put that new value”?
Clayton: Right. Two big questions that would be huge wins for most teams would be, when you’re discussing a feature with the product owner, being able to say this question of, “How do I get here, and how does the user get here? Then after they do this thing, what happens next”?
You can imagine a system where you built some system that takes a report that someone generates. They type up some values in some text file or whatever, and they are supposed to be able to put this report into the system. Then there’s some black box that happens, and then it spits out some report.
People forget to ask, “Well, how do they get the report in the system in the first place”? because that’s the sort of thing that I think developers…They would develop the system, and they would say, “Oh well, I’m going to use my shell script that I wrote to import this file and parse it and blah, blah, blah.”
Then they’ll tell this little old lady user who works part‑time, “Yeah, just use your shell script.” “What”? Then when things come out, it’s like, “Oh, your report was generated. Where do I get it”? “Oh yeah, just SFTP into this thing, and find it directly with your username.”
It’s like, “Whoa, shouldn’t that get like emailed or put in a public place or something”? Those kinds of things. The, “How do I get here? What’s the entry point”? And then, “What happens next after I clicked the feature”? Those are two very important questions.
Derek: A lot of these things obviously can be addressed during planning meetings, meaning that if you’re asking a lot of these questions during your planning meeting, you’re getting good quality wireframes. You’re having those visual discussions and those entry and exit points, those workflows.
It avoids a lot of problems which comes to the last thing and that’s…At least here in Integrum, we do something where we have acceptance criteria, and when we walk through the product owner during planning meeting, we basically say, “What are the terms that consider this complete”?
I think that access a checklist at least on a functionality perspective for both the product owner and the developer to say, “I really shouldn’t be telling the product owner that this feature is complete. I know what’s done, these things that we agreed upon at the planning meeting.” It also allows the product owner to say, “Let me go through this checklist to make sure that the developers said what we agreed upon.”
Though, I don’t think that’s enough. That’s a really good start, but I still think ‑‑ what we talked about ‑‑ is the design acceptable? Is the UI acceptable? Do we have the proper entry and exit points? Do we have a sensible workflow? Have we tested it on production? Did we have somebody else on the team test it on production? Is it shippable? Is it deployable? There’s a lot to it.
I guess what I’m saying is, developers do not be so lazy when it comes to the point. A lot of times we try to push all the responsibility back to a product owner or to a QA team. In 20 years at software this has been problem in every single company I’ve been with.
Even with the QA team…The QA team says, “Listen assholes, you guys don’t ever test anything before you give it to us. What’s wrong with you”? I’ve heard product owners say, “Why do you keep asking me to check this out when it doesn’t even remotely close to work”? How do we get to the point where when we got this checklist or this formula of “these are all the things we need to do” that we actually do it?
Clayton: That’s a hard thing to overcome in the sense of…Until you see the value that you get from that, it’s difficult to get yourself in that because it is extra work. Most people or a lot of developers have this idea of “That’s not my job. My job is to write code and implement the feature, and your job is to test it or whatever and make sure that it works, QA team people.”
But if you look at it from some other aspect of your life…For instance, my wife and I, if I say, “We have all these dishes in the sink, and we need to put them in the dishwasher or whatever.” And I ask my wife, “Is that something you’ll be able to do while I go do this other thing”? And we’re exchanging things.
She’s going to be pretty upset if every single dish I’ve ever put in the sink that week or that day or whatever has tons of fruitcake onto it. So there are certain things you’d have to do so that the next person in line…And I know that the benefit I get from taking that extra step is totally worth it.
I know that if I follow the checklist, and I make it really easy for the product owner to sign things off, and I make it really easy for them to say, “I was able to go and demonstrate that this feature worked. It looks perfect. It’s just what we talked about,” that’s a huge win for me because now that that feature is actually done, I can move on to the next thing or I can complete some other story.
It’s not this idea of, “I’m going to do a whole bunch of work, and then tell you halfway through the iteration, “Go take a look at 80 percent of the work that I’ve completed.” Then you find out, “Oh well, this is broken. This is broken, this is broken,” all that stuff and I have to go back and fix it.”
If I have this confidence that when I say something is done, it actually is done, I don’t have to think about it anymore, I can just keep going. So getting people to understand that value, that’s a way that we can get people to start adapting the practice of following that checklist and really thinking about these things.
Derek: That’s just a good area that almost every team can improve upon. Again, whether you have a QA team, whether you are the QA team, whether you rely on a product donor or a third party to do verification for you, this is something every team can inspect and do some adaptation to and really improve their quality level, it’s independent a code. It’s really a discipline based improvement and so we just encourage you to check it out. We hope to see you next time.
- Is agile just for teams?
- Pairing good traits
- Pitfalls found while pairing
- Good pairing habits
- Pairing in a chaotic environment
- Various pairing techniques
- Physical pairing station setup
- Remote pairing
- Dealing with distractions
Derek Neighbors: Welcome to another episode of the “ScrumCast”. I’m Derek Neighbors.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
Derek: Today, we’re going to talk about a couple things. First, we’re going to field a question, and the question is, “Is Agile just for teams, or can it be used for solo workers also”?
Clayton: My experience with this is, I’ve done a lot of stuff, just personal projects, goofing around basically on the weekends, and I try and use some scrum process. The thing I’ve noticed is that, I feel like at work I’m a very disciplined person. I have lots of discipline in that regard, and blah, blah, blah.
When I try and do it by myself, I feel like either I have no discipline or I don’t have enough. In my experience, I’d say that if you’re not a very disciplined person, it’s difficult to make it work. There are some benefits from it as far as…everyone has an experience with a personal project that just languishes and goes on forever, and you never finish it. There’s probably a lot to be said that Scrum could help you out with, in that regard. I don’t feel like I have the discipline to do it, myself.
Derek: A lot of agile techniques work fairly decent. In a solo environment, a lot of the principles do unexpectedly iterate. Using iterative approach, time‑boxing, continuous improvement, all of that stuff translates perfectly. When it gets a little bit more to estimating and doing some of the heavier parts of the methodology, it’s much more difficult to be disciplined about that, in a solo environment. It’s feasible when it works, but you have to have a lot of discipline to do it.
Today, I wanted to talk a little bit about pairing. Clayton, as a team lead you do a lot of pairing on interviews, here at Integrum, and you get to see a lot of pairing. I wanted to talk a little bit about what you think are some traits that make somebody a good pair.
Clayton: In pairing the most important one is being engaged. That’s a broad term that means the concept of being a good listener, paying attention, being interested in not only what’s going on, but also…when’s someone’s driving, or they’re solving a technical problem, it’s easy for them to get in that mindset. You have to be able to switch back and forth, and switch modes. If you’re the person, you’re not driving, you’re the passenger, you need to be able to keep focus on maybe some certain processings, or the non‑technical things.
Obviously if you are driving, being able to get into that mode and not worry about those things. Let someone else take care of that for you. I think that’s a big one for me. Outside of that, I would say that being a good pair is one of those things where I don’t think there’s a real good book answer for it.
If you were to try and do something by the book or write a list of things that you can do to be a good pair, that would be really hard to come up with that list. It’s more of a matter of good communication, good soft skills, those kinds of things. I think that’s most of it.
Derek: What are some of the pitfalls? You get to pair with a lot of people who are new to pairing. What are some of the things…when you see two people that maybe have never paired before and don’t necessarily have good habits, what are some of the common things that you see where people fall down in pairing?
Clayton: The driver‑passenger role is one that people don’t do a very good job of. Especially people that are new that say, “I’m a coder; I’m a programmer.” They have this idea of what that means to them. Then when they’re not driving, there are some people that fall in the subset of, “I’m going to micromanage every decision that you make while you’re driving, because that’s not how I would do it.”
There are some people that say, “Oh sweet, you’re doing all the work. I’m going to kick back and check my emails,” or whatever. Even in the pairing interviews, we notice that people, obviously they’re there for an interview, they’re trying very hard to be polite and engaged, and all those things. You can definitely tell when they get the keyboard, you mention something, “Oh hey. What about this?” and they can’t even hear you.
I think people don’t have that, not listening when they’re driving. Other than that, pitfall wise, people fall into categories of being a bad driver; just going down some rabbit hole ignoring what the other person is saying. The passenger plays an important role in guiding you, especially if they say, “Hey. This doesn’t look like a good path to go down.” Bad drivers just ignore that.
The one that we see the most is probably bad passengers. I think body language is a huge thing. If you ever want to evaluate people that are pairing, just look at the driver and the passenger. Usually the driver is leaning forward, because they are using the keyboard.
Most of the time, you will find the bad pair who are the bad passengers, are the ones that are leaning back. They don’t have their shoulders facing the workstation, that kind of thing. The people that are leaning forward, have the same body posture as the driver, those are the ones that are probably more engaged.
Derek: In dealing with a lot of people that are new to pairing and getting them up to speed, what are some things that you found have been successful in getting people up to speed with the concept of pairing in a fairly short amount of time?
Clayton: Brief overview of the role of the driver and passenger. A lot of people view pairing as, “Half the time, I’m working. Half the time, I’m watching someone else work.” They don’t understand what really they’re supposed to do when they’re not actually coding. Getting people to understand that is very important.
After that, I would say that there are bunch of games that we’ve had some good experience with. Ping Pong Pairing where one person writes the test, say a failing test, and then, the other person has to write the implementation for that to make the test pass. That’s a great way for both people to be engaged and both feel like they’re doing something.
Another one would be switching off at predetermined intervals. Say you set a timer for 15 minutes and it’s not this thing where the timer runs out and the person that’s driving says, “OK, cool, give me another two minutes, I’ll finish this up.” It’s literally, 15 minutes is over and slide the keyboard and mouse over and the other person has to just pick right up.
You can’t…it’s very obvious that you’re not being effective when the first 15 minute bell goes off and the other person is like, “Oh. What was on the menu?” They don’t have any idea. I think that’s a really good one to keep people engaged. I’m trying to think of some of the other games we played.
One that’s good, actually, for a lot of people have a criticism of pairing, is that they feel like, “Well, I’m really good at what I do. I’m a really good developer. I don’t want to pair with people that aren’t very good because it slows me down.” One thing that you can do to improve those people on your team that may be more junior or don’t have your level of expertise, which you probably don’t have any, but you think you do.
But, those people, to train them or to help them out, would be to do the distant passenger. A lot of times, I see that when people are in that situation, pairing the person that’s the more senior person will be micromanaging and driving and basically, telling them, dictating what to type.
“You should write this method. You should return it this way. You should use the turner in, blah, blah, blah. If you talk at a higher level and say, “Well, we want this model to be able to…we want this instance of this object to build or respond to this method. I want it to return a hash of these things.”
When you speak at a high level like that and then, you let the person go do the implementation. Whether or not you’re doing TDD even, but let the person do the implementation and then, maybe set aside some time at the end to do some kind of code review of like, “OK, see how you did that. You solved the problem. Here’s how I would have done it.” Have that discussion. I think that’s really helpful when you have a mix of skill levels.
Derek: One of the things we see, obviously, operating on the Gangplank because it’s pretty noisy in here. We’ve got a lot of people pairing in close proximity. One of the things that a lot of people ask me is, “How can your guys be developing in such louder, chaotic environment”
Maybe if you could explain a little bit about what it’s like to Pair Program in an environment where you’ve got lots of people Pair Programming in fairly close proximity and whether that positively or negatively affects productivity.
Clayton: I’ll give an example, recently one of the guys on the team got everyone little Nerf guns that shoot darts. For the past two weeks, it’s been like every day, it’s people shooting darts.
You could be sitting there, trying to solve some complex problem and darts whizzing over your head. That’s the nature of the environment. I found that a litmus test for me is if I feel like I’m distracted or I hear people talking about, “I can’t get anything done today,” I feel like that’s not good pairing.
Or there’s a problem with their pairing because I notice that when I feel like I’m doing a good job and have an engaged pair and we’re really hammering things out, it’s almost like all that stuff just doesn’t matter anymore. It’s really easy to block it out, probably more than people would think.
You’ll notice that when people aren’t pairing, a lot of times people will put on headphones and try and get into the more traditional coder mentality of, “I’m going to go into my own little world, so I can’t hear or see anything. Don’t bother me kind of thing.”
When you’re pairing, you, obviously, can’t do that. When you’re pairing, you don’t really need to do that as much, in my opinion.
Derek: What you’re saying is you like to look deeply into the eyes of your pair and have some tantric pairing going on and nothing else in the world exists except for your pair?
Clayton: No, it helps if you have a little mirror, so you can glance at each other’s eyes every now and again. You put that above the monitor and you’re good to go.
Derek: I think that’s something interesting. One of the things that I’ve seen people talk about are some different pairing techniques in the way of physically setting up how you are pairing, whether that be some face‑to‑face pairing, some potentially pairing without even a laptop or a machine in front of you to solve the problem.
Then, to go to actually pair to implement the problem. Have you tried any of those things and if so, what are some of your thoughts on those?
Clayton: I tried the face‑to‑face pairing at one point in time. That was quite a while ago, I would say, before I was…I was trying things out. I don’t know. I hadn’t made my mind up really on pairing yet.
I found that to be distracting. It seems like the face‑to‑face stuff would be good and maybe it just was the person I was pairing with, but I found like it was more convenient to be looking up and away from what we were doing and doing a lot more conversational talking. That was probably the down‑side to that.
Other than that, as far as different pairing configurations, one technique that I had to do working with someone, this is easy to do when you’re pairing. People have a certain different degrees of personal space and that kind of thing. I had noticed that every time we sat down at the desk, this person would always sit in the middle and so it’s like I found that towards the end of the day, I would be pushed over to the side.
We got to a point where we drew some lines on the desk with some tape and we said, “OK, here’s our zone where we need to be and if we drift out of this zone, then one of us is going to be uncomfortable because we can’t see the screen or whatever.” That brought us actually much closer physically together in that regard. Then, we also made a rule that the keyboard had to be in a certain spot on the desk.
That was a way of balancing that stuff out so we could say, “We’re slightly off center from the desk and from the keyboard and the mouse and everything, but we’re still comfortable.” That cut a lot of problems out because we didn’t realize how much time we were spending nudging each other left or right and repositioning yourself through the day.
Once we set that ground rule, it was easy to be able to get going, keep going.
Derek: That’s a good segue into the physical set‑up. Tell me a little bit about what your optimal pairing station is. Is it a one keyboard, one mouse, two keyboards, two mice? If you’ve tried some different variations, why you prefer one over the other?
Is it single screen, double screen, preference of one over other?
Clayton: As far as the screens and work station set‑up, personally, when I was maybe younger, there was this dream of like I want to have 10 screens in front of me and that seemed so cool. Then, as I’ve gained more experience, if I just had one…we use iMac. The 27‑inch iMac, that’s got a big screen on it. Sometimes people load up that screen. Traditional set‑up is that screen and a secondary monitor. People load that stuff up with just tons of things.
I feel like it’s distracting for one thing. When I’m sitting on the left side of the station, I like big fonts and everything, but I have a hard time reading specific code or terminal or whatever that’s on the complete opposite side of the desk.
In that regard, I would prefer to probably have one monitor. As far as the keyboard stuff, I personally like two keyboards.
The reason I like that is because two keyboards, two mice. I’ve noticed that when you’ve got someone who’s pretty strong willed and they want to go down their own path, and they’re pairing with someone that maybe isn’t, maybe someone that’s more willing to go along with them, it’s harder for that weaker willed person to grab the keyboard if they want to take control.
If they have their own keyboard, it’s really easy to just press a key. It’s amazing how much you can screw somebody up by pressing a key or two keys. It’s kind of, “I don’t think we’re doing the right thing.” “No, trust me this is right. Let me keep doing”
You press command‑TAB and switch to whatever the other application is and bring it in focus and then, it’s like…it’s a total…it’s an easy way to have this stopping point of, “OK, put the brakes on. Let’s talk about this.”
Without having to physically, grab the keyboard from somebody.
Derek: What you’re saying is dual keyboards prevent pair assaults?
Clayton: There you go, yeah.
Derek: One that a lot of people are probably asking at this point, remote pairing. Thoughts on having to pair remotely.
Clayton: Every programmer that I’ve ever known has this ideal that, “My job is totally over the Internet, so I can work super effectively at home.” We tried that when people were sick or people are away or whatever.
It’s really difficult unless you’ve got…even with like the screen sharing and remote control that like, say iChat gives you or remote desk software or whatever, that stuff is really difficult because you get a little bit of lag and you don’t realize how much that effects the way that things look.
If someone is scrolling a web page and you can’t see things anymore or whatever, that’s really distracting. Then, I would say the good thing about it is that when you’ve got two people who potentially can control the mouse or the keyboard, having like a code order where you actually have to physically stop everything and say, “Mouse,” or whatever, so you can get control because, obviously, two people are remotely doing that, isn’t going to work.
I would say that’s nice, but overall, the negatives outweigh the positives as far as remote pairing is concerned.
Derek: The last question really is distractions. How do you deal with distractions in two ways? One distraction would be somebody else on the team needs you for something. Instead of just interrupting one person, now they’re interrupting an entire pair. If it takes a certain amount of time to get back on task when you’re interrupted and now, you’re affecting two people.
What are some ways or techniques to be able to minimize that? Then, the second one is physical distractions, in the terms of, I’m going to say, near‑term problems, laptops, smart phones, things that, I think, as a passive pair are really tempting to get into.
What are some thoughts on mitigating those two things?
Clayton: I would say that as far as…that one first, as far as the passive stuff where you…sorry. When people are distracted or tempted to look at their phone or their laptop or whatever, that’s something that is up to the pair.
Definitely, you’ll have situations where, especially if you have someone that’s driving that doesn’t really want to be pairing, when the other person looks at their phone, it’s like, “Thank God, I don’t have to worry about this person anymore.”
If you’re the kind of person that is…personally, I think that’s disrespectful when you’re pairing, you don’t want the other person just goofing off because then, you get into the mindset of, “Wow, pairing is really useless because I’m just doing all the work and this person’s surfing the Internet.”
People try and make a lot of excuses about it where they say, “Well, I need my laptop so that I can do research,” or, “I need my phone so that I can check my email because I don’t want to miss anything,” or whatever.
That’s a real concern, but it segues into the idea of solving the first problem where I feel like having some kind of consistent timer, that totally solves that problem. If you say, “We’re going to to set a timer every 15 minutes, we’re gonna switch pairs.” If someone walks over to you and says, “Hey, I’ve a question.” You can reference the timer and say, “Well, I’ve got 10 minutes left.” Usually 15 minutes or less, there’s nothing that’s so important that it can’t wait that much time.
If you’re worried about missing an email from a client or something, it’s pretty easy to say, “OK, we’re going to work for every 15 minutes, and then every 15 minutes I’m gonna check.” At most you’re going to go 15 minutes without seeing it. Which for most people is probably acceptable. I’d say that having the timer is really good and that helps solve both problems.
Derek: We’ll see you next time.
- 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 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.
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’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?
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.