Ready for projects? – Try agile

I am lecturing at a software project course. This is the fourth time already and there are now some forty students enrolled. They will specify, design and implement solutions for eight different customers, some of whom are external companies and other internal university units. Not all customers are familiar with projects and only a few students have gained practical experiences from project planning, management and implementation.

I have twenty hours at my disposal to help getting the students ready for the work, but each of them will spend additional two hundred twenty hours to carry out their project. In project teams with around four members this sums up to six person-months. Will the students and customers benefit and be ready to grasp new projects?

The answer is “Yes, if agile”.

Sharing of competences across projects

Projects prosper in many places, because they are by definition time-wise and resource-wise constrained assignments aiming at results to meet pre-defined goals. It is tempting to plan things to be done so that calendar time and people’s work are not overly consumed and what is wanted will be achieved.

Following this reasoning, we could organize many tasks as projects and educate ourselves on how to make use of them. This is certainly done, but not everywhere. One and a half months is a rather modest fraction of the total sum of the work load of a degree student, referring to the participants of my course as an example.

More broadly thinking the number is higher, because modern action learning and group work activities and even thesis writing can be thought of as projects, although we do not often execute them exactly as such. However, at the university we do apply for and run a big portfolio of research projects. A majority of competitive funding is achieved through projects and we have the necessary means to carry them out. I haven’t seen any project to fail because of lacking such means.

We still mainly do not expose students directly to these projects and do not necessarily share project experiences between ourselves. When I lectured my course for the first time, I needed to spend quite much time to incorporate concrete examples into the existing course materials. Luckily enough, I had those available from the past many years, including also something that had gone miserably wrong in projects.

Because projects are individual assignments rather than permanent organizational structures, they become easily isolated. If post mortem evaluations are omitted, the opportunity of sharing competences across projects is missed. We should invest in preventing this to happen. In expert teams knowledge creation and sharing is the very basic process. The world-famous scientist Ikujiro Nonaka has shown this in an elegant way.

Just Scrum it

There is another aspect in modern project work that may be even more important, though, the agile approach. It represents incremental methods that can be traced back to as far as the late fifties. Evolutionary management, iterative design and the original Japanese lean production are among the forerunners of the agile era. The more recent Scrum method is, in my opinion, one of the best agile fruits seen so far. Had I the full authority, I would change my project management course to revolve entirely around Scrum.

A scrum is not an acronym, but a noun. It means the act of restarting play in rugby, so that the players pack closely together with their heads down and attempt to gain possession of the ball. This is the iconic picture of rugby football known by many.

Similar to teams of rugby players, Scrum teams “restart” their project work by getting their heads and hands ready for the next incremental play round alias Sprint. As one Sprint should last only from two to four calendar weeks, there is no room for playing with time and the proceeding of the tasks that are picked up becomes highly visible.

In the vintage project world results were fixed, but the tasks, calendar time and work efforts were flexible. Project budgets and schedules were overrun and more work done to ensure the early specified outputs. In the agile approach this is exactly the opposite. The results are flexible and the project resources fixed. An agile project can therefore provide something to deliver at any point and always on time. This may become as a surprise, but you better believe it.

What I will also emphasize to my students is that in Scrum teams there are only pigs, whereas all the other people – such as me as their teacher, are chickens. This is a compliment and not an insult. What it means is that in a bacon-and-egg breakfast the difference between a chicken and a pig is that the chicken is only involved, but the pig is fully committed. When you are committed, you will create, capture and share your competences.

Text: Veikko Seppänen
Photo: Wikimedia Commons