I'm a M.Sc from the Computer Science department at Aalborg University in Denmark. I've studied game development at DADIU, as part of my specialization in games on the master degree and specialized in HCI. Currently I'm the Project leader of BZS and I'm coding for the mod. I blog a bit on moddb when it is related to the mod or personal experience which I find useful for the game community. To read more about my study experience and other project, see www.ringhauge.dk

Report RSS Agile Development

Posted by on

I really wanted to write about agile development vs traditional development for a long time (since late September) and I even wrote a draft for some of it.
Lot has changed since. My Critique has changed a bit and some new aspects which I reflected upon, has changed my mind of the draft I made, and the things I wanted to debate.

I also wanted to review these methodologies compared to the general concept and how BZS is handling these. Unfortunately my mind will not remeber all the important details and I had numbers of things to see at meanwhile, hence I will not reflect upon BZS in this article.

I cannot guarantee that I carry all the facts in my mind. Intense mental concentration has a curious way of blotting out what has passed. Each of my cases displaces the last, and Mlle. Carère has blurred my
recollection of Baskerville Hall. Tomorrow some other little problem may be submitted to my notice which will in turn dispossess the fair French lady and the infamous Upwood.

Arthur Conan Doyle

(I always wanted to use this quote)

Not a solution, just a guide

The point is: Agile and traditional development is not about using "THE" solution and fight about which one of them is best.
I had numerous debates with my Professor: John Stouby Persson after the lectures about agile perspective and the affect it has on group work.

One of the things we remarked was that Danish Bank (who made a presentation for us) said they used agile development, but this was not exactly true as it was covered by an upper hierarchy of leadership upon the scrum team, which is seen in figure 1.
Danish Bank Structure
Figure 1: Upon Scrum lies UP, but then it becomes traditional at the above layers. Hence it is not completely agile.

And their "roll-out"(implementation) of agile development in teams was made very traditional, despite every expert and book would say to jump straight into it, as it otherwise could fail to make the teams understand the methodology. One of the best thing I think they covered, was the critique of the selection between agile and traditional development methods when starting a project.

Some of their project leaders want to use an agile approach, because it is hype, shows that you adapt yourself to new knowledge, which also is a way of showing commitment (I will get back to that later).
The Problem is that not all projects fit an agile approach as the best solution.
One of the best way to illustrate this, is as the book Craig Larman: Agile Iterative Development: A Manager's Guide describes in one of the check lists for agile or traditional selection:

Traditional: You know exactly what to do and how to approach it.
Agile: In the start, many things are unknown and things may change.

As a perspective: In some software projects, you are handed an list of requirements and you have a large document describing how everything must be. In such a case it is very easy to determine the schedule and just start coding. Where an agile project, like BZS mod and many others: you have a vision, but it is difficult to describe the requirements for all the content. This uncertainty may require things to be changed, and for such an approach, you must be able to handle these request through the project.

As Danish Bank says it: Waterfall is still an key option.
The framework they use to decide whether to use agile or traditional, is shown in figure 2.
Danish Bank Decision Framework
Figure 2: The Decision Framework looks at different influences on the project and provides points for everything which is good for the agile approach. To use agile, the score must in average be above 2.5.

Personally this was a very important lecture, as it arguments why agile and traditional is not a solution in it self, but rather a set of rules to adapt to the project, so the project can be handled in the best manner.

Which leads me to the next part: commitment (which my Professor and I had a personal debate about in 20 - 30 minutes)


Short intro:
John Stouby Persson has recently written a new article to be released in some Magazines. (which will be released in approximately two years, because they are really slow to post articles. That is rather stupid i think.)
The article is about group work, where research shows that: If a group consist of some members, but one of the members are more experience than the others. It may improve the collaboration and actual product, if that person is removed from the team.

In the above, I believe that some of the reasons that causes the group to work inefficiently, are if the experienced person acts as leader in a flat structure, or takes monopoly on a type of work, like coding. It will result in less commitment from the rest of the group.

In my current group(semester 5) we are working with Scrum. Even though there isn't any hierarchy in the group, we have one person who is an independent developer in his own firm, structure-freak and workaholic.
Compared to the rest of us who have worked together in two years, we are not near as eccentric with the progress in the project from today till tomorrow, and none of us consider a day to be from 8 till 20.

The "over active" person is definitely keeping my commitment on a lower level, not to mention that i try to ignore him as much as possible.
But on a general level, it also means that the things he makes, the rest of use will not be able to relate as easily too, as we don't retrieve the same writing/coding experience in the project, because that 15 hour code assignment was done by him on one day.
Not to mention, we are ahead of the time schedule, but he is the one having stress...

How is this related to agile development?

Many agile methods was developed in America (like scrum), where it is common to show your commitment by staying late at the office.(I don't recall whether it was west or east side of America, sorry.)
This is the agile manifesto: Agilemanifesto.org
And here is a bit explanation: Searchcio.techtarget.com

The individual and interactions refer to these principles:

  1. Recognizing that the best work emerges from self-organizing teams.
  2. Providing motivated individuals with the environment and support they need and trust them to get the job done.
  3. Maintaining a constant pace for completed work.
  4. At regular intervals, having the team reflect upon how to become more effective, then tuning and adjusting behaviour accordingly.

Before I give my version, please ask yourself if you see something wrong with these principles?If you look at principles, they all have efficiency in common: "best work", "get the job done", "constant pace", "reflect upon how to become more effective"

But research has also shown that a person is "only" effective about 20 - 25 hours a week and a "commitment" with many hours, evolves some amount of mind-spacing in the work time.

Leaders has an urge to earn most money as possible, utilized in a cost-benefit analysis. And leaders suck up to their leaders. (hence the "we must do agile project FTW no matter what" attitude)

Where XP is an agile method, which is very focuses on the programmer, with a maximum of 40 hours weekly work.
Scrum is an agile method focuses on leaders and unfortunately very misunderstood, with Sprints(effectiveness-control) that contains falsly-estimated-work-time(group pressure) and a scrum master, who due to incompetency believes he is in charge of peoples time management and questions the members life cycle (Evil leader, aka jerk).

Scrum done right, can improve the work yes, but one person can make it work slower, because the required commitment just starts a conflict and causes stress, even when there was no need for it.

The essential problem in this is, if the project is agile, it can be hard to estimate the time you need for research and implementation. As a developer you may ask yourself: How many schedules/rapports/presentations did you fake your content at ?
If you fake the content and it is discovered, you will just have to use time to refactor it and contribute with some lame excuse for the lack of correct content. However if you didn't fake it, would the commitment level you made really be appreciated? How much faking would you be willing to do, to prevent being fired? appreciated? pay raise?

This question can be quite relevant, as leaders measure the efficiency by using matrices and data like "lines of code" or for papers "number of pages" to determine the quality, of the teams and the individuals.
And in the end, quality is not about LoC or NoP, but getting the project right, but many don't understand this.

I find it important to fill life with more than work, example: family, entertainment, sleep, a moment of silence for your self. And I hope to join a workspace with the same opinion. Cause if the commitment level is the same, nobody will be looking down on you and you will be happy about your work.

I have altered some of the text above to be more objective and less subjective.
I haven't made a followup on this blog entry, and I doubt I will be doing it. However from experience and recent debate, it is important to point out that SCRUM still works in a project and in many cases fits better than XP ex: game development.

The text I wrote was partly based on the experience I got from a project, where our collaboration in the team caused SCRUM to be abused and thereby caused frustration.
There will be some of you who might be able to relate to the boss/leader aspects I write about, but that doesn't mean SCRUM is bad, it just means it was used incorrectly.


Good points. Especially the one in the beginning: "Agile and traditional development is not about using "THE" solution and fight about which one of them is best.". Many people forget this, and spend too much time looking for a perfect, almost magical solution than getting familiar with the present one. In the end, one could choose whichever method he/she prefers, if it suits him.
Personally, I believe I need a mix of agile and traditional development. If there's no strict deadline, agile is the way to go for me - but if I'm restricted in some way, some pressure is needed so that I don't let others down. I've also had a similar experience with a team where one of us was super-skilled and hard-working, but he kind of had a rocket start on his own and the rest of us was playing catch-up, without being able to contribute much.
Equally-talented and equally-engaged team members probably constitute the best team. If there's a genius in the group, the whole productivity (but experience gained as well) of the group depends mostly on the leadership values of the "genius". He can teach every team member and take them to a higher level, or he can just do his part of the job - or even the others' parts as well - and let the others figure out what to do. The question is, if you want to give this responsibility over a group to a single person, or if you're better off spreading it equally among the group members.
Oh, and one last thing - I can't believe that *efficiency* is measure by some people by lines of code - it's like measuring the technology of an airplane by its kilos :P.

Reply Good karma Bad karma+2 votes
eliasr AuthorSubscriber

In Denmark we have a single company, named Sysmatic, who covers a C-5 Ranking for "quality-cover". This ranking system requires that a lot of goals are met in analysis, design and testing; but also how the team work together and the documentation they provide.
That firm uses a mix of traditional and agile development, not because they can't decide, but because that works for them.

I do like that your reply also look at the positive sides from experienced developers. At the time I wrote this, I was one among others, who were frustrated by our genius. Later when we corrected our paper, the same person was very stubborn about some corrections. It resulted in our supervisor asking at the exam: "Where are all the arguments you had for writing this? you had them in the earlier version." also stating that it had decreased the grade of the paper.

Your points are good, but the person him/her-self must be aware of that gap and utilize it well for the team-members, so they learn instead of letting that person drag them though the mud.

This semester I'm in a group who are against scrum, basicly due to slavery(heh), but their experience caused them to rather leave all organizing behind and plan the project on "good faith".
The one who would be best suited a leader in the group doesn't want to accept the responsibility as leader, but sure wants to decide as much. Right now it mostly consist of him and I debating how it should be and two others who waits till the meeting is over.

Last semester I didn't have time due to too much work to do. Now I don't have time due to too little work being done.

I completed Sofware Enginering (the course for the article's topic) with A+ , so I assume I will be writing another article which describes "the methodologies and when nothing happens in a project" - that could be a good title, but I haven't decided it yet.

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Last Online
Denmark Denmark
Become friends
Member watch