3 Things That I’ve Learned about Agile
3 Things That I’ve Learned about Agile
Take a look at what this developer has learned about practicing Agile from working with number of Agile development teams.
Join the DZone community and get the full member experience.Join For Free
The Agile Manifesto is 15 years old. By some estimates, 90% of software development organizations are practicing Agile in some form. So, if you are reading this, you probably have some experience with Agile. I’ve been using Agile for the last 8 years in various forms and companies. I’ve been a part of productive and fun Agile teams and I’ve also been on a few that had serious issues. Those experiences have taught me three important things about Agile that I implement as CTO of CUE Marketplace.
1. There Is No Such Thing as “Agile by The Book”
Agile is a toolkit of great methods to help teams respond to change and to help them quickly and consistently release working software. There isn’t one specific path to success with using Agile. There are some great frameworks like Scrum, XP, and Kanban. These are great starting points for a new Agile team. I’ve used pieces of all three in the past. Once a team starts working through their process, they’ll find that some tools work better than others. Every team is different with its own unique personality, so what works with one may not work with another. This is where you’ll see teams and their processes adapt to their internal culture and evolve over time. When organizations start to push "rules" for how their teams work, it hinders growth.
2. Change Is Good, Embrace It
Humans generally resist change. We don’t like the loss of control over situations, the change to our routines, admitting we failed or any of the other feelings or insecurities that come with change. We can’t control when a customer changes their mind, or a market situation changes, or if a stakeholder wants to add something last minute. The best thing to do is embrace that change. Agile has some great tools to help embrace change.
- Short release cycles allow those last minute additions to be only a few weeks away from release, no matter where you are in your current sprint. Just add them to the next sprint!
- Unit and automated testing will ensure that any last minute code changes will not break things elsewhere in your application.
- Regular retrospectives allow teams to look at what has and has not worked in their process. The teams pick one or two areas for improvement and focus on those during the next sprint.
- General transparency of the product and process promotes openness and constant input into what the team is doing.
3. Automated Testing Makes Everything Easier
Agile teams that I’ve been a part of all have had manual QA testers. There usually is a manual regression testing phase at the end of each sprint. There are a couple of concerns with that approach. One, most of your QA resources are not utilized throughout the sprint, and two, finding issues at the end of a sprint can make them harder to troubleshoot because the team won’t know when they happened. Some of the strongest teams I’ve worked with had a quality engineer on the team. The engineer builds new automated tests as new features are added and maintains the existing tests as the application changes. The automated tests run as often as possible. I prefer them run when new code is committed along with unit tests. If the test suite is large, nightly testing is another good alternative. These tests will tell the development team that something they just committed broke the application. Manual QA testing will always be needed in certain spots that cannot be automated, but most of the heavy lifting can be done by the automated suite.
I hope some of my lessons learned can help your teams be more productive and fun! There are many more great things about Agile including continuous delivery of working software, team transparency, sustainable development practices and close collaboration with the team and with customers alike.
To see more of what I'm working on right now, click here.
Published at DZone with permission of Steve Jovanelly . See the original article here.
Opinions expressed by DZone contributors are their own.