As more companies embrace Agile in software development, ISS lecturer Michael Tan reveals five good practices that can improve your agile project.
Agile methodologies offer an alternative approach to conventional project management. As more companies embrace Agile development like Scrum and Extreme programming to implement their software application systems, here are five considerations that can improve project management.
1) Educate everyone involved
Before adopting Agile, everyone, including the project team, users and managers involved should understand what it entails and what is expected of them in their respective roles. There should also be a briefing session for the senior management on the type and level of support required to implement Agile effectively.
2) Engage the users
The next step is user engagement. The users have to be readily available to provide inputs to the project team. An important component of Agile development is regular communication – lots of it. Multiple short and personal sessions instead of lengthy group workshops are needed to constantly evolve the requirement. Because of this, users have to set aside time to meet with the project team. One way to free up users’ time is to hire temporary staff to relieve users of their usually heavy workload.
3) Have a documentation strategy
One of Agile’s manifestoes, “Working Software over Comprehensive Documentation”, leads to the common myth that Agile requires no documentation. Without documentation, there can be no organisational memory. Instead, what Agile advocates is a better way of writing documentation. For example, if a piece of information is only used for guiding future work, it should be kept temporary and discarded once the work is completed, much like the scaffolding in the construction of a building. However, if a piece of information is needed for future reference, then it should be kept permanent. An example would be the maintenance manual of a system, without which, the maintenance engineer might not be able to do his work effectively.
4) Writing User Stories
User Stories are a popular way of capturing requirements in Agile methodologies. This is a brief description of requirements from the user’s perspective, like the following:
“As a <user’s role, e.g. approving officer>,
I want <a list of requirements, e.g. easy access and viewing of all my projects>
so that <clear benefit of each requirement, e.g. I can process orders faster>.”
User Stories contain information on ‘who’ (As a…), ‘what’ (I want…) and ‘why’ (so that…). The ‘who’ and ‘what’ provides information on the requirements while the ‘why’ provides the reason for the requirement. With such information, the development team might be able to change the ‘what’ as long as the ‘why’ remains the same. An example would be “As a user I want to be able to reset my password easily so that I can still use the system if I forget my password.” A developer might still be able to satisfy the requirement without implementing the password reset function if the developer is able to make sure that the user does not forget his password.
While the format is useful, you do not have to follow it dogmatically. For requirements that are common practice or common sense, say, the unique user log in for security and accountability, the ‘so that’ section can be dropped to reduce cluttering the documentation. We should be agile after all!
It is also useful to write the User Stories on index cards or sticky notes so that the development team can refer to them easily. Some teams have found it easier to maintain the stories using spreadsheets, although that could sometimes be hard for referencing.
5) The Product Owner Role
Traditionally, the project team engages with different stakeholders such as senior executives and end users directly to elicit requirements. However, different stakeholders might have their differences and it is left to the project team to facilitate its resolution, even though they might not be the best party to do it. The product owner thus is someone with the vision and authority, and is available to provide the right requirement. However, when an ideal product owner is not available, implement a process so that decisions about requirements can still be obtained efficiently. An example would be to pair a product manager and a business analyst. A product manager has the authority and vision about a product, but is usually too occupied with his work, while a business analyst is usually available and is able to facilitate an agreement on the requirements.
All said, part of being Agile is to be adaptable and flexible. Each Agile team will be different from another. Make good use of best practices and common sense to design simple processes that work for your team and help to keep track of the requirements as they build up.
This article is first published in NUS-ISS quarterly e-newsletter, Issue 5 (Jan-Mar 2014).