Adapt to change.
Scrum is one of the most popular frameworks for agile software development. It is the art of “doing twice the work in half the time” and can get a product or service into the hands of customers quickly, especially after a prototype has been validated.
An agile team, or handful of teams, can quickly evolve from low fidelity prototypes into high quality products through iteration, continuous integration and regularly deployed releases. The framework is light-weight and the use of short sprints or iterations means organizations can respond quickly to changing customer needs with a low cost for change.
Teams who use the Scrum framework are self-organizing and supported by a Scrum Master, who serves the team in administrative events, team coaching and the pursuit of the agile mindset. Another critical role within the Scrum framework is the Product Owner, responsible for collecting and prioritizing product requirements in order of value to the customer. Product Owners continually manage a backlog of changing customer needs, ensuring immediate requirements are clearly understood for the team delivering the product.
There is no typical role configuration for a Scrum team, so teams can be formed to fit the context. However, we do find that a team of no more than 7 ± 2 is the best balance for efficiency and team communication. For continuity and the benefit of the final product, we recommend designers and software developers work together in the same team where possible.
Scaled Agile 5.0
The Scaled Agile Framework (SAFe) is an agile framework that is intended to guide enterprises in scaling multiple agile project and programs. SAFe aims to address problems encountered when scaling beyond a single team.
There are four configurations of the framework that are organized to support different levels of hierarchy and structure across an organization. Design thinking is present within all configurations. Therefore, it is essential for any organization undergoing a SAFe program to work with design thinking practitioners in the definition of user problems and solutions.
SAFe uses some of the more common techniques of design thinking, but not all. In SAFe 5.0 it makes specific reference to the following:
- User personas
- Empathy mapping
- User journey mapping
- Benefit/effort matrix
- Story mapping
Design thinking techniques were not included in SAFe 4.0. They are a completely new addition to the 5.0 iteration of the framework, although they have existed for many years prior to SAFe.