Resources for Agile /Scrum
January 19, 2016 8:55 AM Subscribe
What are some good resources you have used for implementing Scrum in web development shops?
The owner of our very small web development firm has asked us to read the book Scrum: The Art of Doing Twice the Work in Half the Time. I've read this (mostly negative) thread on Agile methodology.
Does anyone have good experiences using Scrum in a web design/development environment (as opposed to software development) and have suggestions for making it work?
The owner of our very small web development firm has asked us to read the book Scrum: The Art of Doing Twice the Work in Half the Time. I've read this (mostly negative) thread on Agile methodology.
Does anyone have good experiences using Scrum in a web design/development environment (as opposed to software development) and have suggestions for making it work?
Don't have a specific resource but a small observation about 'resources' in this area. I was in a group that was transitioning and had a manager new to the company that had a lot of experience previously (knew some originators) with agile/scrum. At one point the company did a video conference/class with a rockstar agile expert, LOfreakingL was it funny to watch the two of them clash!
There are a lot of smart ideas in that world but too many expert dogmatic consultants.
As for a resource the original statement is best.
posted by sammyo at 9:53 AM on January 19, 2016 [1 favorite]
There are a lot of smart ideas in that world but too many expert dogmatic consultants.
As for a resource the original statement is best.
posted by sammyo at 9:53 AM on January 19, 2016 [1 favorite]
Does your shop do client, fee for services type web dev work? I would strongly urge your manager and you to just go ahead and do the Scrum master training and get the certificate. This is the firehose method of getting into Scrum and it will save you all a lot of time and effort and banging your head against the wall. Do not try to do this from a book.
Also, you need to be clear on what problems you are trying to solve. Doing "twice the work in half the time" is not a typical mantra you'll hear coming from the mouth of a developer. Unless of course you can add on "for twice the pay!" to the end of that. You should run away.
I really enjoyed exploring and unfolding the Agile process in my web dev shop as a PM. I took the Scrum Master course and found that they didn't have a lot of answers to my "how do I market this to new clients?" and "fixed fee/deliverable contracts." I felt like the emphasis on understanding the user stories and requirements and building "just in time" was a real boon to just managing the workload and stress. I found that the built-in check-in point really increased actual collaboration and helped our often-fractured teams stay in a team mode.
But, working up new clients into this methodology each time was a challenge at best and a nightmare at worst. Having management not take the courses or have an on-the-ground understanding of what we were trying to do made for some endless and tiring debates. The owner really enjoyed saying things along the lines of "twice the work in half the time" in order to sell the work but that's not laying out the playing field in any comprehensible way.
If the contract says, "you will build the website to do X" then no amount of iterating will get you out from under that unless your client really wants to go there. We had one client that this method worked great with, we had a limited budget and we both agreed that we would see how far we could stretch it by clearly defining user stories and accomplishing small bits of functionality and then assessing where we wanted to go next. We had complete teams and we ended up in a different place than where we thought we were going to go, with very little stress and everyone was happy at the end. The client trusted us right off the bat (which is very important) and they were eager to "try agile." I had two other clients who did not go so well in terms of Agile (but they were kind of jerks anyway).
If you want to know how to do it, pony up and drink from the firehose. Then look very closely at your current process and see what can be improved. I found that the focus on user stories and breaking the project down into increments really helped us break through some bad work that we were doing. But it's not easy and requires enthusiasm and diligence.
posted by amanda at 10:20 AM on January 19, 2016 [3 favorites]
Also, you need to be clear on what problems you are trying to solve. Doing "twice the work in half the time" is not a typical mantra you'll hear coming from the mouth of a developer. Unless of course you can add on "for twice the pay!" to the end of that. You should run away.
I really enjoyed exploring and unfolding the Agile process in my web dev shop as a PM. I took the Scrum Master course and found that they didn't have a lot of answers to my "how do I market this to new clients?" and "fixed fee/deliverable contracts." I felt like the emphasis on understanding the user stories and requirements and building "just in time" was a real boon to just managing the workload and stress. I found that the built-in check-in point really increased actual collaboration and helped our often-fractured teams stay in a team mode.
But, working up new clients into this methodology each time was a challenge at best and a nightmare at worst. Having management not take the courses or have an on-the-ground understanding of what we were trying to do made for some endless and tiring debates. The owner really enjoyed saying things along the lines of "twice the work in half the time" in order to sell the work but that's not laying out the playing field in any comprehensible way.
If the contract says, "you will build the website to do X" then no amount of iterating will get you out from under that unless your client really wants to go there. We had one client that this method worked great with, we had a limited budget and we both agreed that we would see how far we could stretch it by clearly defining user stories and accomplishing small bits of functionality and then assessing where we wanted to go next. We had complete teams and we ended up in a different place than where we thought we were going to go, with very little stress and everyone was happy at the end. The client trusted us right off the bat (which is very important) and they were eager to "try agile." I had two other clients who did not go so well in terms of Agile (but they were kind of jerks anyway).
If you want to know how to do it, pony up and drink from the firehose. Then look very closely at your current process and see what can be improved. I found that the focus on user stories and breaking the project down into increments really helped us break through some bad work that we were doing. But it's not easy and requires enthusiasm and diligence.
posted by amanda at 10:20 AM on January 19, 2016 [3 favorites]
Yeah, twice the work in half the time, no. Not realistic. However, I've really enjoyed transitioning to Agile with a Scrum master certified colleague – we do functional testing (with a bit of integration testing in the mix due to system requirements), and he brought so much clarity and direction to Agile that it really helped. So I too would highly recommend the firehose method and going into Scrum master certification. It's not something that lends itself to book learning – it's best learned either on the ground from an existing expert, or in that certification.
I have been on so-called "Agile" projects that were not, and a few people read books, and it was just a mess. There's a joke in our company that Agile is often synonymous with "whatever the fuck goes" because of similar experiences. This latest experience wiith a genuine Scrum master, though, has really been an eye-opener.
The biggest hurdle to this is UAT. Man, getting people to actually test the crap they've asked for....brutal.
As a test manager can I just say AMEN? Also: please for the love of god do not just tack on testing as an afterthought. Especially in Agile. One of the two Agile transitions I'm on is being saved because it integrated our test lead into design and development phases, so we testers always know where we're at and what needs testing. The second Agile transition has begun with "oh, look! a test team! we'll add them on as an afterthought" when in the existing V-model project... well let's just say that if it weren't for our team being implicated from the design phase, it would be in flames. I can't even imagine what it might explode into as an Agile project. (We're insisting that we at least participate in user stories, because yikes.)
posted by fraula at 11:31 AM on January 19, 2016 [2 favorites]
I have been on so-called "Agile" projects that were not, and a few people read books, and it was just a mess. There's a joke in our company that Agile is often synonymous with "whatever the fuck goes" because of similar experiences. This latest experience wiith a genuine Scrum master, though, has really been an eye-opener.
The biggest hurdle to this is UAT. Man, getting people to actually test the crap they've asked for....brutal.
As a test manager can I just say AMEN? Also: please for the love of god do not just tack on testing as an afterthought. Especially in Agile. One of the two Agile transitions I'm on is being saved because it integrated our test lead into design and development phases, so we testers always know where we're at and what needs testing. The second Agile transition has begun with "oh, look! a test team! we'll add them on as an afterthought" when in the existing V-model project... well let's just say that if it weren't for our team being implicated from the design phase, it would be in flames. I can't even imagine what it might explode into as an Agile project. (We're insisting that we at least participate in user stories, because yikes.)
posted by fraula at 11:31 AM on January 19, 2016 [2 favorites]
I'm a... well, a glorified proofreader on the web development side of a big brand that loves Agile. Message me with questions if you want.
posted by emelenjr at 3:00 PM on January 19, 2016
posted by emelenjr at 3:00 PM on January 19, 2016
How does your shop bill for work? Doing customer billable work agile generally requires the buy in of the client, as agile and fixed cost bids DO NOT GO TOGETHER. Also generally speaking, the client has to really trust your shop to sign off on agile, so it's something you can do with establish clients where that trust exists. But if the boss wants to bid fixed cost on poorly scoped projects then employ agile I strongly suggest you have a plan B ready to go. Because your shop is going to run our of clients, or money. Whatever comes first.
posted by COD at 5:44 PM on January 19, 2016 [2 favorites]
posted by COD at 5:44 PM on January 19, 2016 [2 favorites]
Hi, I defended Agile a bit in that thread. But I also agree with the comments here that you've got to know why you're doing it and plan how to integrate it with your clients' and workmates' expectations. Also, the linked Agile Manifesto above is critical: that's *why* Scrum exists, and Scrum isn't the only flavor of Agile. So read the fairly revolutionary Manifesto (and 12 principles); learn it; love it. It's all about practicality, rational inspection of results, and most importantly it's about treating all the players as humans. To the extent someone pushes it on you as "twice the work ..." I'd worry they aren't really grasping the intent of Scrum. That book has an unfortunate title; I like it and I think Jeff Sutherland even mentions early on that he wrestled with the idea that the title might give the big bosses the wrong idea. He's correct: you really do get more done in less time. But there's a learning curve and you've got to dive in with CI processes, test automation, co-located teams, open communication, a present and active product owner, &c. or it ain't gonna work.
I would go grab some books like Coaching Agile Teams or maybe Succeeding With Agile (the whole Addison Wesley set is pretty good) and browse them. Also Mike Cohn of Mountain Goat has a good blog about this stuff, and there are even some good groups on LinkedIn where you can see often basic questions asked. Scrum Alliance does cert and training, so request to be sent to a 2 or 3 day Scrum Master class and get a basic overview.
Do make sure you figure out how this works with clients. With my last company, we told the client "you're hiring our dev team for $x a month and we'll work on whatever you want. Here's how the process works." They loved it. They actually ended up having us do a bunch of unplanned stuff and bailed on parts of their original project because the 2 week increments and the product backlog gave them so much better insight into their own priorities. It was supposed to be 3 months but they rented our whole team for 2 1/2 years and we built them all kinds of crazy stuff: Complicated multi-language web site with login area stuff and admin tools, intranet reports, setup of their infrastructure in different countries, whatever. But if the contract had said "build this web site to this giant spec for $xxxx dollars" it would have been a mess.
Hope this helps ... you can also MeMail me.
posted by freecellwizard at 9:46 AM on January 20, 2016 [1 favorite]
I would go grab some books like Coaching Agile Teams or maybe Succeeding With Agile (the whole Addison Wesley set is pretty good) and browse them. Also Mike Cohn of Mountain Goat has a good blog about this stuff, and there are even some good groups on LinkedIn where you can see often basic questions asked. Scrum Alliance does cert and training, so request to be sent to a 2 or 3 day Scrum Master class and get a basic overview.
Do make sure you figure out how this works with clients. With my last company, we told the client "you're hiring our dev team for $x a month and we'll work on whatever you want. Here's how the process works." They loved it. They actually ended up having us do a bunch of unplanned stuff and bailed on parts of their original project because the 2 week increments and the product backlog gave them so much better insight into their own priorities. It was supposed to be 3 months but they rented our whole team for 2 1/2 years and we built them all kinds of crazy stuff: Complicated multi-language web site with login area stuff and admin tools, intranet reports, setup of their infrastructure in different countries, whatever. But if the contract had said "build this web site to this giant spec for $xxxx dollars" it would have been a mess.
Hope this helps ... you can also MeMail me.
posted by freecellwizard at 9:46 AM on January 20, 2016 [1 favorite]
I think there's some good advice here but just want to add ...whether you do a class or read books or online or have workshops, people are going to HATE it for 1-2 sprints at least and you just have to back up the reasoning behind all your ceremonies and activities. Be able to answer questions like "Why do we have to meet every day?" "Why don't you just tell us what to do?" "Why can't we extend the timebox?" Etc etc etc.
posted by sweetkid at 10:53 AM on January 20, 2016 [1 favorite]
posted by sweetkid at 10:53 AM on January 20, 2016 [1 favorite]
Also: don't be discouraged because people hate it, and don't go back to the old way just because people hate it. They're going to hate it at first. If they still hate it after the first 3-4 sprints, you need to re examine the process.
posted by sweetkid at 10:54 AM on January 20, 2016
posted by sweetkid at 10:54 AM on January 20, 2016
I've found thoughtbot to have a really good description of their process.
I work in a small development team and lead our scrum process. I'm not formally trained in scrum but I really like that it gives us the opportunity to continuously improve our development process. We use PivotalTracker which is great for managing sprints. We've found it hard to use for longer term planning (it's quite biased towards a list of detailed stories with estimated work effort) so we have a google doc with a list of quarterly objectives that we use to group our detailed work.
A quick summary of our process is as follows. We work in two week sprints:
* kickoff meeting Monday morning (first thing 30-45 minutes). We go through pre-written/outlined stories with our product person, discuss them and make sure we all agree with scope and effort level
* 10 minute standups every morning at a fixed time
* 30-45 minute retrospectives Friday (10 days later); here we review our work and discuss what went well, and what we can improve
Overall it's nice cos we can talk about how to improve our workflow in a constructive setting. There are also lots of opportunities to ask for help (which we all avail off). There are a few other things which I'm happy to expand upon if it's useful - I know I'm not an expert but it really works for us.
posted by a womble is an active kind of sloth at 5:53 PM on January 20, 2016
I work in a small development team and lead our scrum process. I'm not formally trained in scrum but I really like that it gives us the opportunity to continuously improve our development process. We use PivotalTracker which is great for managing sprints. We've found it hard to use for longer term planning (it's quite biased towards a list of detailed stories with estimated work effort) so we have a google doc with a list of quarterly objectives that we use to group our detailed work.
A quick summary of our process is as follows. We work in two week sprints:
* kickoff meeting Monday morning (first thing 30-45 minutes). We go through pre-written/outlined stories with our product person, discuss them and make sure we all agree with scope and effort level
* 10 minute standups every morning at a fixed time
* 30-45 minute retrospectives Friday (10 days later); here we review our work and discuss what went well, and what we can improve
Overall it's nice cos we can talk about how to improve our workflow in a constructive setting. There are also lots of opportunities to ask for help (which we all avail off). There are a few other things which I'm happy to expand upon if it's useful - I know I'm not an expert but it really works for us.
posted by a womble is an active kind of sloth at 5:53 PM on January 20, 2016
This thread is closed to new comments.
I've only used agile in software dev, but what I like about it is the iterative process. You're never going to get too far down the road with a bad solution. The biggest hurdle to this is UAT. Man, getting people to actually test the crap they've asked for....brutal.
As a Change Management person, what I'll tell you is that folks at the top need to convey GOOD reasons for change and they need to be 100% in support of folks coming on board. Reading a book ain't going to cut it. If you're going to move from Waterfall (or whatever you're currently using) to Agile, you can't just mandate it. There should be classes, focus groups and user communities. Besides, who in your group is likely to be Scrum Master?
Most places try to adopt a Waterfall/Agile hybrid. This is just confusing and annoying. No one method is perfect, but pick one and go with it.
posted by Ruthless Bunny at 9:09 AM on January 19, 2016 [4 favorites]