Scrum Gathering 2015

I had a chance to attend the first Scrum Gathering 2015 in Vietnam. It was the first time of many things – more detail later. The event was about Agile/Scrum. Therefore, before I talk about my personal impression and feeling, you should clearly state about my background of Agile/Scrum:

NOT MUCH

I have been coding for long time and have been reading and applying (kind of) for quite a while. However, I am not applying Agile/Scrum as the scrum materials.

And I was not going to the event to learn Agile/Scrum either. I went because:

  1. It was an international event, speakers are well known – or at least I heard about them
  2. I have not ever been in any community conference
  3. Mind open: See how they are doing out there
  4. Meet new people

So, what did i feel? I felt good (event I had sickness that day 🙁 ). I felt involved. I met people from different countries, with different job titles. They were talking a lot about agile, about scrum, about processes, … They are truly professional. And I felt “LOST” in the beginning. I did not know how and where to get started. However, very quickly the community atmosphere helped me get started

Hey, man, you are here for a reason. Let’s open and talk to people

And I started to talk. Things just kept going as it should be.

However, there was one problem:

I do not know what to ask speaker

That was when I realized that I have many things to learn. I might write more about that in some later posts.

Next are some of the thoughts i had during the event, especially when people asked speaker of how to solve this issue, that issue, …

I started to think: Hey, wait a second! They focus a lot on this phase: Scrum welcomes changes. So they expect scrum to give them the tool to deal with changes from client/customer. And we also have the same philosophy in coding. We are as developer/architect told to design/code in such a way that: you can deal with requirement changes easily or less costly.

No one mentioned about that in the event 🙁 And when i mentioned about that in the discussion. They seems to ignore that, and show the gesture that: Yeah, we know and just move on with their discussion.

Everything comes to code, btw 🙂

PS: I had many things in my head after the event. However, the Mr. Bacteria knocked me down. Therefore, those are information that left in my head. I want to write them down before they’ve gone 😛

PS2: I will join this event next year for sure 🙂

Do we need technical design?

Recently, the trend is for XP ( Extreme Programming) and Agile management with Sprint/Scrum, so do we still need technical design for a project?

The purpose of Agile developement is to supply the deliverable product sustainably and XP helps team accomplish the goal. Over the internet, we have found many principles, tips, best practises about coding, how to make a better code. However, noone talks about good technical design. In fact, none exists.

With the agile developement, the project is splitted up into small tasks. Each has acceptance test and customer relation. And most important, the customer is involved and the delivered product satisfy customer and we are ready for the change from them.

Now, let’s assume that we have all stories need to implement in one sprint. And the whole team will discuss how to do it. The question is how to make the technical design for those stories? and does it make sence to make the design for only those parts and the next sprint will continue next parts? I think NO.

Someone will say YES. Then i assume that you have made the technical design for those parts. Then come to the coding. Click here to see XP Practice . In summary it says:

  1. Write unit test and acceptance test, if you follow TDD.
  2. Write code to pass those test
  3. Refactoring code, of course make sure the tests are green.

And how can we refect the refactoring in Technical Design? So still say NO to technical design.

And consider time you spend on that

Someone will say: It keeps the thing we did in case when new comer want to get a preference. Do you really use the technical design to get understanding about the code or you will look directly into the code? if the code wrote 1 year ago and now you come in, what will you do in order to understand it? You only do this if the code has never been refacted.

My conclusion is that: If you are in XP and Agile development, you DO NOT need technical design. Instead of spending time on making the technical design, you should spend time on learning OOP principles, best practices. Then the code will explain itself.

Oobs, Are you throwing technical design away or is it useless? NO. We should consider it as a general documents of the project not the technical thing in detail.