Our Customer don't sit with us, Can we be Agile..

Have you heard these questions during the project execution:

• My customer don't sit with me, Can I go agile?
• What is the use of doing agile when customer cannot give feedback?
• I am doing daily standup everyday, Can I be called Agile?
• My team does Daily build , Is it Continuous Integration?, Is it Agile?
• We are doing Iteration but it is not timeboxed. But we are Agile.

I have given just a few questions that we may come across during our interactions with the team. Sometimes it looks like the focus is to be called agile by doing certain practices. Sometimes the team and the middle management dont want to change to any new process and puts across points to prove that Agile is not suitable given the dynamics.

It is loud and clear- Agile is something which we cannot do, we need to be Agile. Agilility can be practiced in every team, irrespective of whatever the constraints the team faces.

Teams must note that a collection of SCRUM , XP, Lean Software Development, Crystal, Kanban etc and the usage of these practices does not mean that a team is Agile. Agility comes from the team and individual who are working on the project. Agility is all about being sensitive and providing highest focus to customer, fast , pragmatic , practical , self organized, giving continuous attention to technical excellence, giving importance to the working software, being simple, having a constant rhythm and sustainable pace, having a motivated team, welcoming change, having mechanism of stopping and correcting. These are not some silver bullet points. These are the principles behind being Agile. Teams must understand that it is not to prove to somebody we need to go Agile. Similiarly it is not to show what environment is not available due to which Agile cannot be done. In my opinion these are some of the anti patterns which we as team members should watch for. If we see any such symptoms then we should immediatly stop and do some retrospection about the reason for being Agile.

Now answer to my question "Our Customer don't sit with us, Can we be Agile..". Well the answer is "Of course, you can be". Agililty is all about following the principles. Even if customer dont sit with us, we can get iterative feedback through the 2 weeks sprint from our test team. It can also give feedback about the way the user stories are written from the development team. It can give feedback about the architecture. And so many other feedbacks. Of course, If the customer sits with an Agile Team, it has lot of advantages. The feedback can be much faster. If there is an option available, having the customer with the project team will really help in being agile and successful. But looking into the diverse projects and situation in which different projects are executed, sometimes the customer is not available directly. In this case we can be Agile by following the iterative and incremental delivery model & related practices and improve the delivery every iteration.

References:
a) The Art of Agile Development- James Shore and Shane Warden
b) The Software Project Manager's Bridge to Agility- Michele Sliger and Stacia Broderick

Build Optimization for effective CI

In this post I would like to bring some of my observation and perspective of Build Optimization to have a very effective and good Continuous Integration System.

Build Script is all about automating the tasks required for the system development.
I have noticed that Build Scripts are not given enough priority in teams as compared to production code. In fact on a lighter note, it is seen that in the context of priority the order of priority is on these lines , production code first, test code second and build script may be last. "-:)
Some of the most commonly used build script language is Ant, Maven, Make.

The way the build is organized should depend on the following factors:
a) Module Organization
b) Where (Which Operating System ) and how it should compile, test
c) Packaging Structure

Before the build script is written the member should understand the way the system is organized, how the modules are dependent to each other. This would help in really organizing the system appropriately.

Due care should be taken to ensure that there are no unnecessary steps added without any purpose. Sometimes I have seen that some build scripts perform tasks like zipping and sending the files to some other server, unzipping & compile and bring back the file to the root server and then do certain operations. When it is closely looked it was found that these operations were really not required. These tasks add to the time taken for the building the system. This is also one of the reason why Continuous Integration System in some teams takes more time to provide the overall results.

The important point is the Build Scripts should be reviewed carefully and members writing the scripts should be well trained on the system. If it is given less attention, later it effects the complete team's performance as time taken for completing the whole build through Continuous Integration System (includes compilte, inspection , test ) is very high. And later refactoring the build scripts is a mammoth task.

Reference
1)http://en.wikipedia.org/wiki/Make_(software)