Xebia Blog

Last week Gero Vermaas explained the Incorrectly Applied CDM en this week we’ll continue with #3 - Missing skills

Just like any other paradigm, a level of new knowledge and experience is required. Unfortunately, SOA requires lots of new knowledge and experience. It requires a different way of thinking of more or less everyone involved. People are used to closed environments on both organisational and technical level; largely well protected from influences and unwanted dependencies with the outside world. It's all in their area of influence which makes achieving short term results relatively easy. I'm referring to silo applications where the world is complicated enough. From their view, SOA makes things even more complex. There should be awareness that there is lack of knowledge, experience and attitude and something should be done about this first. There is no real solution, except for the obvious one: educate everyone involved. Also, agile methodologies have proven to be effective in building up knowledge and experience.
(more...)

Filed under: Agile, Architecture, SOA
4 Comments

Saturday 17/05/08: Six hours of journey after starting early (very early) in the morning is not that awful when you are looking forward to attend some kind of a "First….".This adds some extra enthusiasm!!

We were three, Saket and Rupal being the other two. Apart from participating we were also embodied the task to propagate Xebia's learnings and experiences as one of the front-runners to imbibe Agile.

A small, but an all charged up audience of some 25 odd people were just enough for that (even smaller) Conference Room at CYP Asia Center hosting the "First" Agile Workshop in Chandigarh. Developers, project managers and even some entrepreneurs formed the lot. Its amazing how Agile is stirring up everyone and was good to see an all inquisitive bunch of people. (more...)

Filed under: Agile
No Comments

Last week we discussed #6 - which means we've now passed the halfway point of SOA Pitfall countdown! Let's quickly move on to #5.

Like the Not Invented Here syndrome we discussed earlier, Big Design Up Front (BDUF) is something not only witnessed within the realm of SOA. However, where the NIH syndrome is generally accepted to be a bad thing, things are not that simple when it comes to BDUF.

(more...)

Filed under: Agile, Architecture, SOA
2 Comments

For a training on Scrum and Agile I was planning to give I was looking for games to play during the course to explain some basic things. Ofcourse we would be playing the XP game but I wanted something more to explain some other fundamentals.

One of the games I found interesting during my own trainings was Goldratt’s dice game. For the training I was preparing an adjusted version of Goldratt’s dice game. As you might know Goldratt’s dice game illustrates the effects on variation in processes and its effects on cycle time. You can find a simulation of it at http://www.ganesha.org/leading/toc.html.

Next to that I wanted to have another game to illustrate the effects of having large inventory and the difference between push and pull production. After a few minutes searching the web I found the CUPS game. (http://web.lemoyne.edu/~wright/cups.htm).

The Cups game is about the difference between push and pull production. It helps you illustrate its effects on inventory, costs, rework and ability to respond to change. One of the main things of being Agile is of course your ability to react to change and generate feedback, see http://cesarioramos.wordpress.com/2008/03/23/improper-feedback/.

I found that the outcomes of these games are easily related back to Lean and Scrum principles and that they can be used to have some fun and easily explain things during training.

How does Scrum relate to Goldratt’s dice game?
Using Goldratt’s game you illustrate that in order to maximize throughput you should minimize variation in processes. Scrum helps you achieve this by minimizing disruptions of work and achieving a sustainable pace throughout the project!. See also http://jeffsutherland.com/scrum/2007/07/origins-of-scrum.html

How does Scrum relate to the CUPS game?
The CUPS game helps you illustrate that we should limit work to capacity and keep inventory low if we want to be agile and effective. If not, your cycle time will go up and as a result your agility down! Scrum offers a way to limit work to capacity through its sprint planning. We know that during sprint planning the amount of selected work should be based on the team’s capacity.

There is also Little’s Law stating that WorkInProgress (WIP) = CycleTime (CT) * ThroughPut (TP). So to be able to respond quickly to change you should minimize the CT. We know that one way to achieve that is to minimize WIP. For a Scrum project you could say that the WIP is equal to the Sprint Backlog and the number of Product Backlog stories that are worked out in detail. So what is the minimum WIP that you should use? Again Scrum has some simple principles to help out. One of them being that we should focus on the top product backlog user stories the next sprint. So working on these and detailing them before the next sprint planning takes place is a good idea. How much work should be detailed? well... at least the team’s current capacity! I prefer to use the plan, do, check, adapt cycle. So I would first see how it goes with a WIP of about 2 times (sprint backlog and detailed stories on the product backlog) the team's capacity and then take it from there.

If you want to have some extra fun during the CUPS game you could do so by changing requirements during the process.

Have fun!

Filed under: Agile
No Comments

For some years now I have been working as a tester in agile projects. In our projects we are trying out new ways to integrate testing into the development cycle and ideally to offer a complete project solution to our customers. In my vision the perfect offering would be to create working software with each development cycle, which has the actual ‘Done’ status. Not only ‘Done’ from a development point of view, but actually ‘Done’ from the customer perspective as well.
(more...)

Filed under: Agile, Scrum, Testing
No Comments

As you enter into Agile world, a statement welcomes you - "Just do enough documentation". For quite sometime, I was puzzled what we really mean by this. In my view "just-enough" is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing "not just-enough documentation" (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.

What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.

(more...)

Filed under: Agile, Multimedia, Project Management, Quality Assurance
No Comments

Sometimes back there was an interesting debate between Agile manifesto founder member Bob Martin and renowned Jim Coplien about the relevance of good design principles in TDD based development.

Jim had very thought provoking views about what people do in the name of TDD and when it leads to something where it's just impossible to do any kind of refactoring further as there was no overall sound design/architecture base.

It leads to following questions:

• While practicing TDD and Scrum, is it really possible to focus on a good design considering we just focus on the prioritized list of requirements and don’t really see their interactions with other user stories to begin with?
• Without having a big picture in shape of logical diagram, class diagrams (read UML), deployment diagrams, is it really possible to create a good architecture/design? May be it’s possible in small scale projects where the level of complexity in terms of business logic is not too high. But the question is more relevant for big projects (1-2 million LOC).

There were some interesting follow up in this respect from various people in Xebia. I thought it'll be a good idea to combine all those thoughts through this blog.

(more...)

Filed under: Agile, Architecture, TDD
No Comments

According to CATB, the act of shaving a Yak is "Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on.".

The first time I read about the term was on this blog, but that was a long time ago. I was only recently that I noticed that a) I was doing it again, and b) some of my collegues where unfamiliar with the term. Therefor, I decided to (also) blog about it.
(more...)

Filed under: Agile
2 Comments