Introduction
Most of us,during the development of a software system, have probably received some major changes requests from customers near the end of the project. Even worse, during a demo session, the end users as soon as see (for the first time) the final(?) product jump out of the window screaming and cursing you and your team:"This is not what I wanted. I don't like it. Get it back and bring me something else". What exactly is this "something else"? No one is able to explain it and at this point of the project being under budget/time pressures it is something extremely difficult to clarify. With a simple (greek) word: A CATASTROPHE. If you find your self smiling at this moment then at some time in the past you have been in such a position and of course, for that we usually blame this unsatisfied and indecisive creature that we call "the customer". No matter how many times you have tried to "freeze" the requirements in the early stages of the project either because you had a fixed-price contract, or because "we need to know in advance what we are going to develop", the only thing you achieve is to "lose" the customer from the beginning of the project and obviously, this is not what you would expect. So, are we really unprotected against to our customers? Of course not. Our purpose is, or at least should be, the delivery of a system that covers as many as possible, and always within budget, customer business needs. One of the agile practices I like and I believe that help towards this aim is the one i simply present (for agile dummies) in this blog.
Some simple rules and guidelines
Frequent demos for immediate feedback are extremely imporant and come to fill the gap between the development team (what is implemented) and end users (what they really want from the system).The fact that from the early stages of the project, the customer participate at regular intervals in such meetings, ensure that critical requirement changes and misunderstandings are identified as soon as possible. Thus the implementation cost is far lower than the scenario where the same change is "discovered" much later when the project would be in advance.As for each agile practice, however, frequent demos should follow some rules and guidelines in order to get the maximum of the. The following brief instructions are mainly focusing to projects where there is a single customer.
Most of us,during the development of a software system, have probably received some major changes requests from customers near the end of the project. Even worse, during a demo session, the end users as soon as see (for the first time) the final(?) product jump out of the window screaming and cursing you and your team:"This is not what I wanted. I don't like it. Get it back and bring me something else". What exactly is this "something else"? No one is able to explain it and at this point of the project being under budget/time pressures it is something extremely difficult to clarify. With a simple (greek) word: A CATASTROPHE. If you find your self smiling at this moment then at some time in the past you have been in such a position and of course, for that we usually blame this unsatisfied and indecisive creature that we call "the customer". No matter how many times you have tried to "freeze" the requirements in the early stages of the project either because you had a fixed-price contract, or because "we need to know in advance what we are going to develop", the only thing you achieve is to "lose" the customer from the beginning of the project and obviously, this is not what you would expect. So, are we really unprotected against to our customers? Of course not. Our purpose is, or at least should be, the delivery of a system that covers as many as possible, and always within budget, customer business needs. One of the agile practices I like and I believe that help towards this aim is the one i simply present (for agile dummies) in this blog.
Some simple rules and guidelines
Frequent demos for immediate feedback are extremely imporant and come to fill the gap between the development team (what is implemented) and end users (what they really want from the system).The fact that from the early stages of the project, the customer participate at regular intervals in such meetings, ensure that critical requirement changes and misunderstandings are identified as soon as possible. Thus the implementation cost is far lower than the scenario where the same change is "discovered" much later when the project would be in advance.As for each agile practice, however, frequent demos should follow some rules and guidelines in order to get the maximum of the. The following brief instructions are mainly focusing to projects where there is a single customer.
- Since the beginning of the project, therefore, describe in details the practice you intend to follow and try to explain its return of investment. Make clear that these demos have a single purpose. To understand early in the project what are the actual needs of end users and get as soon as possible feedback on the track you follow, so if something is extremely wrong you have adequate time to fix it.
- If there is some kind of dissatisfaction about the large number of releases, it is good to clarify that these are not real releases, but internal demos, which will be not available to all users. There are nevertheless valuable for the early diagnosis of requirements misunderstandings.
- Respect customers' free time. Try to find an approach that will make everyone happy. If the customer can not attend a demo at the end of each iteration (for example every two or three weeks) try to make it at the end of each month. This, IMHO, is the maximum allowed period between two demos.
- Try to ensure that you really have to show something. New features, modified or redesigned screens are essential in a demo and should work with no problems. If the customer is frustrated by a non-working demo, then it is most likely that he loses confidence in the development team and distrusts any attempt for future meetings.
- The demo should be done only by development-team members so that he/she will show the customer features that need his/her attention and feedback. Do not let the customer "play" with the release. Politely remind him the purpose of this meeting and that the demo version of the system is not suitable yet for beta testing.
- Remember to make clear before each demo that the product/system is still under development and that this is NOT what the end users will get. Try to focus on core and critical business requirements so you can get important feedback, but this does not mean that you ignore proposals for the usability, the user interface, etc.
Product vs Project
What happens though, when we do not have a single customer, but our product is targeting thousands of customers? Obviously, the frequent demo aproach seems to be unrealistic or it may be applied to a limited extent. For that reason, I propose below a couple of alternative actions that will replace this practice aiming at the same results (get early feedback).
- Try to create videos that demonstrate the new feature of the upcoming release- several days before its official announcement. Something like a pre-release announcement.The main advantage of this approach is that with minimum cost, we can briefly show (the duration of the video should not exceed 2-3 minutes), the core features for that we would like to get feedback and comments from our customers, before the new version is actually released
- Try to provide a try-it-live demo site where customers (existing and potential) are allowed to test the new upcoming version (Beta versions, Release Candidate versions) and send with a predefined way comments and feedback.
- Try to gather some of the customers (if they are located in some or nearby places) or a webinar for long distance-customers and perform a demo session instead. Although this will not have the same results as if you would showing the product in a single customer, but you may get some important feedback.
Benefits
Some of the practice's benefits are summarized right below:
- Early detection of misunderstood requirements.
- Correction of the project "path" at a very low cost.
- Continuous communication with the customer.
- Increase confidence between the development team and end users.
- Creative collaboration to achieve the same purpose (meaningful and working product)
- Most critical and core features are delivered first and complete without having to reach at the latest phases of the project.
Probably the above list is not completed, so if you have some more ideas (remember this post is for agile beginners and not experienced users) feel free to post your comments.
0 comments:
Post a Comment