The Agile approach
Many software developers say that they are using Agile approach, but actually they only use it as an opportunity to skip development process and documentation so they can jump into coding. These “undisciplined developers” know that middle level managers and company owners have no idea of what Agile really is. That is why many managers told me that Agile does not work in their companies. In my study of 250 software projects in the past three years, I found that Agile is excellent for small software projects (Less than 10 people), it can helps improve quality and customers' satisfaction significantly.
The key success thing in Agile is to have a skilled and experienced project team. Agile project demand every team members to play several roles when needed from architect, design to develop and test. A programmer who only write code will not be able to use Agile successfully. Beside skilled developers, the project need good Quality Assurance (QA) who can build and execute tests, and Configuration Management (CM) who can help control the changes and build the released software product. One important key role in Agile is the Product Owner (PO). This role requires an highly experienced person to work with customers and ensure everyone on the team understands customer needs. (This role is also called as Business Analyst or Requirements Engineers in other approach) The PO must identify the right customers to ensure requirements are accurate and provide value to the company. Sometime a customer representative will be assigned to the project to act as the PO. The main job of the PO is to validate what the team is building is something that the customer actually wants.
Another key role in Agile (The Scrum method) is the Scrum Master. The Scrum Master defines the processes and practices for the project and ensures the team follows them. Another key task of Scrum Master is to remove any obstacles or roadblocks for the project. The Scrum Master also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Release Planning session. If your organization is new to Agile, it is important to include an Agile coach who has deep experienced in Agile approach to ensure the team is implementing Agile effectively. The coach also provides training to the team and make sure that they will not do any “Shortcut” or “Trick” to jump back to old habits such as “Code first, Design later”.
To make sure that the company is using Agile correctly. It is important to train both middle level managers and owner too. They must understand Agile process, roles and responsibilities of team members and trust their teams to do the work. They should attend the Sprint Review (The Scrum method) to gain a sense of progress instead of just read a status report. They must understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. Of course, they do NOT need to be an expert but at the minimum, they must understand the concept of self-organizing teams, collaboration. They need to help the PO with requirements and clarification to ensure that the team is building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the PO and avoid making promises to customers without the PO in agreement. Basically, Agile approach is NOT only for the development team but everyone within the company must understand the process and benefits of it. It takes teamwork to succeed and with Agile, the team is the entire company.
Contradict to the wrong notion about Agile that it only requires “coding skill to do it fast”, there are many rigorous Agile practices. That is why it is important to have good Agile training before adapting it for the company. Having good discipline helps with productivity and quality because the discipline ensures that everyone is focused on the work. If you hear someone says that Agile is about “Coding faster and quicker”, it is clear that they certainly have never actually done Agile but only pretend to know something about it.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
