When I started my study of software engineering at university, I thought the Waterfall model was such a beautiful model which would lead the team to deliver a system successfully.
There are 7 typical phases identified in Waterfall model and they are followed one by another in sequence.
1. Requirements specification
2. Design
3. Construction
4. Integration
5. Testing
6. Installation
7. Maintenance
Processing these phases one by one just like the water fall down from one stone to another and finally jump into a deep pool – so beautiful trip it is! I have believed software must be developed by following this kind of well defined methodology.
But the strong dependencies among these phases force the team and the client to draw boundary between them. The team wants to keep the requirement “stable”, so getting signature on the requirement is very important as well as the change management later. The client wants to ensure every phase has been processed very well, so putting varies of documents/codes into SOW as defined deliverables.
Does the boundary really help?
The world is changing faster and faster. Except for the information lost caused by the oral/verbal communication on requirement, no project can keep the same requirement from the start to the end.
Change Management Process? It helps from scope’s perspective but from change frequency’s perspective, it maybe not. After all, a single small change needs the effort and long time to go through whole change management process, from proposing change, estimation, getting client approval , processing the phases one by one…
After I joined Perficient and started to practice on Agile, I found the answer. Developing the most important features (from user’s perspective), the real running features and get reviewed by client iteratively. One single Iteration/Sprint should not longer than 1 month, used to be 2 or 3 weeks. During the Iteration/Sprint, the scope is a stable one – no change. But client still has the flexibility to stop the Iteration/Sprint, if they really want to change their mind from what just finalized at the beginning of the Iteration.
Yes, to apply Agile, client needs to be deeply involved. There is no boundary set between development team and client – they are collaborating. And client is happy – the features are always exactly the one they want!
You mention that you found the answer in Agile and the importance of “developing the most important features (from the user’s perspective)” etc. and that those lead to a happy client. I think you’re right in that it should lead to a happy client since the research shows that developing features with input and feedback from users periodically throughout the project improves the client’s ROI. So how do you inform the first sprint with user input? You can get an understanding of the users and their needs to feed the first sprint by conducting a “Sprint 0.” During Sprint 0 you can perform a variety of user-centered techniques, such as contextual inquiry — think “gorillas in the mist,” contextual interviews, usability testing of the previous or current solutions, and other techniques. A Sprint 0 also offers the added benefit of providing the development team with user requirements to map back to through all the sprints of the project.
Exactly. “Sprint 0” is the first Sprint used to set up the project context with stakeholders (the team, the client, the upper managers and the others), to have an overview of the Product Backlog, to set up the infrastructure (such as the Continuous Integration Environment etc), and the product release plan and so on.
Backlog grooming for Spring 1 is also in the scope of Sprint 0. But it’s not simple – most of the time, the most important feature is not the easiest to finish in the first Sprint, especially when the system architecture is not stable. Splitting the user story to fit the Sprint 1 needs varies roles (Business Analyst, Architect, the team) participating and for sure it needs well communicated from client.