Information and Methods DSDM Atern (2) tutorial (Trần Xuân Trường)

2. A number of problems (4 in total) could have had a major impact upon the tight delivery deadlines. What were these problems? How did the project team use DSDM to help overcome these problems?

Answer :

According case-study, these problems are :

1. The diverse range of stakeholders presented major challenges.Not only were there 12 of them, drawn from both the public and the private sector, but they had very different ways of working and perceptions of risk.
2. The project was impacted by a major office move and complete change of team by one of the key project stakeholders around the time the system was due to go live.
3. Resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project had to be overcome.
4. The requirements for a major part of the system were more complex than first thought and were changing as part of the review of the regulations.

As we know DSDM Atern principles 3 "Collaborate" encourages increased understanding, greater speed and shared ownership which enable teams to perform at a level that exceeds the sum of their parts. With problem 1, It's help the project team DSDM’s focus on collaboration, facilitation and stakeholder engagement helped ensure that everyone worked together and any issues were dealt with quickly.

With problem 2, the project team follow DSDM Atern principles 6 "Develop Iteratively" to help them to cope with changing requirements and personnel.Change is inevitable, It's allows for change and harnesses its benefits. Within the constraints of time and cost, change is actively encouraged in order to evolve the most appropriate solution. Atern uses iteration and constant review to make sure that what is being developed is what the business really needs.

The project team need to deliver the project on time however DSDM presented cultural difficulties for one of the key stakeholders, The project team intergrate DSDM Atern into an existing Prince2 Environment in order to help them to quickly establish or enable their own agile capability and overcome resistance to the ‘iterative’ and ‘appropriate level of rigour’ approach of DSDM for the project.

And final problem, The project team realised that the only sensible time for this to go live was 1st September, at the time only 3 months away. So with DSDM Atern principles 1 "Focus on the business need", it's help them to overriding project goal, which is to deliver what the business needs it to deliver, when it needs to be delivered by using MoSCoW prioritisation. Using this techniques it became clear that this functionality was a ‘should have’ rather than ‘must have’ for delivery and so was re-scheduled for the following year.

DSDM Atern – tutorial 1 (Trần Xuân Trường)

2. Principle 2: Deliver on time

In order to fulfil on-time delivery principle Atern teams need to : 

• ·         Use timebox approach
• ·         Focus on business priorities
• ·         Always hit deadlines.

Timeboxing the work of projects is a powerful practice which truly helps facilitate on-time delivery. A timebox is a fixed period of time at the end of which one or more deliverables have been completed. What we are focusing on here is the completion of deliverables by the exact deadlines and a timebox is only successfully achieved by then. Timeboxing takes advantages of iterative development approach as it breaks down the project into small fixed periods of time, usually two and four weeks which is a reasonable time span for development team to meet the objective of that timebox. Longer timeboxes, say 6 weeks, usually would cause the team to lose focus and it is logical and common sense that short timeboxes always push development team into hard working mode to fulfil the requirements agreed on at the beginning of the timebox.

On top of that, there is this Daily Standup part in all timeboxes in which development team together shares information on what each member has been doing to achieve the timebox’s objective and what he  will be doing till the next standup , as well as any problems he has been having that prevents him or the team from achieving the objective. Daily Standups would help identify problems earlier, so that the development team can fix them in early stage, save time and do not miss the deadlines.

DSDM pratice uses MoSCoW prioritisation for business priorities, which also help keep product deliveries on time.  As stated in the MoSCoW rules, the total effort invested in Must Haves should not above 60%, so it makes sure that development team can at least guarantee to deliver those Must Haves and present a usable product on time. Even if the team do both Must Haves and Should Haves, the total effort is still no more than 80%. We only use 80% of the development time to bring out a fine usable product, therefore we definitely deliver the product on time.

In conclustion, the combination of timeboxing and reasonable MoSCoW prioritisation allows the development team to predict the time of deliveries and always hit deadlines.

DSDM Atern – tutorial 1 (Nguyễn Quang Hiệp & Nguyễn Năng Chung)

Focus on the Business need

Explain what is meant by the term ‘Business case’. Why is the business case so important when delivering a system within a Rapid Application Development environment?

The term "Business case" is really means the business proposal. It helps us know about project overview, strategic goal, current situation and problem, critical assumption and constraints, analysis of option and recommendation, preliminary project requirement, potential risk of the project. When we have project description with strategic goal and we can confirm time to do project, functions, technology will use and give requirements for each group the project will very clear."Business case" giving exactly all of the elements need when we do the project. Projects requirement clear, easy to divide small project, know how much resources to divide group to do project. "Business case" is necessary and important when delivering a system within a rapid application development environment.

Tutorial 3: MoSCoW rules (Hoang Tuan Long and Vuong Tan)

Question 2. MoSCoW rules

a. Using the MoSCoW rules discussed in class, prioritise the above requirements into one of the four categories.

1.      Customer database – customer data entry, querying and updating

2.      Quotation database – data entry, querying and updating of premiums

3.      Quotation screens – enabling telesales staff to quote prices to customers

4.      Phone acceptance of insurance policy (and ensuing processes)

5.      Printing of insurance certificates and insurance schedules

6.      Automatic printing of renewal reminders

7.      Phone acceptance of renewals

8.      Automatic printing of payment reminders

9.      Phone acceptance of payment via credit/debit cards

10. Management reports detailing daily/weekly/monthly premium sales

11. Management reports detailing new customer business v. existing customer renewal

12. Management reports profiling customer type/motor vehicle type/type of insurance

13. Automatic back-up of database on a transaction-by-transaction basis

14. Telesales security system with graded access to system functionality

MoSCoW prioritization

Must	Should	Could	Won’t
1,2,3,4	5, 7, 9, 13	6, 8, 10	11, 12, 14

The requirements 1, 2, 3, 4 must be MUST HAVEs. Obviously, customer and quotation are the two objects this telesales system is all about, therefore customer and quotation datababase is very crucial to the main operation. On top of that, the core business requirements of this system are to enable the telesales staff to quote prices to customers and for customers to accept the insurance policy, which is why requirements 3, 4 belong to the MUST HAVE. There is no point in implementing a telesales system which does not meet these requirements.

The SHOULD HAVEs of the system are 5, 7, 9, 13, because the system can work without them (the telesales still can quote prices to customers and customers still can accept the insurance policy by phone) and moreover these requirements really affect the business case. The phone acceptance of renewals or the phone acceptance of payment via credit/debit cards are the absolutely necessary functionalities for customers if they want to renew their insurance or make payment, so why are they not in MUST HAVE? It is because this system is urgent as the scenario describes; the renewals will not happen in couple of months, and there are many other ways to make payment, so they can wait.

The requierements 6, 8, 10 belong to COULD HAVEs, simply because they don’t really affect the business case here. The management reports detailing daily/weekly/monthly premium sales kinda help figure out good and bad points of the current sales activities, thus the system could have this function. We can say that these requirements are additional features it is nicer to have them.

Finally, there are requirements 11, 12, 14 in the WON’T HAVEs. These requirements have very little business value and the system does work really fine without them.

b.  Do you think the MoSCoW rules are an effective way of prioritising functionality?  What problems (if any) do you perceive with using this approach?

I think MoSCoW rules are an effective way of prioritising functionalities because:

·        They help indentify the functionalities which bring the most business value.

·        They help indentify the most important functionalities earlier, so developers can do them first.

·        They help indentify the functionalities which bring less business value, so developers can consider doing them later or not at all.

·        They help reduce confusion of different options from stakeholders because they force all the relevant stakeholders (customer, product owner, project sponsor and users) to be in one place to talk through their different options on what to be done and eventually reach the final agreement of prioritization.

However, we may encounter the problem of not being able to balance the 60% effort for MUST HAVEs and the other 40% for SHOULDs and COULDs. Once the requirements are placed in the MUST HAVE category, it is likely that the efforts invested in these requirements are too many and enough to take up almost all the project time. Eventually, the MUST HAVE functionalities are delivered perfectly, but maybe there are no functionalities coming from SHOULD or COULD HAVEs. This means we only bring out a system that works, not stably and beautifully works. Furthermore, this technique is supposed to prioritize functionalities, not removing them off the list like that. In conclusion, it is recommended that no more than 60% effort for MUST HAVEs for a project, with 40% SHOULDs and COULDs. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.

Rapid Application Development (Nguyễn Năng Chung - Nguyễn Quang Hiệp)

3.         Timeboxes

Give a simple definition of a timebox. Explain how a timebox enables an iterative and incremental approach to delivery.

Timeboxing Models: 

Answer : 

a) Definition :Timebox is a technique for organizing software delivery and it can be used for planning or scheduling. It refers to the act of putting strict time boundaries around an action or activity.

  

_Another definition :(http://tynerblain.com/blog/2006/04/12/how-to-use-timeboxes-for-scheduling-software-delivery/)

  A timebox is a fixed unit of development capacity. An easy way to visualize a timebox is as a two-dimensional graph. Along the vertical axis is the cost of the development team (per unit time). Along the horizontal axis is time. The longer an iteration is, the wider a timebox is.

The important thing to notice is that with Cost and Time fixed, the capacity of the timebox is fixed. There is only so much that can be accomplished with a given team and a given amount of time.

b) how a timebox enables an iterative and incremental approach to delivery :

In the timeboxing model, the development is done in a series of fixed duration time boxes – the functionality to be developed in an iteration is selected in a manner that it can “fit” into the time box. Each time box is divided into a sequence of fixed duration stages, with a dedicated team for each stage. As a team completes its task for a time box, it passes the outputs to the team for the next stage, and starts working on its task for the next time box. Due to pipelining, the turnaround time for each release is reduced substantially, without increasing the effort requirement.

Tutorial : Why do we need methods?

1.The author of the above article notes that “the development groups were isolated from one another - one group was doing analysis, one group was doing software design and a separate group was doing implementation”.
Why would this arrangement be a recipe for disaster?

When the development groups were isolated one another , how can they share information of part they do like analysis, software design, implementation . They cant connecting together how one group can discuss to other group . One group was doing analysis they have many idea to do project make it very interesting and unique but this group cant talk to group was doing software design that means group was doing analysis is useless because all of their ideas can't share to group doing software design , group was doing software design need find their own ideas to design software.And a group was doing implementation still need find their own ideas to completed project. I think if the development groups were isolated from one another, each group just do different project. One group unrelated to another they can completed project easier and less make mistake than when group were isolated from one another. The development groups were isolated from another this arrangement is really to be a recipe for disaster.

Tutorial: Why do we need methods?

2.    The author also quotes the Standish Report stating “the statistics demonstrate that the larger the budget and the bigger the team, the more likely the project is to fail. Nine out of ten large projects experience severe problems. With regard to software development projects, bigger is almost never better”.

 Why do you think that large projects with big budgets are more likely to fail?

Answer (XUAN TRUONG)

Large projects with big budgets are more likely to fail because of many reasons . Compare computer industry to other industry like bridge building . As you know all of the bridge building projects are large and in computer industry there are many large projects too . According the chaos report , bridges are normally built on time , on budget and do not fall down while software never comes on time , on budget and it always break down . If a bridge fall down , it's investigated and a report is written on cause of the failure . This is not so in the computer industry where failures are cover ignored, and as a result, we keep making the same mistakes over and over again .

Many report show that large project means the project is very complexity . Very complexity make more uncertainties . More Uncertainties make project is harder to estimate . Hard to estimate make low estimates . Low estimates lead cost overruns . And even if a large project has been launch, it still can be failure . Here is examples : 

Picture 1

Here is a illustrates the distribution of success and failure across project size : 

Picture 2

The large project fail much more than small and medium project . Why ? According the Gartner Survey , to know it we based on 6  causes of project failure :

1. Functionality issues
2. Substantially late
3. Quality issues
4. High cost variance
5. Canceled after launch
6. Rejected or not implemented for other reasons

Based on these causes we have illustrates the percentage of failures : 

Picture 3 

As we see , in functionality issues , the percentage of three project size is almost equivalent as other reason issues . In substantially late , large IT projects is higher than the other project because is large project , it take much more time to done and business conditions keep changing after the project scope has been set and it make the project time overruns . About high cost variance you can review picture 2 to for more examples . Poor quality of large IT projects is lower because large project cant develop with poor quality if u want it success . In canceled after launch , the percentage is lower because you can't launch a large project with many issues with function or time overruns especially the cost overruns . If large project fail , it fail during development.

The last problem is with big team , the large project still more likely to fail . Let take a look at an examples : In a develop team have 10 person , it's easy to see which developer needs help . In a team have 50 person , it's hard to see who needs help . In a team have 100 person , it's even harder . Even they memos their problems , u don't have enough time to help each person and it will cause your project time and cost overruns. So why don't we hired a small develop team to develop large project ? We don't do that because this may cause the developer have less responsibility with their work . One person have many work to do so they just finish their function or statement then work with the next function or statement with low quality even without testing . So that make project fail too.