Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Are You Really Done, Done?

DZone's Guide to

Are You Really Done, Done?

One of the principles of agile is to Deliver Working Software: Deliver working software frequently, from a couple of weeks to a couple of months in less time.

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

Written by Robert Sfeir for LeadingAgile .

One of the principles of agile is to Deliver Working Software: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. What that principle doesn’t tell us is: who are we delivering the software to exactly? Of course the answer is (and should be) it depends!

A small team would deliver software directly to the consumers. In larger organizations, and specifically ones going through an agile transformation, the delivery of working software has different meanings. For example: your team builds the front end of a complex system. Can it simply upload your software to a production server when it’s development ready? It is likely that someone deploys it for you. Training and documentation may also be necessary, and scheduling and executing it also requires additional time. Integration and regression testing at scale is yet another factor, and the list goes on.

As we work with agile at scale the definition of done for a team is only sufficient for the team. The definition of ready for a user story is sufficient for those developing the stories. So how do we know when we’re truly ready to release?

The Definition of Release Ready.

Our Teams work with a supportive cast of characters that help us get our work to its destination. Much like a business analyst will consider what the developers need, it is logical that developers consider the downstream activities that affect their ability to release. Developing the software doesn’t end our responsibility to deliver working software.

I use the Definition of Release Ready as a way to give the Team an opportunity to explicitly understand and track what needs to happen after the development is done. To define Release Ready I include various stakeholders that are responsible for getting the work to the finish line. Some groups that should be involved in the definition are:

  • Security
  • Integration Testing
  • User Acceptance Testing
  • End User Documentation
  • Training
  • Tech Ops

All the work mentioned above should take place as close to development as possible. Some of the work by its nature will tend to leak beyond the sprints. Defining Release Ready together with the Team will not only validate your work, but also build on the agile principles of building relationships, respect, face-to-face communication, and delivering working software.

When are you really done, done…done?

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.

Topics:
release management ,project management ,team collaboration ,agile

Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}