I thought it I'd share some of my insights relating to Agile Software Development Practices:
- Motivation: Members of an Agile team need to communicate constantly. Through scrums, design sessions and pair programming. Team members that are not motivated will not communicate effectively with other members. Ensuring that the team members are positive and are able to approach one another easily is critical.
- Prototypes: As user stories get picked up by the developers they need to demonstrate their initial implementations to the business analyst who worked on the story. These demonstrations help guide the developers in the right direction and give the business analyst(or user) an idea of how the system is evolving over time. Misunderstandings get picked up quickly and resolved early. This also prevents unnecessary changes to the system further down the line.
- Focus on the critical path: A full front-end to back-end system prototype needs to be delivered as early as possible. This forces the team to focus on the user stories that form the core of the system, and helps avoid unnecessary scope creep. I don't think there has ever been a system that I was not able to break down into between 6 and 8 core stories that would break the back of the system, and provide a full end-to-end demonstration.
- Test driven development (TDD): This is a practice that many believe increases code quality and provides the team with unit tests around their core services. While this is true, test driven development is really a practice that I have rarely seen developers get right. The ones that got is right used TDD as a design tool for their Service API's, and ensured that the complex system services had the appropriate unit tests. Test driven development can also be abused by some developers who have a "code addiction" = Love writing unnecessary code.
- Administration: Administration tasks need to be minimised. Micromanagement of one's time is a real killer here. The Kanban board is great for reducing administration related to tracking progress and can be used to maximise progress transparency.
- Documentation: This is the dark horse. The truth is there are certain user stories that require documentation and some that don't. Quality over quantity is the mantra. I have seen a team use wikis very effectively to document processes, set-up and administration tasks. This effectively reduces the email trail. If the business analysts are experienced with the technology screenshots are always a very nice to have. Screenshots say a thousand words and clear up the implementation specific early. The following types of information should accompany screenshots:
- - Overall summary of what the business requirement and how the screen satisfies this requirement.
- - A small section for each control on the screen that includes the following information: What data is displayed, the format of the data, the validation rules that apply to the control.
- Extreme programming (XP): can be leveraged for the following reasons:
- - To train up junior developers on the system framework.
- - To allow senior developers the opportunity to assist one another to complete a user story.
- - To avoid silos of information in the development team.
- Spikes: This occurs when a developer picks up a story that requires some sort of investigation into the technical implementation options for completing the user story. The developer will set allocate a fixed time period with the Team lead and will spend that time investigating the various options outside the framework of the project. No developer is expected to know everything about a technology and can use these spike periods to perform the research they need to identify a feasible solution.
- Retrospective meetings: allow the team to reflect on past sprint iterations(short time periods - normally 2-3 weeks between client demonstrations) on the successes and failures of the sprint. The team is allowed to evolve and adapt the administrative and management process, thus leading to a scenario where they become 'self managed'. Another great thing about retrospective meetings is that by allowing team members to raise their gripes is that there is some form of accountability across the team.
