SQL SERVER – 3 Common Mistakes of Agile Development – Notes from the Field #074

[Note from Pinal]: This is a 74th episode of Notes from the Field series.  Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. Storytelling is an art very few have mastered in their life. When I requested Stuart to share his ideas about agile, he shared a very interesting insight on this subject. He had very interesting story to share about 3 common mistakes of agile developments. I very much enjoyed his notes from the field and I am confident that you will like it too.

In this episode of the Notes from the Field series database expert Stuart Ainsworth explains about 3 Common Mistakes of Agile Development.

 SQL SERVER   3 Common Mistakes of Agile Development   Notes from the Field #074

I’m a developer by history, but a project manager at heart.  I’ve started becoming much more interested in helping teams improve their workflow, not just helping them write better code.  To that end, most of the development shops that I’ve worked have struggled with the ongoing battle to get features built and shipped on a schedule that satisfies business requirements.  Good developers are proud of their craft, and want maximum time to create; business needs features to go out the door quickly in order to compete.  These goals are often in conflict with each other.

Agile methodologies (such as scrum) try to help balance this tension by encouraging active conversation between business and development, and continuously delivering working software that is flexible and adaptable to change.  In the shops where I’ve seen agile development fail to deliver, I’ve noticed the following 3 bad habits:

  1. We have a failure to communicate.

Communication sounds easy, but it’s really, really hard.  Well-defined requirements help, but they’re no substitute for ongoing mutual conversations between developers and business people.  If a requirements document is the only method of explaining what to build and when to build it, you lose the ability to forecast what comes next in terms of building blocks.

Several of the principles of that Agile Manifesto deal with communication between business and development, but my favorite one is “business people and developers must work together daily throughout the project.”  If you want to be an agile development shop, you have to be an agile business.   Business needs to understand the challenges faced by developers, and developers need to be involved in understanding the changing needs of business.

  1. Code releases are always a feature release or a bug fix.

Bug fixes are good, and features are what make money; however, if the only time your shop is releasing code is to implement a feature or fix a bug, then you’re not continually improving your product.  The temptation is to fall back into a waterfall-like methodology; deployments become huge stacks of code that are not added to the product (or operational environment) until the day that a feature is supposed to be released.  The larger the stack of code, the harder it is to test, and the greater the risk of failure.

What agile principles suggest is that you should “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”  The goal is to release code frequently, even if that code is only establishing groundwork for future development efforts; smaller code is easier to test, and ultimately, a feature release becomes the final step in a series of releases.

  1. Software release dates depend on the quality and completeness of the code.

This is similar to the second issue, but a slight variation; a shop that constantly changes the length of their iteration will ultimately experience burnout.  It becomes harder and harder to stay on schedule and feature releases get pushed further and further back.

I prefer to have a fixed iteration period, either every four weeks or once a month.  There’s something about a cadence that motivates people to focus and get things done.  If a developer is working on a bit of code that’s supposed to ship in a month, it’s easy to evaluate how likely that’s going to happen within a couple of weeks; if it’s not going to be complete, build the working software, and release it.  With each iteration, it becomes easier to define what can be done in a fixed-length sprint.


Agile software development lends itself to creative implementations, but it’s important to stay true to the principles of good communication, continuous improvement, and maintaining a constant pace for development.  Avoiding some basic pitfalls can help your team stay productive in the ongoing race to get features out the door.

If you want to get started with SQL Server with the help of experts, read more over at Fix Your SQL Server.

Reference: Pinal Dave (http://blog.sqlauthority.com)

SQLAuthority News – Scrum: Agile Software Development for Project Management

This is something I have learned while working for so many years as Project Manager. It is not as important to know how things are done but it is important to know how to get things done. Scrum is an Agile Software Development system which helps developers to get project done in reasonable time and with superior quality.

Scrum is organized around the following roles:

  • Product Owner – Determines what functionality is needed
  • ScrumMaster – Leads the Scrum and is primarily responsible for making sure the Scrum process is followed and removing impediments that keep the Team from working
  • The Team – Those who do the actual work that translates what the Product Owner has requested into usable functionality

The following is a synopsis of the Scrum process:

  • The Product Owner creates the Product Backlog (List of Desired Functionality in the System)
  • A meeting is held with the Product Owner, the ScrumMaster and the Team
  • The Team commits to getting x number of items from the Product Backlog done in 30 days. This 30 day block is known as the Sprint
  • The Team makes a Sprint Backlog (List of items that must be done to turn the Product Backlog items into shippable items during the Sprint)
  • The ScrumMaster meets with the Team daily and asks each member three questions:
    • What have you completed for the Sprint in the last day?
    • What will you complete for the Sprint tomorrow?
    • Is anything impeding you from getting your work done?
  • The Daily Scrum causes the Team to reveal exactly where it is, or where it isn’t
  • The ScrumMaster keeps distractions away from the Team
  • The Team self-organizes and keeps the Sprint Backlog up-to-date
  • An item on the Sprint Backlog is done when code is well-written, well-structured and thoroughly tested
  • At the end of the Sprint, a Sprint Review meeting is held
  • Items not completed during a Sprint are allocated to a future Sprint

Other important notes to keep in mind when utilizing the Scrum process:

  • Scrum makes a project’s progress and problems constantly visible
  • Every Sprint produces an increment of potentially shippable functionality
  • Scrum must be put into place before it can be fully understood
  • Scrum focuses on what can be done
    • It instills the “art of the possible” and allows work to go forward before things are “perfect”
    • You will never achieve perfection, no matter how much planning you do
    • Sprints are time-boxed to keep the team from searching too much for perfection
    • Focus efforts on a small set of pressing problems
    • Define work that will allow concrete results
    • Planning doesn’t have to be extensive for a Scrum project to get going
    • The minimum is a vision and a Product Backlog
  • Scrum is anti-sequential
    • Get going on what can be done
    • Help each other out
    • Collaborate
    • Sequential tasks divide a team
  • In Scrum, an estimate is not a contract
    • Scrum expects exceptions to the plan and doesn’t fear them
    • Adaptation is a normal part of the process

Reference : Pinal Dave (http://blog.SQLAuthority.com), Comments from Scrum Team Members, Many Online Resources