Agile Development blog - eliasr

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.

-THE HOUND OF THE BASKERVILLES, Sherlock Holmes
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.

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.

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)

Commitment

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.

Update:30-08-2014
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.