You may land up in situations when a project is almost stable. For developers handling issues and enhancements for the project, the work available is not sufficient. So, when team is comfortable with the project and it's already stabilized, team can start handling another project at the same time. It's good for the people working in these projects from learning perspective. They are exposed to multiple technology stacks, problems and functionality. At the same time, it works well for an organization in general.
(more...)

Filed under Agile, Agile Maintenance, Project Management, Scrum | 4 Comments »

When you think of inducting a new developer in existing project, it's relatively easier to do it in an Agile software development project than in a traditional project. The atmosphere and programming culture is entirely different here compared to any traditional project. Instead of people working in isolation and being responsible for assigned tasks, people here work in a mode where frequent communication across table is necessary. Instead of one person being responsible for assigned tasks, the whole team is responsible to complete it.

The mantra is efficient communication and more interactions. So when a new developer enters the Agile project (Scrum + XP based), pair programming, communication across the table makes a person comfortable with the new project environment. Instead of going through bulk of developer's handbook and design document, conversations help to bridge the gap. However when you need to really need to refer some documentation, it's always there. Also new developer continues to develop on top of whatever existing team has built on. So you see, knowledge transfer is seamless and relatively easier compared to any traditional project.

(more...)

Filed under Agile, Agile Maintenance, Java, Multimedia, Scrum | 8 Comments »

When you think about documentation in Agile software development, most of the times it talks about "just enough" which definitely makes sense considering the thickness of design documents in traditional software development. The Agile mind specifically thinks what actually is required in terms of documentation.

Agile software development also gets translated into efficient communication, collocation and sitting in one room or same table and having conversations whenever there are issues. Some of the XP practices like pair-programming helps a new joinee to come upto the speed when she joins the project.

When you talk about effective communication and resolving issues in a team as and when they arrive, you lead towards a situation in which knowledge resides in the heads. People may not feel the need of documenting in detail as they seem to know everything about the project. You may end up in a situation where a new team doesn't have "enough" documentation to begin with in maintenance phase. That's why when one talks about "just enough documentation", that "enough" word needs to be quantified.

(more...)

Filed under Agile, Agile Maintenance, Java, Multimedia | 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...)

Tags: agile documentation
Filed under Agile, Multimedia, Project Management, Quality Assurance | 1 Comment »

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 »

These days a lot of big organizations are spending a good amount of money on making their websites more usable. And you may want to know why?

Think about a Fortune 50 organization (with around 100 thousands employee strength) which has many web applications working across the organization. It may have intranet applications, some business applications etc to facilitate business in effective way. These organizations spend a lot of money on IT spending and generally require many new applications every quarter. Now think about a case where all these new web based applications are different in their look and feel (navigation, fonts, colors etc) from each other.
(more...)

Filed under Java, Usability | 1 Comment »