This paper brings out the uniqueness involved in Agile Scrum projects, and identifies the traits required for a successful team. The paper concludes with recommendation of interventions required for effective scrum team.
Engineering uniqueness of agile projects
There are several things which cause an agile project to be different from projects based upon more traditional approaches, including:
- Setting up the development environment
In a traditional project, the team can spend sufficient time in setting up the environment; in case of agile teams, they need to be productive form the first hour. From our experience, we have realized that 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. In sprint 0, we must 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.
- Automated builds
Let us fail early! We have learned that 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 that, 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’ve used include Ant, Maven and Nant.
- Continuous integration
Form our past experience we have learned that 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). A key lesson learned is, the sooner that you identify integration errors the sooner you can fix them. Key tools we’ve used include CruiseControl, CruiseControl.Net and Bamboo.
- 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. A practice (which we learned the hard way) is to use unit tests so that code changes do not break existing functionality. We also started writing unit test cases before coding. Key tools we’ve used include JUnit (and other xUnit tools such as NUnit, HTTPUnit, etc) and MockObjects.
- Refactoring
In a traditional environment, normally an individual protects their codebase until integration, but in agile we practice 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 a period of time, our code base started behaving strangely - the solution to this was refactoring (thanks to Martin Fowler who popularized the term refactoring in his book of the same name). Refactoring essentially boils down to code changes which improve the structure and clarity of the code without necessarily changing the functionality. A key lesson learned was to have unit tests as a safety net before refactoring the code, and some key tools used include Eclipse, NetBeans, IntelliJ IDEA and Visual Studio.NET.
As it is clearly evident there are certain unique things in agile projects engineering practices, so the teams need to be prepared for and oriented towards these practices.
Behavioral traits required to work in agile teams
As agile teams work differently from normal teams and depends a lot on effective and efficient communication and fast execution, there is an increased need to use soft skills. If we are aware of this and actively encourage the use of some of these traits and skills, we can make agile teams more meaningful and productive.
Self-organization usually relies on basic ingredients like Positive feedback, Negative feedback, Balance of exploitation and exploration, and multiple interactions. From our experience, a team may fail to give the right kind of feedback and shy away from interaction because of many cultural and social issues.
From my experience, this remains a ‘myth’. Always we tend to have ‘predictability syndrome’ - the more planning we do the more predictable we will be.
The team needs to have good discipline, the ability to take responsibility, be committed, and take accountability and ownership.
One of the key skills that the team needs to have is the ability to ask for help and to seek out review. In certain cases we had seen the ‘ego’ factoring out as a major impediment.
Taking responsibility, being committed, and a spirit of collaboration are sometimes taken for granted; however from our experience we sometimes need external interventions to make these happen.
Certain key skills which we normally tend ignore are the ability to take initiative, enjoying working in an intense environment and adapting to new situations and frameworks easily.
Most of our projects are distributed, meaning there will be a co-development scrum between client and the service provider. In these contexts, skills like managing diversity, time management, diplomacy and leadership are very essential.
Success ‘Mantra’ for agile teams
For any agile projects to be successful and hyper-productive, the team needs to show more enthusiasm and the right attitude towards ,learning from peers in spite of seniority and expertise. A safety net for fearless expression needs to be ensured so that real camaraderie can be exhibited, which in turn will increase focus on the goals of the team rather than ‘what is in it for me’?
Conclusion
From my experience and observations, the skills required to be hyper-productive in an agile project are different from those required by a traditional one. We have identified behavioral and technical skills required for a team to have that edge. Anyone who acquires these ‘delta’ traits will be equipped with the right set of behavioral and technical skills, which enable them to work effectively in an agile project. The summary of the skills are represented in the table below.
Skill table
|
Role |
Technical skills ( in respective platforms) |
Behavioral skills |
|
Developer |
CRUD operations, interfacing with different layers of the development frame work. Unit testing (tools – NUnit, JUnit ) Code coverage concepts and tools Code review concepts and tools Continuous integration tools Refactoring concepts Code-smell concepts Scrum process |
Communication Collaboration Time Management/ Planning Thinking Conflict Management Dealing with Change/ Flexibility Decision making Teamwork/ Teambuilding Handling stress Problem Solving Leadership Diplomacy |
|
QA |
Definition of done -> acceptance criteria Test management Automation / scripting Environment setup Database concepts |
Same as developer |
|
Scrum Master |
Scrum process Templates and usage Project Management tools Continuous integration tools Development environment setup |
Developer skills + facilitation |
About the Author
Prasad, has 10 years of experience in the IT services industry, His first exposure towards agile was from a Microsoft project in 2005; from then onwards he did solutions development, coaching, consulting, and teaching on agile and its flavors for many companies like GE, Cisco, Coke etc. Currently he is working as a 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 at pprabhak@symphonsysv.com