Episode #14 Transcript – How to Make Scrum Really Work

August 14th, 2008

Click here to listen to Episode #14

Hi, this is Derek Hatchard. You’re listening to Episode #14 of Devcasting. Recorded on Monday July 7^th, 2008. In this episode, I talk with Joel Semeniuk from Winnipeg, Canada about how to make Scrum really work. Enjoy the show.

Derek: Hello Joel, welcome to Devcasting.

Joel: Hi Derek, how are you?

Derek: I’m very well. So with me today is Joel Semeniuk who is with the Imaginet Resources in Winnipeg, Manitoba, Canada, the coldest place on earth that I’ve ever been to. The most mosquito ridden place in the summer time. Joel, can you tell us a little bit of what you do?

Joel: I’m actually the Chief Envisioning officer for Imaginet in Winnipeg. And my day to day responsibilities is just essentially team facilitation, making sure that from a government’s perspective, our teams are following the best practices in adjusting the practices as they go along as the needs of the project kind of dictates. That’s one part of my role. The other part of my role is just kinda making sure that Imaginet is kinda doing the right thing with the right side of customer worldwide.

Derek: And just for the sake of full disclosure, I actually used to work for Joel. It was fun at that time. It was last real job I had for I decided to pursue entrepreneurial endeavors.

Joel: Yes and we are very very sad to see you go.

Derek: Oh, you say that now. Joel, we’re gonna talk a bit about Scrum. Which is something that I’ve heard in conferences where you’ve spoken about that. Just a startup for listeners out there who aren’t really familiar with Scrum, or maybe they have heard about that but don’t denotes promise specifically. Could you tell me briefly what is Scrum.

Joel: Sure, Scrum is an instance of a process framework that kind of falls some of the core Agile principles. It really kind of focuses on the establishment of high bandwidth teams, but what I mean by high bandwidth is that, teams are collaborating with one another almost constantly. As well as putting in very discreet cycles within a process environment. And it really what it focuses on is time boxing everything so very high bandwidth between your team members and really focusing on time boxing amongst of work in two things called sprints. So, when we’ll look at an overall application, what Scrum suggests that you break down the overall project into a series of about one month blocks of time called sprints. And inside of those sprints, you tackle a chunk of functionality that your team and your customers agree at two at the same time.

So, at the end of every sprint, you don’t just have a design or you don’t just have a partial implementation of a set of features. You actually have a working application that you can then build upon for your next subsequent sprints.

One of the key aspects to this particular Agile process framework is that it really focuses on the ability to change but also getting work done. So, within the sprint, your team is very very focused on getting the features that we’ve identify this being part of the release of that sprint. But what that also allows us to do that at the end of every sprint, we can reassess what value we’ll providing to customer. One of the things that we know in the software engineering environment is that things change, requirements change all the time, the perception of value changes for the applications that we write and what Scrum allows us to do is adapt to those changes that need be.

One of the core aspects of Scrum though is really kind of getting into these little rituals. I use the word rituals because it has the right meaning for the type of messaging that we wanna get across. Above of it all, the teams, the development teams really love to work with Scrum. And the reason for that is because it just provides that nice pattern for them to work with them. The other aspect is that it really kinda focuses on high bandwidth and it starts with something called the daily Scrum. The daily Scrum is about a 15 minutes standup meeting of all –(4:50)– with your team members and it also includes your customers at the same time. We’re all kind of declare what we did since the last Scrum, so yesterday. And what we plan to do on the upcoming before the upcoming Scrum as well, which is tomorrow. As well as kind of declare to the team any type of impediments that we have. This really kind of creates a very synchronization point between your team members and your customer.

Now, when we think about this, we also have the synchronization point at the end of the sprint as well where we get together with the customer. We show them what we’ve done, we allow ourselves to take feedback from our customers and work it into the upcoming sprints. But we also have time at the end of the sprint to really think about how we can do a better job. That’s part of something called sprint retrospective. With the team and the customer get together and we look at how we actually work together as part of the team to develop that software. We think about ways that we could do a bit better of our job or maybe optimize some of our processes and really kind of reflect and also some of the things that we did really well. So, we can kind of get into that, continue in improving mindset where the next sprint will have higher velocity or better quality or better communication or changes to reporting mechanisms and so forth.

So, those heartbeats that exist inside of the Scrum methodology really kind of help to reflect the way that the team works, again, that high bandwidth team as well as the ability to change.

Derek: There are a couple of terms that you just mentioned, could you define them for us? One is velocity and then tied to that, you’re trying with the sprint. How long is the sprint in your context?

Joel: Sure. Well, let’s start with the concept of the velocity. Velocity is essentially, you know, many people use that in many different ways. But how I like to think of it as how much in terms of quantity, user valued functionality we can provide in a particular period of time. So that might be measured in features that could be measured in something called user stories and it can also be measured in some other measurement that the team feels comfortable in using.

We at Imaginet, use something called features which is derived from another methodology called feature driven development and we measure how many features we can get done in a particular sprint.

Now, in a sprint, we actually have a fixed amount of time. It could be usually anywhere between 20 working days to 30 working days and really we’ve seen 20 working days for us being achieved really good length on sprint. We have seen other organizations that have up to 40 working days as well, but for me when it comes to producing software, the more feedback mechanisms that we have in place, not only with the team but with the customer, the better it is.

We also experimented with one-week sprints as well and we’ve found out that it’s a little bit too short for us to get working product to the customer in a valued period of time.

Derek: All right. So, you’re talking one to two months of delivering a working system of some form. So, everything that customer wants that they have something delivered every month or two. That’s your goal.

Joel: Yeah, I mean the customer needs to see something from us. Now, typically what we’ll also do is group and this is a common practice as well. Group sprints together and that’s something called a release. Here’s an example. We have on our teams the concept of an alpha release, of beta release, of release candidate. We see the same from corporations like Microsoft as well. And we typically group 3 to 4 sprints within a major release. And that again just provides us a more another feedbacks cycle so that we don’t go for 12 or 18 months without actually having something real that we can deploy to our customers. Essentially, when we release at the end of an offer or at the end of a beta, we’re not just showing the customer what we’ve done. We’d actually like to install it in their environment, go through a pre-production cycles, QA cycles and actually get the customers starting to use the application instead of just showing and going through standard walkthroughs with our customers.

Derek: See, you do a talk of how to make Scrum really work which applies that there are instances of Scrum process framework, is that the terminology?

Joel: Yes.

Derek: So there are instances of the process that are not working. So what are the pitfalls that teams run into and what do you mean or what are you talking about when you tell us how to make it really work?

Joel: Sure. Some of the times that I’ve seen Scrum fails is when people just get into sprints. They just start developing software and they go, ‘hey, you know we have our team meetings every morning and we broke everything down into sprints, let’s just go, let’s just write code’. Great if you have all your docs in a row but the reality is, most customers, and I say the word customers as being any consumer of your software, anybody helping to pay the bill if you do develop software. Late to know how long things are gonna take and generally, what are gonna get for their money and by when.

Scrum, the methodology framework represents a better of planning for this upfront, it’s called the preparation. And we like to actually put a bit more effort into the preparation phase to kind of layout what are the next couple of sprints will look like, do you have an understanding of some of the basic requirements and features that we’re gonna be implementing on the first sprint bases. And at least have a better of baseline before we actually just start implementing code. Customers feel very, you know, instead of going off and writing code and coming back month later, customers feel comfortable in seeing what the game plan looks like and sees how, you know, what they gonna get for the money that they’re paying you to build.

This is also important from a larger team perspective. It’s really quite important to give the perspective of the project as a whole to the entire team. And typically, you ended up doing a certain amount of, we’ll call it requirements gathering and decomposition upfront. So what we promote as part of the Scrum methodology is something called feature driven development feature decomposition which allows you to kind of represent what you’re doing in a fairly discreet way. Another people do it little differently. Some people like to get their collections of user stories done upfront so they’ll go away do their joint application development sessions with their customers to truly represent how the users are gonna be using the software. Then they actually prioritize those user stories or features and then based on either prioritization or technical dependencies, start thinking about how you’re gonna be ordering and sequencing that work and then bucketing those features and work into sprints.

So, I found that organizations who don’t do that preparation phase, who aren’t actually fairly discreet in how they gather some of the initially user stories upfront and do some that initial planning, don’t have a lot of great success implementing Scrum. What I mean by successes, the customer isn’t happy. The developers might be happy as heck but we’re not building software for developers. We’re building it for the customers.

Derek: One of the things that I’ve seen is the temptation of the developing team looking at all of the other stakeholders that’s saying, ‘would you just leave me alone and let me write code’. Upfront planning, I don’t know what it is. It’s like there’s personality thing that makes the developer just instinctively doesn’t want to be a planner and have to learn that –13:00-.

Joel: Right and to some degree, I mean if you got smaller teams as it works so, almost everybody in the team must gonna have to become a planner. When you get into larger teams, for example, we’re working on a project right now with about 12 or 13 developers on board. We are not leaving a lot of the planning work to some of our lead developers who have good perspective of how everything works. That doesn’t mean that the opinions and the thoughts of maybe some of the developers who just want to code aren’t taken into consideration but we are able to kind of segment the work. We end up having something called the Scrum of Scrums. And that’s one of the ways that you can actually scale out Scrum to larger different teams that might work in different areas. So for example, we use some Egyptians to do pieces of our projects and they will Scrum every day with one of our test leads. So, they’re not part of the overall Scrum. Whereas our local developers will Scrum locally and then we have a Scrum of Scrums where the leads get together and kind of synchronize up themselves.

This is why it’s really important to keep Scrum as very very time focused, if not standup as much as humanly possible. And the lead not getting into rat holes, not getting into overall design discussions and so forth. We’re really kind of focusing on what we’re planning to do and the impediments. Then it’s really up to the job of the project manager to make sure that the person in front with their hands sticking out trying to block all the impediments from heading their development team. I mean that’s a sign of a great Scrum master being able to make sure that our development team is as highly productive as humanly possible. That’s why looking at the impediments on the daily basis, not just the monthly or weekly basis is really quite important.

Derek: Yeah, I’ve always thought of that, it was one of the golden points of Scrum was that person who’s dedicated to just making sure that the developers can develop software, get up all the other things the other way.

Joel: Exactly. Now, that things said. What we’ve also found out and unfortunately we found this at a hard way, is that it’s really important to have overall team buy-in and perspective of what we’re doing. So just going off from breaking down like of the project manager goes and says, ‘ok, here’s what’s in the sprint guys, just go to it’. You know what, when you have high IQ people, they don’t want just take directions without reason or some guidance well. They need to understand why, why did you select this as part of the Scrum or sprint, why are we doing this, why does this take higher priority than other.

One of the things that we have really focused on and really tried to improve upon is to get everyone’s involvement when it comes to sprint planning. Not only just the technical people but our users as a whole. Now, we’ve also found out that sprint planning, it’s really hard to do it with just one sprint. You have to kind of step back and make sure you have perspective over the entire release and over the entire project to make sure that things still make sense. Without that perspective and the constant reinforcement of that perspective, you might get a team that is overly focused in one particular area. And in doing so, could miss the overall objectives of the projects. And we’ve seen that happen time and time again where with the developers are thinking that one feature is of high priority and the customer thinks it’s a fairly low priority and we got a mismatch if you will when it comes to effort and thought and so forth. You got a lot of spins, so the developers would go off and do a lots of design, you know they’re gonna create a rules engine about this, they kinda fancy this and fancy that. Whereas the developer goes, ‘no, all I want is a pull-down/drop down box. Or you know if you cut that feature, I’d be happy as well’.

So, in making sure that we always have that oversight into how it works. Developers’ things are important as well as the overall customers’ things as important overall across the entire lifecycle of the project, not just on the per sprint basis.

Derek: Alright. So, I think we got a two problem areas that you pick. One is a lack of upfront planning send a big picture and another one is a failure of team members or even the team as a whole, kind of missing the point of which features are higher priority than others. Others gonna fix ways in which team’s fail when they try to implement Scrum.

Joel: You know, missing that retrospect is also something that I’ve seen as well. So you know, they’ve really kind of broken down the project appropriately. They might be doing requirements correctly but the retrospect is a very important aspect of the project where the teams get together and they look at how they work as a group. Some of the micro processes, I guess you can say that are checking processes work on an automated built, processes work, can we fix those, can we automate those further. But also some of the macro processes in terms of you know, well we’re having too many status meetings, you know, we are forcing us to do way too much work to track our daily tasks or something like that. Really, making an effort to make changes to your process for the next sprints so that ultimately, you can be more successful.

Now, one of the key aspects that we found is that disability is really important. Meaning, that at the end of the retrospect, we should actually have a fairly discreet list of what needs to change and who’s responsible for making those changes. Those should be worked in to the sprint plans. As we are developing features for a customer and that’s very important. We might have to do a little bit of extra work in order to make our processes more effective. Maybe we have to change the way that we’re automating on deployment of software, for example. That may impact overall velocity from a customer perspective. But you do need to work those into the sprint plan after they discreetly. Other wise, what happens is that the team must be working extra hours to be more proficient and that’s really not gonna be good for team morale. But making sure that you have a very discreet list of what you’re going to improve on a per sprint basis. And just making sure that the team has visibilities as, ‘okay, look, you guys asked for these processes to change and have made suggestions on how we can be more efficient. Look, we’ve made these changes and we are more efficient and then continue on that cycle.’

So what happens is that you end up having like a project within a project. So the continuing improvement of your project becomes its own project done to itself. But in order for that to be successful, you must recognize that will have impact on the day to day activities of the team as a whole.

Derek: Alright. So what are other tips you have for really making Scrum work?

Joel: Keep it simple. You know, you can get into so many, so easy especially with really smart people to really over complicate things. And focus on two key principles. If you focus on these two key principles, you know, rate them up on your white board and make sure that every decision supports these two key principles. One is feedback mechanisms. Every process in the world needs to have a feedback mechanism. And as it happens, the smaller the time scale for that feedback, the more effective that process will be.

So, when you think about how you’re tracking things, how you need to report on things ‘cause ultimately customers do like to have reports and how the team works. Think about those feedback mechanisms. So, sprint has a number of built-in feedback mechanisms which is your daily Scrum, your sprints, your retrospectives and your sprint planning that happens every month as well. But one of the things that we’ve seen teams done is implement yet another one and they built in weekly feedback cycles as well. So, they’re able to kind of takes stop of where they are within a sprint on a per week basis.

So always having a feedback mechanism, every manufacturing process needs to have feedback or like a biofeedback mechanism. And the more that you can put in without impeding the velocity and the quality of your team, the better it would be. And there’s gonna be a limit, right? There’s a fine balance and you might find on the project that you’ll be trying to find to measure too much without getting the value well. Then you back off and you go, ‘oh no, we’re not measuring enough.’ But you know sprint after sprint, keep adjusting with that line is, to make sure that that feedback mechanism kind of balances itself back up. And by the way, that will change on every project. Your way might work well as a set of feedback mechanisms on one project on one team, may not work with a different team size, for example, or for different type of project. For example, highly contract driven projects are really tough. And sometimes, Scrum doesn’t work at all if customers are via contract forcing you to meet pre-defined obligations and change will be penalized. Well, you know, Scrum might not work for you. You might wanna go to more of a traditional waterfall method and manage change from there and that’s where Scrum can actually be fairly dangerous. So, we have to assess it from that perspective.

The other key principle. So the first key principle being feedback, the second key principle is bandwidth. Making sure that you have extremely high bandwidth between your team members internally as well as with your customers. We’ve seen this a lot when we looked at extreme programming, for example, in getting onsite user pair programming. Those are all about the bandwidth. Making sure that we’re not having to communicate by documents. So, you know if I have to write down a set of documents to be consumed by another person. That might have to exist because of the size or the scalability of the team or maybe even geography. But if you can get a way with doing having bandwidth impersonates, it’s even better. Having in person meetings is preferable to having, for example email type of conversations. For example, with our Egyptian team, we Scrum with them every morning over Skype. In morning to us and being late afternoon to them. But making sure that they never go dark on us. And that’s one of the dangers of having remote team as that team kind of what we call going dark, which means that the communication doesn’t happen as quickly as we’d like to see in terms of feedback mechanisms or communicating requirements, for example.

Derek: I’ve worked with an Egyptian developer and it actually worked out really well and it’s been morning from me and it’s middle of the afternoon, somewhere story. But I’ve found that it has worked really well. I wasn’t quite sure at first how easy it would be but my goodness, it’s just been a pleasure working with them. The guy that I’m working with is really bright. And even if your much earlier, the notion we have intelligent people on our project, it’s hard to just get them much of work to do and just ask them to blindly do it or constant looking at things and ask, ‘why is something being done that way? Are you sure that’s the best way to do it?’ I found with the guy I’m working with, it’s just been a beautiful back and forth. He keeps giving me great feedback on the features said and on having to implement it. It seems like you’re saving that sort of Agile methodologies in general.

One of the key principles is its extremely high bandwidth between all the people involved. I think that’s a beautiful way to say it. Which makes you think of one of the other things we hear in Scrum, which is the chicken and pig stakeholders, how would you put it? Can you explain that to people who are gonna hear that term and their scratch has go with it, what the heck are they talking about?

Joel: Well, the ‘chicken and the pig’ goes back to an old story. Well, the chicken and the pig were walking down the street. The pig goes, ‘hey, I’ve got a great idea, let’s open a Bake and Eggs Breakfast Store’. And when you think about that, bake and eggs, the pig’s got basically the skin in the game whereas the chicken is only laying the eggs and doesn’t really have the same skin as the pig. So, when we think about who’s got the ownership or who’s got a skin in the game when it comes to our team, we kinda have to think about that. So, the development team obviously has a skin in the game, they’re being responsible for producing the requirements of customer obviously has the skin in the game and what we like to separate are those who just have an opinion, for example. It might have been on the sideline and that might be your sales team or high-level management team or so forth. They’re not really responsible for producing anything but just having oversight and opinion. What a lot of organizations do is they actually separate their Scrums into chickens and pigs. Where the pigs will actually get to contribute to the Scrum in the morning and the chickens just get to listen. They get to stand by and listen to what’s going on and offer up their opinion later on.

What we’re finding in a lot of our projects is that, almost everybody, we’re trying to turn everybody into pigs. We’re trying get everybody’s skin in the game. From every developer right to the customer and when everybody’s skin is in the game, there’s much more focus on quality and deliverables and review cycles and so forth. Whereas, if you label people as chickens going on, you got nothing to lose if these fails, just a few eggs and you can lay some more if you need to. No big deal but when you really work to get everybody as pigs in your project, you actually get higher quality throughout. And much more concerned about the overall product as you’re moving forward.

Derek: So you actually make a point to try to get move our people more involved to the project if possible. You try to keep individuals from being on the sideline simply offering opinions. Is my understanding correct?

Joel: Yeah, that’s exactly, yeah. I mean so many times I’ve seen developers going on, ‘just tell me what to do and I’ll do it’. To me, that’s not good enough. Most of developers, almost 95% of the developers I’ve ever worked with are highly skilled, highly intellectual people and they have an opinion and thoughts about how we should proceed. Taking a passive aloof mindset on a project is not going to add quality. Once you give them ownership to something is kinda like, ‘no no, you know you own this section’. They start thinking about requirements, they question requirements more, they think about timelines, they think about design. So, it’s not always in a perfect world for them. They should always be aware that we all live under constraints, constraints being time and money and skills and all those good things. And when we allow everybody to have a form of commitment that takes them to account somebody’s constraints, they all become pigs. They’re all kind of watching out for everybody’s bottom line.

I’m not saying that I wanna turn everybody into project managers who are concerned with budgets but making sure that everybody really understands the scope of the project, what the goals of the customers are, what the goals of the dev teams are, and how to make sacrifices between a puristic model software engineering to a much more practical one. And really, when we’re developing line of business applications, we do have to make tradeoffs. I mean we do have to think about what’s best for the overall project as a whole as well as to the customer. That might not mean doing things harder to press and using every brand new technology or technique out there. That actually might mean doing it as simple as humanly possible or as quickly as humanly possible. Sacrificing what we could be constrained as best software engineering practices, for example.

Derek: Now, if there’s a possibility that there’s a new technology, there’s something that sitting there that we think might be able to solve the problem for us and might be something better, faster and stronger for using that. How does that fit on Scrum if we have a month for a sprint and we’re gonna build this particular feature that’s sprint? It seems pretty risky to me, it’s also that you don’t have any room for experimentation.

Joel: Yeah well, that’s where we integrate something called the spike. We’ve taken that concept from extreme programming where you actually have a small problem that needs to be solved or something that leads up to a decision. So for us, what we’ll do is we’ll take the principle of Scrum which is the time box everything. And when we’ll time box a spike, so it could be 4 hours, it could be a day, even it could be 2 days. Or you can say, ‘okay, this is the problem that we’ll have to solve.’ For example. ‘do we build our own rules engine or do we go for an off the shelf rules engine? Okay well, let’s think about that. What’s gonna help us make that decision.’ The other one might be, ‘do we use enterprise library or do we use CSLA or which did access model we’re gonna use? Are we gonna use in hibernate or we’re gonna write all the code ourselves?’ We kind of think of those as decisions that need to happen on a project but we make those into spikes. So someone will go off and do some a little bit of research on a particular problem, come back with the certain of set of recommendations. What’s great about having a timebox spike is that you can easily schedule it into your sprints and you do need to schedule it in like all other development tasks like fixing builds and creating continuous deployment scripts and so forth. They should help us resolve the problems.

For example a project that we’re working on right now. We had a number of spikes that helped us determine whether or not we should go and use WPF or to use a traditional Win forms basic client. So we spike on WPF as a whole, we spike on some of the frameworks and tools that integrate with WPF, we spike on some of the compass that the application blogs that we might use for WPF, first is Win forms. And those are broken down into nice big chunks where you can come back and said, ‘you know what we’re not comfortable with this toolset yet or this framework isn’t available yet or the community isn’t really supporting this and there’s only two devs on our team and they experienced on this. And kind of come back as a whole and make a decision. So the concept of a spike is very important for that.

Derek: Well, what did you decide, WPF or Win forms?

Joel: On this particular project, we’re going with Win forms but we’re gonna be doing portions within WPF. We’ve just found that the velocity of our team and the time lines that we had to hit to produce really well constructed visually, very basic visual line of business application forms. We’ve had higher velocity with the tools and a knowledge that we currently have. That being said, we are all gonna be trained in WPF and we will be doing another portion of the application on WPF but it’s gonna be less critical than what we are doing today.

The simple reason there, is we weren’t comfortable with the compass of application block stuff that’s available for WPF yet. As well as the overall skills and the depth of the skills of our entire team. We really believe in cross-disciplinary rules on our team. And we’re just finding that to get everybody up to expert level. WPF is gonna take a long time and there’s gonna be a lot of bumps on the road. Probably something we should have started long time ago from a wholistic corporate perspective but there’s really only a small number of experts on WPF in our team and we’ve found it too risky.

Derek: A common refrain it seems these days. So, how much do tools matter in doing Scrum right? And are there specific tools that you recommend? Are there sort of other tools in addition, what should people be looking at?

Joel: Simple tools are better. Tools that allow you to bucket information. What I mean by bucket is to categorize or put it into one or more instances. For example, we’ve seen organizations try to use Microsoft project. And you know Microsoft project does not hop in us when it comes to Scrum. And there’s a couple of reasons for that. Scrum relies on fixed duration based buckets. If you think about a sprint as being a scoop and we take that scoop and we dip it into a bigger bucket to get water out, right? The size of that scoop that we’re using is really gonna dictate how much we’re going to be able to do in that amount of time. So it really represents capacity.

With Microsoft project, it’s very tough to do that. You get to need the concept of some retasks that roll up to be an aggregate of all that’s children tasks and some of all that kind of sorts of stuff. You have to do funky things. And so I say, stay away from Microsoft project for doing any type of either the based planning and so forth.

We, at Imaginet, are using team system and we use work items instead of team system to represent not only the features that we’re gonna be implementing but also things like spikes and tasks and so forth. What team system provides is the way of categorizing your work items into buckets. So, we assign it to sprint buckets and we assign tasks and features to other functional categories. And it allows us to really kind of change things over time and do goofy things like using pivot tables to see what the status is for all the features or better assign to a particular sprint. And don’t be too rigid in terms of how you do your bucketing. Use fairly granular buckets and allow your bucket contents to change over time and having tools that allow you to easily move things between buckets or understand the capacity of a bucket is a really important thing.

What we’ve end up doing in Imaginet is building additional tools on top of team system that allow you to make that bucketing process a little bit easier. We don’t use interestingly enough, the templates that are available for Scrum for team system. What we’ve actually done is use MSF for CMMI, the base process template, one of the base process templates that comes in team system as a base for our process methodologies ‘cause we’re consulting company and that means we have to use a little bit more ceremony on what we do with our customers. But we can still implement all the Scrum principles using that methodology template.

Derek: When you do a projects internally, do you follow the same processes, the same methodology? You mentioned that you have to do phase with a little more of ceremony because you’re dealing with external customers.

Joel: Yeah, it’s kind of interesting, we tried to never be too prescriptive on a per project basis and when we have some general categories going. ‘You know what, this is a contract driven, very high risked base project. We need to have ceremony therefore, we’re gonna wanna track this stuff. We’re gonna wanna try risks more explicitly. We might want to have more workflow as part of our bug tracking, more workflow when it comes to deployment to productions and so forth. Versus maybe in internal project. We have a lot of internal projects that we classify as gear. Well, obviously those on site are going to have as much ceremony, so we might wanna just track some simple things like features and tasks and nothing more. Or maybe just some simple sprints for example.

So, we try never to be overly prescriptive to say, you know, every contract that we do has to have, we have to use this particular process template. We like to try though at simple things as we go along. So when we startup for project, we’re going to say, ‘you know we have to track risks this way, we have to track features this way and we actually have a library of different work items and some reports and queries that we use to assemble new information into our project templates’. So, for example, we’ll create a brand new project template based of MSF for CMMI but then add an impediment work item or a glossary work item for example where we might wanna track some additional things as need be.

Derek: Last question for you Joel. If someone wants to get started with Scrum and someone’s listening to this and thinking, ‘oh, this sounds like a great idea’. What resource that should they go look for? What should they be buying? What should they be reading? What are the things that they should look for in order to really try this out on a project?

Joel: Sure. There’s really only two things that I recommend. There’s a book from Microsoft Press, I don’t have it in front of me right now. But it’s from Microsoft Press that’s written by Ken Schwaber. He’s one of the founders of Scrum. He claims not to be a founder but just an assembler of best practices into what he called Scrum. And I agree with that because a lot of the practices have been around for a long time before Scrum. I think it’s called An Introduction to Scrum but you should go and take a look at that on Amazon.

And also, there’s a company who’s actually called Conchango which is based at the UK which creates a Scrum process template for team system. Now, interestingly enough, even if you’re not using team system, you might want to actually take a look at this because from the Conchango web site and specifically the process guidance pieces that support team system from the Conchango web site, it goes into a very good explanation of Scrum. And it’s actually one of the resources that I’ve been promoting to people worldwide and say, ‘this is an all mindset of resources, takes you through the entire lifecycle of what Scrum looks like, how you can modify Scrum, has a great Q and A section, has links to videos of Ken Schwaber talking about certain areas. It’s really kind of the bill and end all’. If you want Derek, I can provide you a link to this and you could put it on your blog

Derek: That would be fantastic. Well, this is great Joel. I’ve really appreciate in taking the time. I think Scrum is fantastic. I’m not nearly as evolved in my execution of Scrum as you are. You give me something to aspire to, which is good.

Joel: Well, all through out, it’s I who’s learned. That’s for sure.

Derek: Yeah, if anyone has any questions or comments, feel free to leave up at Devcasting.com. If you have any questions for Joel, you can leave them there and I’ll make sure that they get passed on to him.

Anything else you wanna add Joel before we wrap up?

Joel: I just want to be going off and have a great vacation.

Derek: Isn’t it good and call and hop in the van. All right well, thank you Joel.

Joel: Okay. Take care.

Entry Filed under: Netcast