Shipa is open sourcing Ketch, Shipa's deployment engine, under Apache License Version 2.0.
Today's choice of Agile methodologies is far greater than just the original XP (Extreme Programming) and Scrum, both introduced over two decades ago. Plus, there is a raft of hybrid Agile approaches emerging, in response to organizations needing large-scale Agile, to support compliance and coexist with more traditional methodologies.
Beyond Scrum and Kanban, other methodologies better suited to large-scale Agile including the Scaled Agile Framework (SAFe), Disciplined Agile Delivery, Large-Scale Scrum (LeSS), and large-scale Kanban have traction in many blue-chip companies.
All of these methods help to scale-up Agile, but we are also seeing more organizations combining both traditional and Agile approaches within the software lifecycle. By doing so, they can balance the demand for control and structure, against flexibility and response to change.
Take for example a manufacturer of specialized components for the telecommunications market. The customer requirements are strict, the order volumes are large, and lead times are very long, so there needs to be comprehensive planning of the entire development process. Waterfall development is the established way of working.
However, the test and verification processes down the line are a lot less predictable: it is difficult to know exactly when a component is going to be ready for testing. So, the manufacturer introduced Agile into the testing phases. Bi-weekly sprints give the verification team the flexibility manage a volatile backlog, and by using a Kanban board, they visualize and assign upcoming tasks. The organization gets the best of both worlds: traditional structure and the ability to respond to the unknown.
Hybrid Agile also means that organizations driven by regulation can become more Agile. This is a big step forward. Until recently, more risk-averse markets were wary of changing. Indeed, many organizations are embracing Agile precisely because it contributes to quality, compliance, and control, without creating unnecessary roadblocks to market.
It's All in the Execution
Regardless of the flavor of Agile chosen — packaged, hybrid, customized, or unlabeled — what matters is how it is adopted. A lot of organizations we speak to are inherently Agile, even if they do not give it that label. Others claim to be Agile, but are not doing it well.
Across all types are some typical hurdles to overcome. For instance, beyond the first flush of Agile at team-level, organizations can find it hard to scale to other teams or functions. Everyone involved needs to have an Agile mindset if it is to work, and that includes management, who sometimes abandon Agile at the first hurdle, claiming it does not work. Achieving sustainable Agile means hard work and is an on-going process that includes retrospectives and continuous improvement.
Evolution Not Revolution
The growing volume of organizations worldwide who are relatively mature in their Agile experiences have a lot to share with others. Beyond getting the buy-in of management and colleagues, they have identified the low-hanging fruit where some initial successes introducing Agile can be quickly achieved, or where there are team members keen to try Agile. Those projects and individuals then become advocates for more widespread rollout.
Taking a hybrid traditional/Agile scenario as an example, a starting point might be looking at Test-Driven Development (TDD). Instead of testing finished code against the original requirements, testing takes place automatically during development, re-tested quickly as needed. This "Shift Left" way of working introduces Agile, without having to affect those using more traditional processes.
Don't Forget Documentation, Planning, and Metrics
While Agile encourages less dependence on documentation, it does not mean abandoning it altogether. Documentation, such as architecture diagrams and key event flows, is necessary to avoid delays in internal coordination, particularly in hybrid Agile scenarios. In compliance-centric markets, documentation is essential.
Good Agile is also about thinking in terms of long-term gains, not just the short-term. Make use of the product backlog: managing it better will have a big impact, because it can provide end-to-end visibility of how value is really being added. It will also help balance out the push (investors, sales, competitors, market conditions) versus the pull (limitations of capacity, time, skills and cost).
True Agile success is based on business outcomes, not vanity metrics. For instance, knowing how many people are actually using a new feature, or additional revenue generated, has more value to the business than counting the number of story points delivered.
Solid traceability matters, especially where regulations exist, because it keeps track of cause-and-effect, while providing evidence for reporting purposes. Traceability helps answer the question: "If something changes, what will be affected?" and works backwards as well as forwards. Backward traceability is checking that what was designed or built is justified by an upstream requirement. Forward traceability is checking that what is needed is addressed at a later stage in the project lifecycle.
To manage traceability, organizations are creating traceability matrices, which document how user stories, tests, and issues are connected, making it easier to analyze impact and support accountability. Some organizations still use Word docs or spreadsheets for these matrices, while industry leaders are automating the process with application lifecycle management tools.
However, while tools help, the right culture is crucial. While it is good to learn from others' choice of Agile, it is wise to take away the parts that are most relevant and adapt them to each situation. Agile has so much to offer all kinds of organizations — the flexibility to innovate and introduce new products at speed, without compromising on quality or compliance — but it is an ongoing process. Accept that there will be roadblocks along the way (but that they can largely be overcome), that Agile is not a one-size-fits-all or static model, that tools help but are not the only answer, and above all, that change is the constant.