Over a million developers have joined DZone.

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

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

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 best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

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

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

{{ parent.tldr }}

{{ parent.urlSource.name }}