Agile Development with Scrum

  • Some great comments earlier on priorities and feature lists. A few things you've got to remember:

    • The customer has got to buy off on this and be a part of the process. Once you're locked in on a 30 day sprint, that's it. It should take an act God or the team agreeing to change to add things in. If things are added in, you can threaten to cancel the sprint if you think it threatens your success of delivering a product in 30 days.
    • The reason customer priorities constantly change and you can never get features signed off on is that the customer thinks this will be their only chance to get the stuff they want. After a few iterations of this the customer will realize that they will only be out the feature they REALLY want for 30 days and it will be in the next iteration for testing. If the customer wants the feature much faster than 30 days, they're probably not thinking things through all the way.

    This should be a partnership between all groups and you'll find it's untimately a culture shift for most organizations. It's been painful at my company because of that reason. But, we began to overdeliver and results speak for themselves.

    Brian

  • Re: QA

    One component of agile methods that is absolutely critical is Unit Testing. You can't develop at the speed of thought without constant, reproducable testing. A test-first methodology actually eliminates the biggest part of the bugs before you get to QA. The QA environment should be more along the lines of testing the infrastructure configuration.

    [font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
    Business Intelligence Administrator
    MSBI Administration Blog

  • The company I work for adopted scrum for five projects about a year ago. Since then all IT development has moved to scrum with about 25 simultaneous teams/projects. We have also adopted principles of scrum in operational areas. We reckon that we are the world's largest scrum shop.

    We do financial processing for a number of banks and insurance companies. In most cases our clients are very happy with scrum and even fund the teams that work on their projects and participate in the scrum meetings (as observers of course). For the minority of clients who are comfortable only in traditional "waterfall" development, we retro-fit our project planning and reporting to fit their needs, but still do the actual work in scrum.

    Many people in the organization who worked in various non-develelopmental roles such as project managers (inside and outside of IT) now spend 100% of their time as scrum masters.

    Our sprint cycle is two weeks, arrived at after some trial and error.

    Regarding QA, our QA department was expanded significantly for scrum and almost every team has at least one 100% dedicated QA person from day one to promote test-based development.

    Prior to joining this company I was a consultant/contractor for over 10 years and saw about 20 IT shops. The scope of the kind of institutional change this company has undertaken obviously dwarfs the various and frequent 're-organizations' typical in most IT environments, yet the problems have been relatively few and we've been able to deliver projects using scrum on a more ambitious schedule than would have been previously considered.

    By the way our enterprise runs exclusively on SQL Server 2000.

    Eric Berkowitz

    ericberkowitz@yahoo.com

  • We've recently started using the Scrum method here as well. So far it seems to be working well. The key is that the business must buy-in to the methodology. We have several business people who would give us pages and pages of features and requirements, but have also had them look at what the really needed at the time. We took the top requirements, decided what could be delivered in a 2 week dev time, 1 week QA cycle, and ran with it. Any changes/updates would wait until the next cycle. During the whole sprint, our business analysts talk with the business owners to ensure that the next sprint will focus on the correct requirements and also to give status reports.

    So far, this has been a good way to develop everything. We focus on what we can do, the number of hours remaining typically fluctuates early in the sprint, then drops as we close out the cycle.

    I think the whole process has helped in a couple of areas - more and regular releases to the business, focus on top priorities, helping the business focus on their top priorities, and a little less stress on the programmers. 😀

    Good thread here and thanks to Adam for the book recommendation. We're going to get a copy shortly to review. If it contains those great tips the reviews allude to, we'll definitely get some benefit from it.

    -Pete

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply