DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • MLOps: Definition, Importance, and Implementation
  • What Is mTLS? How To Implement It With Istio

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • MLOps: Definition, Importance, and Implementation
  • What Is mTLS? How To Implement It With Istio
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. A Better Way Than Staggered Iterations for Delivery

A Better Way Than Staggered Iterations for Delivery

Martin Hinshelwood user avatar by
Martin Hinshelwood
·
Jul. 18, 13 · Interview
Like (0)
Save
Tweet
Share
8.88K Views

Join the DZone community and get the full member experience.

Join For Free
metro-process-link

there is a better way than staggered iterations for delivery that will keep you on the path to agility.

i have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. they believe that by creating a timbox for planning, development and testing that we can get closer to agility and move away from our traditional models. unfortunately the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. in many cases it can be a significant step backward that will take many painful years to rectify.

staggered-iterations-for-delivery
figure: example of staggered iterations for delivery

i have heard this called many things. water-scrum-fall or maybe scrummerfall but whatever you call it the reality is that this is just small waterfalls and in the case above not really that small at all.

the problem with staggered iterations for delivery

in the diagram above we have an 18 week cycle from inception to delivery. that’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. worse this is the most expensive kind of feedback as the coding and testing teams have already moved on from the thing that is getting feedback and the result of that feedback will be more expensive to implement. indeed worse yet if qa finds something that needs fixed we have maximised not only the cost to fix but the mean time to repair as the developers have moved on. and what do they do with that feedback? how is it prioritised? do they quit what they are doing immediately and fix the previous iteration or do they wait until after they deliver this one? what if they are blocking qa? does qa sit around till the end of the iteration after the one they reported the problem in?

the solutions to staggered iterations for delivery

we need to foster teams over individuals and make those teams responsible for the delivery of working software. to get that we need cross-functional teams that can turn ideas into that working software. and we need to do it often.

  • cross-functional teams – we need to have everyone on the development team that is required to turn the backlog item into working software. if you were a property developer you would have access to joiners, plumbers, plasterers and electricians. you would create a team of individuals that was sufficient to complete the daily work on site with experts on hand as needed. this is the same process for a development team. you should have all of the skills that you require on each team to turn the forecast backlog items into working software each  and every iteration. have experts on hand for those tricky items but minimise the dependency that you have on them.

  • asynchronous development -  ideally you want all of the disciplines that you need to complete each backlog item to work together to deliver the software. this is more than handing off between disciplines but moving towards everyone always working at any point in time. this is a hard one to achieve but is the responsibility of the team to figure out how.

  • test first – test first is about not doing any work unless there is a measurable test that elicits that work. creating tests from acceptance criteria will make sure that your team is working on and understands the next most relevant thing to be worked on and that you have built what the customer wants. additionally, creating unit tests before code will make sure that your coders are working on the most relevant problem, and that each line of code that they complete does exactly what they intended. the long term benefit of this is that we now have an executable specification that will result in an error if a future change breaks existing functionality.
    • you are doing it wrong if you are not using test first

  • working software each iteration – if you don’t create working software at the end of each iteration you have no way of knowing what really needs to be done to create a working increment. if you do four iterations of two weeks before you think about creating a working increment, how much work (re-work really) is left that you need to complete to really be done? to really have shippable quality? if you don’t have working software at the end of each iteration you are making sure that your business can’t ship out of band, no matter how much it wants to.

  • quality assurance requires no testing – if you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the qa gate is to review the test results and coverage and determine sufficiency of those results and coverage. if you are taking more than four hours to qa two weeks of development then i would suggest that the development teams work is not sufficient.

these things will al individually help and if you are doing all of them together your value delivery and quality should start to increase over time.

conclusion

the expected result of staggered iterations would be an increase in rework and in technical debt. if you are moving from a 4 year iterative process to a 4 month one you will see value, but your process will be opaque and will only reduce your ability to deliver working software.

yes your cycle time will be reduced, but you can do so much better.

-every company deserves working software that successfully and consistently meets your customers needs. we can help you get working software with continuous feedback so that you agile teams can deliver continuous value with visual studio, team foundation server & scrum. we have experts on hand to help improve your process and deliver more value at higher quality.

Delivery (commerce) scrum agile unit test Software

Published at DZone with permission of Martin Hinshelwood, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Never Use Credentials in a CI/CD Pipeline Again
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • MLOps: Definition, Importance, and Implementation
  • What Is mTLS? How To Implement It With Istio

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: