Page 1

Thirteen lucky practices which makes agile projects Hyper productive Target audience: This white paper is indented to Scrum Master / Project Manager / coach / Champion/ Product owner.

Abstract: Thirteen may be unlucky number to many!, but it works for us. For any successful project, there need to be right project management and engineering practices. This white paper is to bring out key agile project management and engineering practices, what and how about those practices. These are based on my last six years experience in agile project management, consulting and coaching.

Key project management practices for successful Agile 1) Impediments Backlog Impediments occur on both team and organizational levels. Identify, prioritize and make them visible using the Impediment Backlog. Scrum Master creates and owns this IB – Impediment Back log and takes responsibility till closure of each item. 2) General Meeting standards One of the key lesson we learnt over the years is the time spend in unproductive meetings, to bring a precise outcome of meetings, all meetings follow a common standard. These basic rules not only increase the efficiency of the meetings but also make them more satisfying for all participants. 3) Template standardization Templates like product back log, 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 are done, which brings everyone on the same page, for eg:- scale for sizing the stories. 4) Estimation Meeting / Release planning

Product Owner and team work on the estimation of the entire Product Backlog, based on MoSCoW and which provide 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 items / user stories selected for the sprint. Product back log items are added to Sprint back log based on the team’s velocity Part 2 In the part 2, 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 each task. 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 improvements and suggestions

Key engineering practices for successful Agile

1) Set up development environment From our experience we have realized, lack of documentation on setting up the development environment is a key reason why the setup time is large. The second key reason is the number of manual steps involved in the setup process. A sprint 0, where 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

2) Automated builds We learnt, manual builds are liable to be both fragile and specific to a single machine - and time lost to making those builds work is time lost to development and testing, on 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. Key tools we used: Ant, Maven, Nant. 3) Continuous integration Form our past experience we learnt, waiting for weeks on end before we integrate code from different team members is a recipe for disaster. If you've got an automated build in place the next thing 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). Key lesson learnt is sooner that you identify integration errors the sooner you can fix them. Key tools we used: CruiseControl, CruiseControl.Net 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. Practice we learnt in a hard way is use unit-tests so that code changes do not break existing functionality. We started writing unit test cases before coding. Key tools used: Junit (and other xUnit tools such as NUnit, HTTPUnit etc), MockObjects.

5) Refactoring We practiced code ownership - in this view all code belongs to all developers, who are free to improve the code when they feel it's necessary. Over 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. Key lesson learnt is have ‘unit tests’ as safety net before refactoring the code. Key tools used: Eclipse, NetBeans, IntelliJ IDEA, Visual Studio.NET.

Development Environment Setup List of software packages to install: for Eg: Java Developer Kit (JDK), the Eclipse integrated development environment (IDE), Apache Ant, Apache Axis, and SQL Server Management Express. 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 <svnhome>/Software/Apache/Ant/1.7.0. For each package capture the system and local variables 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. How is the source code organized? How to get access to the source code repository? This section would provide 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. Setting up working copy (or local developer copy) of code from source code control. For Eg: 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 – 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 tables, views, and stored proceduresFor Eg : this section points to generated database documentation to our SQL Server 2005 database using SchemaSpy. Scripts/utilities used by developers – 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, has 10 years of experience in IT services industry, His first exposure towards agile was from Microsoft in the year 2005, from then onwards he did solutioning, coaching, consulting, teaching on agile and its flavors for many companies like GE, Cisco, Coke etc… Currently he is working as Manager in Agile Labs at Symphony Services (, 40% of projects at Symphony are in some form of Agile and its flavors, and started providing business critical value for the customer through Agile since 2004. He can be reached in

13 lucky Critical Agile practices V1.0  
13 lucky Critical Agile practices V1.0  

Target audience: Abstract: Impediments occur on both team and organizational levels. Identify, prioritize and make them visible using the Im...