Tag Archives: Agile

Better Software East Conference

The Better Software East conference is coming up on November 13-18th in Orlando, FL. This conference about ways to improve your software development process is held concurrently with Agile Dev East and DevOps East.

I’ll be speaking at this conference on Thursday Nov 17th about “Evolving from Automated to Continuous Testing” which should be pretty interesting. And the fun part of it is that because I’m speaking I have a discount code you can use to sign-up at the conference. You can register here and if you put in the discount code BE16AH16 you can save up to $200. If you register early before Oct 14th then you can get up for $400 off, so take advantage.

About my presentation:

Testing issues can be a significant barrier to taking full advantage of agile approaches to software development and the emerging DevOps movement. To leverage these development and delivery strategies to their fullest, you need to evolve beyond automated testing to continuous testing. Arthur Hicken discusses the testing and development processes and technology that enable continuous testing. He shares insights on how to close the gap between business expectations and development activities by encapsulating clearly defining development policies for software releases.

Arthur describes how to prevent defects in code and prioritize defect remediation before a release candidate goes live. Explore ways to realistic test environments and simulations—critical features of the dev/test infrastructure—that enable continuous testing. Learn how to create a feedback loop that exposes defect patterns while highlighting opportunities to improve application design. Take back a comprehensive to do list for processes and infrastructure that must be in place for your organization to implement continuous testing and accelerate the SDLC.

About the conference:

Discover the latest in agile methods, technologies, tools, and leadership principles.

Whether you’re new to the agile process and need to get up to speed quickly or you’re experienced and ready to take your team or organization to the next level, our hands-on, in-depth workshops have you covered. Plus, Agile Dev East is held in conjunction with Better Software and DevOps East, allowing you to choose from three distinct programs.

  • Agile Development
  • Agile Testing
  • Agile Requirements
  • Agile Metrics
  • Improving the Process
  • Agile Leadership
  • Lean and Kanban
  • Agile for the Enterprise
  • Calendar

    Keep track of my calendar for other events – it’s over there on the right somewhere ——–> and don’t forget to register here and use the discount code BE16AH16. In the meantime you can follow the conversation about the conference on Twitter, Facebook and LinkedIn using the hashtag #BetterSoftwareCon. See you there!

Development Testing for Agile Teams Webinar

I’ve got another webinar coming up tomorrow as part of the Parasoft Power Hour series. It’s called Development Testing for Agile Teams. It’s on Thursday, June 19, 2014 12:00 PM – 1:00 PM PDT and you can register for free.

Simple-kanban-board-

Development testing is actually a core principle of iterative development methodologies. Still many teams struggle with implementation. This is why the most successful Agile strategies implement these practices. You can think about this as the continuous integration of software testing activities throughout the development lifecycle.

In this webinar, we’ll discuss how the systemic adoption of a Development Testing Platform (DTP) exponentially helps Agile teams implement Development Testing activities. The DTP is an infrastructure that automates the consistent application of testing practices — static analysis, unit testing, peer review, coverage analysis, runtime error detection, etc.— as well as accurately and objectively measures productivity and application quality. The one-two punch of a Development Testing Platform and Agile development methodology helps reduce technical debt and enable early defect prevention, which is the key to increasing efficiency and reducing risks over the life of the application.

[Update: even though the webinar has passed you can view a recording of it using the registration link above.]

Agile 10 years later: Dogma vs Doctrine

It seems like every few years a new software development methodology comes along. Frequently it’s a rehash of an old methodology, like object oriented programming’s rise (again) in the 90’s. Sometimes it’s a formalization of existing ideas and techniques, and sometimes it’s something completely new. Invariably the new toys excite a group of people who will promote them ad nauseam. Many of them become a flavor-of-the-month (or year) and then are never heard of again. Despite that, some of them end up being interesting and manage to survive their 15 minutes of fame.

The funny thing is that you can usually separate such ideas into two key components. One is the actual technology (ideas, tools, techniques, etc) and the other is the philosophy or religion. In other words, the “why” behind the whole thing. I prefer to think of it as religion because it tends to provoke the same kind of arguments and behavior as religious discussions and disagreements.

Agile development is a clear-cut case of such a problem. There are some wonderful, useful ideas embodied in the Agile Manifesto. If you apply them judiciously with an eye toward constant improvement and productivity, and where necessary take into account the evils of financial viability and mandated compliance overhead (such as aerospace, FDA, government, etc), you can start producing better software more quickly, and with less cost.

However when a group of people start doing Agile for Agile’s sake, you can have a disaster on your hands. I have witnessed this personally at some large companies where an Agile team had an interpretation of agile development that was at odds with the company’s needs.

I say interpretation of Agile, because different people have widely different opinions about the degree to which Agile alters their world. In one case a company building very specific hardware/software products has a very strong need to meet particular deadlines, and to deliver very specific features because they release a matched blend of hardware and software. In this company, the Agile team claimed that asking them to definitively schedule feature delivery was a ridiculous request. The team felt their company’s request was “ignorant” and beneath them. Not surprisingly, such an attitude doesn’t work well at companies who simply cannot have an agile release schedule.

For web-based organizations like Google or Amazon, the timing of feature delivery can be more or less whimsical. They can produce what they want, when they want.

On the other hand, companies building smartphones or heart-monitors face a very different reality. There are deadlines, requirements, scheduling, documentation, etc., all of which have to be met and coordinated.

The sad thing is that the dogma fueling the religious war (We can’t be expected to produce a schedule, we can’t write comments, etc) is counter-productive, which leads people to avoid Agile altogether, thereby depriving themselves of potential and probable productivity improvements.

In my experience Agile, like other methodologies before it, works best when followed in a contextual manner, mindful of product needs, organization (corporate) needs, and other issues surrounding the software in question. If you pick and choose the doctrines that can help your team and your product, you’ll be an Agile fan. If on the other hand you dogmatically adhere to “Full Agile,” without regard to the environment you’re in, you can cause project failure, put people out of work, and potentially kill a project or even a small company.

So Agile is 10 years old now. Should you use it? Will it make a difference? In my opinion if you separate the dogma from the doctrine you can definitely benefit. But beware the pitfalls. If you’re careless, you’ll waste time at best, and money, people and perhaps even more at worst. If you’re careful, the benefits from increase quality and productivity can be enormous.

Resources