Re: [U2] Agile and Scrum
Just to be clear on this. Scrum and XP aren't particularly related. Scrum is a project management methodology and doesn't speak to how the programming is done. XP directly relates to how the development is done. Three of the 12 XP practices have overlap with Scrum (Planning Workshops, Small Releases and Testing), but that's pretty much where it ends. A lot of the thinking, obviously, comes from the same place. You don't even have to be building a system to use Scrum. You could use it to manage any other project that isn't a defined process; something like planning a vacation would work well with Scrum. It doesn't work well for things like building a house, because those kind of projects are less exploratory in nature. The reason that Scrum works is because it embraces the one concept that tradition PM methodologies dread - the fact that the act of starting to build a piece of software changes everyone's understanding of the system. It is inevitable that as both the programmers and customer see the system come together they learn things about the system and their understanding about it should work to best fit the business needs improves. Any methodology that bases all of its detailed planning on the flawed understanding that everyone has before the coding has started has got a big leg up when it comes to failing. Scrum works because it defers virtually all of the decision making until the last possible moment. No feature is build until it bubbles up to the top of the priority list, and the specifications for it aren't finalize until it's ready to be coded. This means that every decision is made in the light of the greatest possible knowledge of the system possible for that decision. And then all of those decisions are reviewed and re-evaluated by the customer a short time later. The biggest stumbling block that people have is, How do you do the strategic planning?. The truth is, as I'm sure everybody already has figured out, is that traditional strategic planning is either a joke, or at best delivers a product that misses the customer's goals by a wide margin. Traditionally, done is defined by identifying at the very beginning of the project a set of features that the software must have. But since this by definition based on an incomplete understanding of the system, is usually pretty flawed. So you think you've done strategic planning, but what you've really done is locked yourself into delivering a flawed design. You don't lose anything with Scrum, except you acknowledge at the beginning that you can't really tell when you'll be done because you can't know what done means at this point - call it the Heisenberg Uncertainty Principle of Software Development. On the upside, with Scrum you know that you won't waste time building features that nobody wants, and the programmers will always be focused on writing the code that the customer has identified as the highest priority - so it's almost a certainty that you'll get to done faster than with a Gantt Chart. Finally, you don't need any dedicated software to manage Scrum. Our Product Backlog is held in a Lotus Notes database. For reasons I won't go into here, I'm not doing burndown charts anymore, but when I did I just used an Excel spreadsheet. Most of our planning and tracking is done using Post-It notes on a whiteboard now. It works better than anything electronic that I've seen. Dave Barrett Project Manager, Lawyers' Professional Indemnity Company (LAWPRO®) This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Agile and Scrum
Some good summary information here, Dave. One note about not needing specialized software is that you use a white board with post-it notes. Using a Kanban board (or similar) with Scrum makes a lot of sense if you are colocated. If you are a distributed team, a tool like scrumy.com might be a good way to do the whiteboard with post-its. In anycase, I would content that a distributed team does need automated tools, although as you mention, they do not need to be dedicated to Scrum. We use trac and export to Excel at times for various purposes. One of the key tools I am not getting from this handily is a burn-down chart, which I think is potentially an excellent tool for the team to see our progress as we go through an iteration. If we switch our iterations from monthly (and I'm not doing a good job with that) to weekly, the burndown might be quite irrelevant, so it is good to know you are not even doing them and still consider it a Scrum approach. Thanks. --dawn On Mon, Oct 19, 2009 at 8:53 AM, David A Barrett dave.barr...@lawpro.ca wrote: Just to be clear on this. Scrum and XP aren't particularly related. Scrum is a project management methodology and doesn't speak to how the programming is done. XP directly relates to how the development is done. Three of the 12 XP practices have overlap with Scrum (Planning Workshops, Small Releases and Testing), but that's pretty much where it ends. A lot of the thinking, obviously, comes from the same place. You don't even have to be building a system to use Scrum. You could use it to manage any other project that isn't a defined process; something like planning a vacation would work well with Scrum. It doesn't work well for things like building a house, because those kind of projects are less exploratory in nature. The reason that Scrum works is because it embraces the one concept that tradition PM methodologies dread - the fact that the act of starting to build a piece of software changes everyone's understanding of the system. It is inevitable that as both the programmers and customer see the system come together they learn things about the system and their understanding about it should work to best fit the business needs improves. Any methodology that bases all of its detailed planning on the flawed understanding that everyone has before the coding has started has got a big leg up when it comes to failing. Scrum works because it defers virtually all of the decision making until the last possible moment. No feature is build until it bubbles up to the top of the priority list, and the specifications for it aren't finalize until it's ready to be coded. This means that every decision is made in the light of the greatest possible knowledge of the system possible for that decision. And then all of those decisions are reviewed and re-evaluated by the customer a short time later. The biggest stumbling block that people have is, How do you do the strategic planning?. The truth is, as I'm sure everybody already has figured out, is that traditional strategic planning is either a joke, or at best delivers a product that misses the customer's goals by a wide margin. Traditionally, done is defined by identifying at the very beginning of the project a set of features that the software must have. But since this by definition based on an incomplete understanding of the system, is usually pretty flawed. So you think you've done strategic planning, but what you've really done is locked yourself into delivering a flawed design. You don't lose anything with Scrum, except you acknowledge at the beginning that you can't really tell when you'll be done because you can't know what done means at this point - call it the Heisenberg Uncertainty Principle of Software Development. On the upside, with Scrum you know that you won't waste time building features that nobody wants, and the programmers will always be focused on writing the code that the customer has identified as the highest priority - so it's almost a certainty that you'll get to done faster than with a Gantt Chart. Finally, you don't need any dedicated software to manage Scrum. Our Product Backlog is held in a Lotus Notes database. For reasons I won't go into here, I'm not doing burndown charts anymore, but when I did I just used an Excel spreadsheet. Most of our planning and tracking is done using Post-It notes on a whiteboard now. It works better than anything electronic that I've seen. Dave Barrett Project Manager, Lawyers' Professional Indemnity Company (LAWPRO®) This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately. Ce courrier
[U2] Agile and Scrum
http://www.agilegamedevelopment.com/2007/12/pair-programming.html XP Development Jerry Banker ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Agile and Scrum
As a Scrum practitioner in an MV environment for the past 5 years or so, I think I can shed some light on this. First, the Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The basic idea behind Scrum is that you divide the work to be done into little chunks and they are put in a list called the Product Backlog. Usually each chunk is an individual feature. The customer prioritizes the Product Backlog, usually in a meeting with the Development Team who supply some time estimates. Then the Team decides what Backlog items they can complete in a fixed time period (usually 30 days), called a Sprint. They commit to completing those items. Complete means fully tested, potentially implementable code. At the end of the Sprint, the Development Teams shows what they have completed to the customer. Rinse and repeat. Once the Sprint has started, the list of PB items chosen cannot be changed. This is the golden rule. If you need to change it, then cancel the whole Sprint, deliver nothing, and start a new one. In 5 years, we've done that once (and it turned out to be a waste of time). It's a big stick. Really important is the idea that the customer sees completed work each Sprint. This is guaranteed to give them ideas, and let them see where problems may come up. The result of that is that some things in the Product Backlog may move up or down in priority, and new items will be added to the Product Backlog. I am constantly amazed at how poor non-programmers are at visualizing how unwritten software will work. This becomes a non-issue in Scrum. Any non-trivial bug is simply added to the Product Backlog. We don't argue about whether or not something is a bug, a new feature, a change in scope or mission from God any more. If it is going to take the Development Team's time, then it goes in the Backlog and the customer can assign a priority to it. End of discussion. In my opinion, it's a risk free approach to at least try on a project. Worst case scenario, you waste some time working on the stuff the customer thinks is the most important. There's no reason why you need to ditch documentation. Just make it part of the definition of complete. There are two major adjustments that programmers need to make. The first just happens by itself: The programmers realize they don't own the software. I can't remember the last time that we had a fight with the users over how the software should work, or what it should look like or whatever. If they're wrong, they'll see it in 30 days and they'll have to commit more of the development time to fixing it, but they won't be able to point fingers at the Team. We just build what they ask for. The second is that the programmers need to adopt a just good enough approach to programming. There's no value in making the code you write bigger than you need it to be, or to build in features that no one has asked for. Write the bare minimum to do the job required and nothing more. This doesn't mean writing crappy code or painting yourself into a corner, but don't go peaking down the project plan building in stuff you haven't got to yet. There's always a chance that you'll never get to that future feature. Our experience is that we've been able to open up a firehose of new functionality on the users with a small team and without building up a massive maintenance burden. There have been a few occasions when we've actually put a project on hold because the customer needs time to digest what we've done, revamp procedures, train personnel and re-evaluate future development priorities. How cool is that?!!! There are some Agile concepts that are a little tough to implement in an MV environment. Test Driven Development, for instance, is tough because you need an automated testing tool, and most MV programs constantly update the database, which means you need to roll back your database in order to reuse the test cases. All of which is tough. Dave Barrett Project Manager, Lawyers' Professional Indemnity Company (LAWPRO®) This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
Re: [U2] Agile and Scrum
Good post! Stuart Boydell -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David A Barrett Sent: Friday, 16 October 2009 07:01 To: u2-users@listserver.u2ug.org Subject: [U2] Agile and Scrum As a Scrum practitioner in an MV environment for the past 5 years or so, I think I can shed some light on this. First, the Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The basic idea behind Scrum is that you divide the work to be done into little chunks and they are put in a list called the Product Backlog. Usually each chunk is an individual feature. The customer prioritizes the Product Backlog, usually in a meeting with the Development Team who supply some time estimates. Then the Team decides what Backlog items they can complete in a fixed time period (usually 30 days), called a Sprint. They commit to completing those items. Complete means fully tested, potentially implementable code. At the end of the Sprint, the Development Teams shows what they have completed to the customer. Rinse and repeat. Once the Sprint has started, the list of PB items chosen cannot be changed. This is the golden rule. If you need to change it, then cancel the whole Sprint, deliver nothing, and start a new one. In 5 years, we've done that once (and it turned out to be a waste of time). It's a big stick. Really important is the idea that the customer sees completed work each Sprint. This is guaranteed to give them ideas, and let them see where problems may come up. The result of that is that some things in the Product Backlog may move up or down in priority, and new items will be added to the Product Backlog. I am constantly amazed at how poor non-programmers are at visualizing how unwritten software will work. This becomes a non-issue in Scrum. Any non-trivial bug is simply added to the Product Backlog. We don't argue about whether or not something is a bug, a new feature, a change in scope or mission from God any more. If it is going to take the Development Team's time, then it goes in the Backlog and the customer can assign a priority to it. End of discussion. In my opinion, it's a risk free approach to at least try on a project. Worst case scenario, you waste some time working on the stuff the customer thinks is the most important. There's no reason why you need to ditch documentation. Just make it part of the definition of complete. There are two major adjustments that programmers need to make. The first just happens by itself: The programmers realize they don't own the software. I can't remember the last time that we had a fight with the users over how the software should work, or what it should look like or whatever. If they're wrong, they'll see it in 30 days and they'll have to commit more of the development time to fixing it, but they won't be able to point fingers at the Team. We just build what they ask for. The second is that the programmers need to adopt a just good enough approach to programming. There's no value in making the code you write bigger than you need it to be, or to build in features that no one has asked for. Write the bare minimum to do the job required and nothing more. This doesn't mean writing crappy code or painting yourself into a corner, but don't go peaking down the project plan building in stuff you haven't got to yet. There's always a chance that you'll never get to that future feature. Our experience is that we've been able to open up a firehose of new functionality on the users with a small team and without building up a massive maintenance burden. There have been a few occasions when we've actually put a project on hold because the customer needs time to digest what we've done, revamp procedures, train personnel and re-evaluate future development priorities. How cool is that?!!! There are some Agile concepts that are a little tough to implement in an MV environment. Test Driven Development, for instance, is tough because you need an automated testing tool, and most MV programs constantly update the database, which means you need to roll back your database in order to reuse the test cases. All of which is tough. Dave Barrett Project Manager, Lawyers' Professional Indemnity Company (LAWPRO®) This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient
Re: [U2] Agile and Scrum
Agreed. An excellent post. And at 769 words, it's half an article. (Hint, hint.) David, if you (or anyone else reading this thread) would like to contribute an article to Spectrum magazine on this or related topics, please contact me. You can reach me at my part-time address, edi...@intl-spectrum.com, or at my regular address or phone number in the sig block below. An Agile Anecdote: I was going to try a simple form of XP (Extreme Programming) on a project several years ago. The client loved the idea and agreed to it with few reservations. I knew they just didn't get it when the next meeting they asked me to provide them with a Gantt chart showing the iteration milestones and what features would be in each iteration. Regards, Clif -- W. Clifton Oliver, CCP CLIFTON OLIVER ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com On Oct 15, 2009, at 1:36 PM, Boydell, Stuart wrote: Good post! Stuart Boydell -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org ] On Behalf Of David A Barrett Sent: Friday, 16 October 2009 07:01 To: u2-users@listserver.u2ug.org Subject: [U2] Agile and Scrum As a Scrum practitioner in an MV environment for the past 5 years or so, I think I can shed some light on this. First, the Agile Manifesto: ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Agile and Scrum
Good job and thank you for writing that up. I've been trying on the scrum front, after having some past project successes with various agile techniques, but I do not feel like I'm particularly successful on the Scrum front. We have our tickets for requirements (user stories) and tasks in Trac, so we attempted to get http://www.ohloh.net/p/agilo-scrum installed, to no avail. I am now attempting to use scrumy.com, which I like but it has no cross-reference to trac so that dual entry doesn't quite work for us and we haven't yet gotten into the swing of it. Of course the tools do not make Scrum, but it is difficult to do Scrum without at least a burn-down report. Additionally, there are a few best practices we do not have, such as all developers being remote (each typically being many states away from the next) and most work just a few sweat-equity hours each week on the project. I asked for suggestions on an agile list a while back and they suggested going to a weekly sprint, which I have tried a few times. The good news is that even with the few techniques we are using from Scrum, such as switching from a daily to a weekly Scrum meeting, and from having a stand up meeting to a skype conference call, but asking the same Scrum questions, we continue to move forward, even if at a very slow pace. We are not standing still, spinning or digging a hole as software projects can sometimes do. We are simply failing to use some of the key aspects of Scrum and failing to move fast, things I suspect might be related. I feel like I could do better, so any suggestions, given our constraints (no one co-located and no one getting paid, for example) would be much appreciated. Thanks. --dawn On Thu, Oct 15, 2009 at 3:01 PM, David A Barrett dave.barr...@lawpro.ca wrote: As a Scrum practitioner in an MV environment for the past 5 years or so, I think I can shed some light on this. First, the Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The basic idea behind Scrum is that you divide the work to be done into little chunks and they are put in a list called the Product Backlog. Usually each chunk is an individual feature. The customer prioritizes the Product Backlog, usually in a meeting with the Development Team who supply some time estimates. Then the Team decides what Backlog items they can complete in a fixed time period (usually 30 days), called a Sprint. They commit to completing those items. Complete means fully tested, potentially implementable code. At the end of the Sprint, the Development Teams shows what they have completed to the customer. Rinse and repeat. Once the Sprint has started, the list of PB items chosen cannot be changed. This is the golden rule. If you need to change it, then cancel the whole Sprint, deliver nothing, and start a new one. In 5 years, we've done that once (and it turned out to be a waste of time). It's a big stick. Really important is the idea that the customer sees completed work each Sprint. This is guaranteed to give them ideas, and let them see where problems may come up. The result of that is that some things in the Product Backlog may move up or down in priority, and new items will be added to the Product Backlog. I am constantly amazed at how poor non-programmers are at visualizing how unwritten software will work. This becomes a non-issue in Scrum. Any non-trivial bug is simply added to the Product Backlog. We don't argue about whether or not something is a bug, a new feature, a change in scope or mission from God any more. If it is going to take the Development Team's time, then it goes in the Backlog and the customer can assign a priority to it. End of discussion. In my opinion, it's a risk free approach to at least try on a project. Worst case scenario, you waste some time working on the stuff the customer thinks is the most important. There's no reason why you need to ditch documentation. Just make it part of the definition of complete. There are two major adjustments that programmers need to make. The first just happens by itself: The programmers realize they don't own the software. I can't remember the last time that we had a fight with the users over how the software should work, or what it should look like or whatever. If they're wrong, they'll see it in 30 days and they'll have to commit more of the development time to fixing it, but they won't be able to point fingers at the Team. We just build what they ask for. The second is that the programmers need to adopt a just good enough approach to programming.
Re: [U2] Agile and Scrum
Hi David, The rollback can be pretty easy if you have a virtual environment for the database testing ... Great story! Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of David A Barrett Sent: Friday, 16 October 2009 7:01 AM To: u2-users@listserver.u2ug.org Subject: [U2] Agile and Scrum SNIP There are some Agile concepts that are a little tough to implement in an MV environment. Test Driven Development, for instance, is tough because you need an automated testing tool, and most MV programs constantly update the database, which means you need to roll back your database in order to reuse the test cases. All of which is tough. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
