[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 stories to share about 3 common mistakes of agile development. 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.
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:
- 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.
- 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.
- 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.
Summary
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 (https://blog.sqlauthority.com)
1 Comment. Leave new
Its very interesting sir…..Thank you for sharing with us…..