Issuu on Google+

The Magazine for Agile Developers and Agile Testers

July 2011 free digital version Š

made in Germany

ISSN 2191-1320

issue 7

© / H-Gall

Thirteen lucky practices which make Agile projectshyper productive by Prasad Prabhakaran

Thirteen may be an unlucky number to many, but it works for us. For any successful project, the project management and the engineering practices must be right. This article will describe key Agile project management and engineering practices. These are based on my last 6 years’ experience in Agile project management, consulting and coaching. Key project management practices for successful Agile projects

1. Impediments backlog Impediments occur at both team and organizational levels. Identify, prioritize and make them visible using the Impediment Backlog (IB). The Scrum Master creates and owns this IB and is responsible until each item is closed. 2. General meeting standards One of the key lessons we learnt over the years is that a lot of time can be spent in unproductive meetings. To achieve a precise outcome of meetings, all meetings should follow a common standard. Some basic rules help to not only increase the efficiency of the meetings, but also make them more satisfying for all participants. 3. Template standardization Templates like product backlog, sprint backlog, impediment backlog, burnout chart, estimation standardization are standardized and communicated to the team. A norming session for the team on the templates and standards is helpful as it brings everyone on the same page, for example scale for sizing the stories. 4. Estimation meeting / release planning The Product Owner and team work on the estimation of the entire Product Backlog, based on MoSCoW and this provides the basis for release and sprint planning.

5. Sprint planning Part 1 The team and the Product Owner define the Sprint goal and the done criteria for each item / user story selected for the sprint. The product backlog items are added to the Sprint backlog based on the team’s velocity. Part 2 In part 2 of the sprint planning meeting, the team works on the selected product backlog by adding engineering tasks to each backlog item. Each team member takes ownership for a specific task(s). 6. Daily Scrum meeting The Daily Scrum Meeting helps the team to organize itself. It is a synchronization meeting between the team members. It takes place every day at the same time, at the same place. The meeting is time-boxed to 15 minutes. 7. Sprint review meeting The status of the project is controlled by reviewing the working functionality. The Product Owner decides if the delivered functionality meets the Sprint goal. 8. Retrospective meeting “Inspect and adapt” is a fundamental part of Agile. During the Retrospective the team analyzes the previous Sprint to identify success stories and impediments. Key discussion is around what went right, areas of improvement and suggestions. Key engineering practices for successful Agile projects 1. Set up development environment From our experience we have realized that a lack of documentation on setting up the development environment is a key reason


why the set-up time is long. The second key reason is the number of manual steps involved in the set-up process. At sprint 0 we document every little thing that a developer needs to do in order to start writing code and integrating with the rest of the team’s work. Here are the points to ponder.

For each package include location (network drive/Internet/ Intranet/other) and credentials necessary. E.g. for Apache Ant, the location would be our subversion repository. The relative path is specified from subversion working copy folder - <svn-home>/Software/Apache/Ant/1.7.0.

2. Automated builds We learnt that manual builds are liable to be both fragile and specific to a single machine, and time spent on making those builds work is time lost to development and testing. For anything but the smallest projects, having an automated build process is essential. We realized, even if you have to take time out to create an automated build environment, it’s time you’ll get back later. It also makes it simpler to ensure that we have a standardized build that everyone on a project can share. The key tools we used were Ant, Maven, Nant.

For each package capture the system and local variables that need to be configured on a machine. For instance, Ant requires the ANT_HOME variable and Axis2 requires the AXIS2_HOME environment variables to be set with values pointing to the folder structure on the development machine.

List of additional libraries to obtain; these include any Java archives (JARs), or .NET DLL files, or others. An example of such a library would be Java database connectivity (JDBC), JARs for accessing Microsoft SQL Server 2005, or JARs for working with IBM Websphere MQ.

How to get user access to queue manager, database server, and remote machines – contact person as well as link to relevant procedures and forms. Details such as application credentials in the development environment or user specific credential forms can be specified here. For instance, I specify an email template with login user name, our team’s application identifier, and a contact person name to be sent to our middleware support group for access to the queue manager.

4. Unit testing In a highly fluid environment with multiple developers, shifting requirements and changing priorities it’s essential to ensure that what worked yesterday works today. We also had challenges with integration errors. In practice, what we learnt the hard way is to use unit tests so that code changes do not break existing functionality. We started writing unit test cases before coding. The key tools we used were JUnit (and other xUnit tools such as NUnit, HTTPUnit, etc.), MockObjects.

How is the source code organized? How to get access to the source code repository? This section provides a summary of the code organization. For example, I organize code based on data domain (customer data, account data, document data) as well as core reusable utilities (e.g. logger, router, exception handler, notifications manager, etc.). This section also provides the location to the subversion trunk as well as additional instructions on getting write access to the repository.

5. Refactoring We practiced code ownership. In this conecpt all code belongs to all developers, who are free to improve the code when they feel it’s necessary. Over a period of time, our code base started behaving strangely. Thanks to Martin Fowler, who popularized the term “refactoring” in his book of the same name. It essentially boils down to code changes which improve the structure and clarity of the code without necessarily changing the functionality. The key lesson learnt is have unit tests as a safety net before refactoring the code. The key tools we used were Eclipse, NetBeans, IntelliJ IDEA, Visual Studio.NET.

Setting up working copy (or local developer copy) of code from source code control. For example: provide instructions on working copy location based on our enterprise desktop policies. For instance, a particular folder has write access, while users don’t have rights on other folders.

Location of key files, such as application log files, error files, server trace logs, thread dumps. Examples in this section include file path location to the Tomcat servlet container log and Websphere MQ bindings files.

Browsing queues and procedure for adding queues. This section will point out the salient# queues that a developer should be aware of in our queue manager. It will also provide naming conventions as well as support information for creating new queues.

Browsing tables and creating database objects such as ta-

3. Continuous integration Form our past experience we learnt that waiting for weeks on end before integrating code from different team members is a recipe for disaster. Once you’ve got an automated build in place, the next thing to do is to go for continuous integration. Of course, an automated build and continuous integration environment pre-supposes version control (or software configuration management, to give it a more formal and impressive name). The key lesson learnt is that the sooner you identify integration errors, the sooner you can fix them. The key tools we used were CruiseControl, CruiseControl.Net.

Development Environment Set-up • List of software packages to install: e.g., Java Developer Kit (JDK), the Eclipse integrated development environment (IDE), Apache Ant, Apache Axis, and SQL Server Management Express.


bles, views, and stored procedures. For example, this section results in generated database documentation on our SQL Server 2005 database using SchemaSpy. â&#x20AC;˘

Scripts/utilities used by developers, i.e. developer tools that automate routine tasks. Examples here include Apache Ant scripts that compile and execute JUnit test suites, as well as those that generate Javadocs based on Java source code.

> About the author Prasad Prabhakaran has 10 years of experience in the IT services industry. His first exposure to Agile was from Microsoft in the year 2005. From then onwards he has done solutioning, coaching, consulting and teaching of Agile and its flavors for many companies, such as GE, Cisco, Coke etcâ&#x20AC;Ś Currently, he is working as Program Manager at Symphony Services ( Forty percent of projects at Symphony are in some form of Agile. The company has provided business critical value for customers through Agile since 2004. Prasad can be reached in

Your Ad here