The University of Helsinki’s way of working - Living documentation on this wiki

The purpose of this wiki is to maintain living documentation on the University’s own established agile practices, to the extent they are not already well-defined elsewhere (e.g. when a practice is not defined in the Scrum Guide or Modern Agile, or the University's way clearly deviates from these). In particular, local interpretations of the Kanban model, for which no canonical definition exists, have been documented here.

As a default, projects and development teams should use the practices presented in the Scrum Guide and this wiki, as they have been proven to work in the University's context in the experience of other teams. However, if a default presented here is not suited to the needs of your project/team, or is simply too vague, does not add customer value etc., it is advisable to adapt the practice. In such cases, make the deviation and the reasons for it visible both internally (e.g., to the PO) and externally (to other teams): discuss internally why you are adapting a practice and document your version to this wiki, so that also others can understand and learn.

Contents

• Modern Agile rooted in long tradition
• Choosing an appropriate development model
  • • Scrum: for easily packaged work 
    • Kanban: for stable industrial output or as a spice
    • "ScrumBan"
    • Moving away from Scrum?
    • Waterfall
    • Working outside these models
    • Cowboy coding
    • Vibe coding
• Scrum
  • Scrum Guide as a baseline
  • Local cultural variations in this wiki
• Kanban
• Scaling Agile

Modern Agile rooted in long tradition

The University of Helsinki’s approach to application development is accurately described in general terms by Modern Agile and its four basic principles:

• Make People Awesome
• Make Safety a Prerequisite
• Experiment & Learn Rapidly
• Deliver Value Continuously

The original Agile Manifesto of 2001 and the 12 principles (in Finnish) behind it still influence our Agile thinking as well. 

Long traditions in Agile 

The University of Helsinki’s application development has had experience of Agile IT projects since 2005, the early days of Agile, before most people had even heard of it. Since 2013, all application development commissioned and made in-house by the University has been required to be Agile, though the concrete methods have varied and there is no single definition of Agile.

Scrum and Kanban have been the methods of choice for most teams for nearly 20 years, but as the field of software development evolves, so should the toolbox! Modern practices for successful agile teams such as continuous flow & micro-cadences, no ceremonies/estimates/roles, impact-based planning (e.g. OKR) are gaining ground and are probably being integrated into evolving Scrum practices, but we do not keep track in a centralised manner. Do share what works for your team! 

At the core of the University’s agile development, light and minimalistic structures have been more typical than extensive, enterprise-level frameworks. This trend seems to continue in the foreseeable future.

Choosing an appropriate development model

Teams and projects are allowed quite wide autonomy regarding their way of working. Here are some guidelines and talking points for choosing the best fit for your specific need. 

Scrum: for easily packaged work 

Scrum is used primarily during product development e.g. within a project. It best fits situations where:

1. Your business problem can organically be divided into fixed-length increments (i.e. 1-2 week sprints) and the increments seem to consist of meaningful packages or themes.
2. Your team benefits from the clarity, collaboration and rigour of Scrum structures, helping them maintain focus and deliver value. For some teams, the rather heavy time investment (up to 10-20% of work hours) required for Scrum rituals can feel like artificial 'ceremony overload'. In other words, choose (or keep using) Scrum if the team's impact is clear and the team's efficiency is not lost in the tangle of backlog refinement, estimates etc.
3. Your team benefits from the estimation and measuring techniques in Scrum, helping them deliver value, instead of using it a performance metric to manage the resources,
4. The people in Scrum roles can actually do what the role description says: the Scrum Master can actually remove obstacles, the PO actually has the mandate to make decisions regarding the backlog etc.

If you think these basic tenets of Scrum cannot be easily adhered to, you might want to think whether Scrum will bring value to your process instead of just introducing friction, or at worst, a cargo cult. You might want to keep the valuable aspects of Scrum – transparency, collaboration, incrementality, fluidity, continuous improvement, introspection etc., and try to implement these benefits within some other framing. See "Moving away from Scrum?" below. 

When using Scrum, it is recommended to include some good practices not covered by official Scrum Guide, e.g.

• Basic elements (visualise, limit, measure) of the Kanban method: this provides valuable transparency and predictability
• Long-term planning of some kind (release planning, roadmap planning); Scrum doesn't say anything about releases etc.  

Kanban: for stable industrial output or as a spice

As a very minimalistic structure based in standardised industrial production, the Kanban method as a sole development model is most appropriate when

1. You already have a stable, deterministic production line with no great unknowns,
2. You strive for consistent quality and steady pace over innovation and managing complexity,
3. The work to be done accumulates in ~constant speed and consists of ~constant sized bits,

In software development, this typically occurs in the production/maintenance stage of software lifecycle and in the slower stages of projects, in the lull ('suvantovaihe') between active development periods. In short, Kanban as stand-alone solution fits situations where the intensity of development is low and the flow of work is near constant.

More often, you would mix & match elements of Kanban (visualise, limit, measure, optimise flow etc.) with elements from some other framing (such as Scrum or OKR or whatnot). With Kanban elements, you gain transparency and real-time situational awareness, but you don't get cadence (i.e. a rhythm, a pre-set reminder to practice introspection, to celebrate results or to prepare for the future) or a high-level view of what is valuable. It's a reactive process in that sense, not creative. 

"ScrumBan"

A possible mix & match of Scrum and Kanban would be to switch 'modes' between the two approaches whenever situation requires. If, for any reason, work cannot temporarily be tied to a time-boxed iteration (Scrum sprint), the team might switch to free-flowing Kanban for the time being. Think of a situation where there is too much uncertainty in terms of scope, knowledge, risks, obstacles or priorities to organise even a one-week sprint or other fixed-time work package. Such circumstances may arise e.g., when waiting for a response from the surrounding non-agile organisation (e.g., administrative decisions or external integrations), or simply during holiday seasons due to absences. Whenever the situation again allows for more long-term planning, a switch back to time-boxing would occur.

Similarly, during a technically challenging Scrum project, it is possible to temporarily switch to the ‘Kanban mode' to conduct, for example, a rapid technological experiment if it is not sensible to plan and start a sprint before such an understanding is achieved.

Moving away from Scrum?

There are variations of incremental, iterative processes that address some of the perceived drawbacks of the industry-standard Scrum of past 20 years. Your team may want to explore these, if many of the basic characteristics of Scrum described above seem to fail for you, or cause more problems than they seem to solve: 2 week increments with stories split from the backlog, refined and estimated, with rigid times dedicated to planning, refining, reviewing, retrospecting.

ShapeUp (2019) is an opinionated variant of SW development process cycle. It has experienced significant new popularity since 2025 with the AI boom, as it puts a strong focus on WHAT is worth building, now that AI's are taking more responsibility on HOW it's built. Compared to Scrum, it has longer increments for uninterrupted work, considerably less bookkeeping and ceremony, considerably more result-oriented scoping, and considerably less tolerance for lingering features dragging on forever. You may want to explore elements of ShapeUp, perhaps as part of your process, if you struggle with focus and clarity, endless lingering backlogs, feeling out of breath, or large projects clogging up your sprints. 

Waterfall

The straightforward deployment of an existing SaaS service, for example, can take place using a linear project model – assuming it does not include customisations, configurations or other customer-specific development.

Application development projects are carried out in an agile manner at the University of Helsinki, which means that a waterfall project is not an acceptable model for procurements where any kind of application development is carried out.

In practice, virtually all project work, even when described as waterfall, also includes some non-linear features, such as checkpoints or audit gates, which act as loopback points to fixing errors (even if the loop is slow or the checkpoint suboptimally late in the process, regardless whether we call the backtracking 'reclamations' etc.). We can genuinely wonder whether there even exists a model in which progress would be 100% linear. If your case really, really looks like a one-way street with no loopbacks, we encourage you to at least take up the issue of quality gates or similar assurances with the project's steering group / owner. The UH project model requires all projects to pass certain gates before proceeding further. 

Working outside these models

Some of the work can and should be organised outside these models, for example, a project's architecture design workshop or a security audit.

Discovery phase methods to increase customer understanding and to define what is worth building (e.g. Design Sprints and other service design methodologies) are even encouraged at the start of projects, followed by a shift into development phase methods described above. 

Cowboy coding

Ad hoc work (a.k.a. ‘cowboy coding') under the guise of agility is not acceptable under any circumstances. See also vibe coding below.

Vibe coding

All requirements regarding regulation (e.g. GDPR, information security) and quality assurance apply. Outsourcing menial tasks to a machine is an integral part of coding, but outsourcing responsibility of the software development process as a whole is prohibited. Vibe coding is good for sketching ideas (Proof of Concept) but the results need to pass the University's regulations and quality standards before production use. See Generatiiviseen tekoälyyn perustuvien koodausavustimien käyttö yliopistolla (in Finnish)

Scrum

The traditional method of application development on the project and team levels is Scrum. See above "Choosing an appropriate development model" for whether it's a good fit for your team/project.

Scrum Guide as a baseline

By default, the University of Helsinki uses Scrum as defined by the Scrum Guide of the Scrum.org community. The University of Helsinki uses the Finnish version of the Scrum Guide (Schwaber & Sutherland, 2020 / translation Lekman et al 2021):  https://www.lekman.fi/scrumguide

Local cultural variations in this wiki

However, few – if any? – organisations comply 100% with the Scrum Guide, and Scrum Guide does not have a view on all the procedures required for application development.

The University’s established practices have been described in this wiki, if they differ from Scrum Guide or are not described at all in it. When starting a new project, consider within your team whether you will adhere to these default values or deviate from them; document your changing and evolving practices here, possibly to be adopted by others as well. Evolutionary change is good! See sidebar for further information on Scrum in UH.

Kanban

Kanban is an evolutionary approach based on Lean principles and Just-in-Time production strategy that makes visible the process and its bottlenecks. In accordance with Lean thinking, the aim is to optimise the value chain, i.e. to minimise the lead time for generating added value.

There is no official Kanban software process. Kanban is very minimally defined and leaves plenty of room for the team's own interpretations and applications. The starting point is the team's current process, which will be fine-tuned as the team goes forward. See sidebar for further information on Kanban in UH. Here, the minimal structure of kanban is described, which can – and should! – be refined on a project-specific basis.

Scaling Agile

The University of Helsinki does not (currently, as of 2026) have a unified management model for agile development for the University as a whole. We tend to prefer light and minimalist structures over enterprise-level frameworks. This provides wide autonomy for units to organise their agile development, which has both its strengths and weaknesses.

Among the units actively involved in application development, University Services (YPA) has in 2024 adopted a common Digital Service Development Model (in Finnish: Digipalvelukehitysmalli). The model is based on the BT standard, developed by the Finnish Business Technology Forum. Its mindset and concepts are useful also in the wider context of the University of Helsinki.

We are also familiar with other agile scaling models, such as Disciplined Agile, Kokonaisketterä ("Total Agile"), SAFe, Nexus and LeSS, and some of their concepts are used by various stakeholders within the University, but not in a centralised or comprehensive manner. The Lean Culture Toolkit of YLE (National Broadcasting Company) is close to our hearts as a mindset, but not in an official capacity.