There are many companies today implementing agile and DevOps practices, usually enabled by a microservices architecture. Most of them are focused on continuously delivering value to their customers within the boundary of a time-bound sprint.
When agile transformations fail, many agilists blame their executives for not caring about or understanding agile. However, few people focus on the different languages that IT and business people speak, and the different outcomes that both sides desire.
Many agile teams rework previously deployed stories, even after plenty of in-sprint testing. Even well-groomed, refined stories, framed with typical, alternate, and error scenarios and gracefully described in well-formed Gherkin, continue to encounter all sorts of bugs.
Modern software delivery involves lean principles, DevOps practices, and of course tools. Implementing those elements in harmony will necessitate a change in how teams operate—more specifically, it will require a change in how managers think about teams.
Part of the path to DevOps requires adoption of agile methodologies. What does it mean for testing when you switch from the traditional waterfall model, with a few long release cycles per year, to the agile model, with changes occurring every two weeks? Here are five key factors to achieve the agile software testing necessary in DevOps.
In Scrum, the product owner and the ScrumMaster are supposed to drive sustainable development. But there's a third force missing from the formula: the health of the code itself. We often forget that our code is also a member of our team, and we have to be concerned about its health and well-being as much as any other team member. That means using practices to develop good code from the beginning.
Agile product management aligns the Product,
Technical and Marketing teams towards building customer-centric products faster
with a possibility to refine the product scope based on the market conditions.
Agile should be about using tailored practices, techniques, tools, and team organizations that fully align to your business context. But the world of cookie-cutter solutions strongly influences businesses and their IT teams to follow their one-size-fits-all frameworks, methods, and tools. Such an approach often introduces many risks, so beware of the following symptoms that may indicate that your agile team has gone astray.
Following agile ceremonies may make an organization feel good, but that’s only a start. “Great big agile” requires leadership at all levels to focus on self-organization and empowerment as a universal framework.