scrum.boulevart.be

Here are a few good reasons to apply agile development principles and practices…

1. Revenue
The iterative nature of agile development means features are delivered incrementally and interative, enabling some benefits to be realised early as the product continues to develop.

2. Speed-to-market
Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and ‘perpetual beta’.

3. Quality
A key principle of agile development is that testing is integrated throughout the project lifecyle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.

4. Visibility
Agile development principles encourage active user involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.

5. Risk Management
Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there’s still time to make a material difference to the outcome.

6. Flexibility / Agility
In traditional development projects, you write a big specification (for example by RFP’s) up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it’s expected. Because the one thing that’s certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it’s imperative to have an  actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.

7. Cost Control
The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.

8. Business Engagement/Customer Satisfaction
The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.

9. Right Product
Above all other points, the ability for  agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It’s all too common in more traditional projects to deliver a “successful” project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.

10. More Enjoyable!
The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what’s right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.

Implications of embracing agile development principles
But there are implications. There’s no such thing as a free lunch! And there’s no magic bullet for software development. Sorry, no, you can’t just drink the cool aid In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can’t blame someoone else if things don’t go right, and it generally requires much more commitment and effort from everyone involved - i.e. teamwork is even more important.

Nevertheless, the advantages of agile development are really compelling.

Yesterday, I found an intresting post in my LinkedIn.  It clearly states that Agile will gain in these economic difficult times.  The article was published on TechCrunch

 

No Scrum Traditional Project Management Scrum and General Benefits:     1. Adaptive Predictive 2. Empirical Approach Liner Approach 3. More Frequent Reviews Review before or after delivery 4. Open and Transparent Closed, hiding behind documents and unrealistic planning tools 5. Light Weight Heavy Weight Scrum and Benefits for Customers     6. Potentially shippable Product delivery after every 2 weeks or 4 weeks Potentially Shippable Product delivery at the end of the project 7. Frequently Customers can ensure that what they were expecting is what they are getting by monitoring the progress frequently. Customer can only review what they were expecting is what they got or not at the end of the delivery. 8. Customer need not to risk for committing and paying the funds without looking at actual progress of the delivery. Customer has to commit and pay the funds phase wise without looking at the actual progress of the product. 9. Customer can start using the prioritized functionalities which creates business value. Customer cannot use the product features until the completion of the product. 10. Customers can determine the product cost based on the progress and during the development. Customer will be decided at the beginning of the development for some agreed upon amount. 11 Allows Continual Inspection, adaptation, Self organization, and emergence of innovation. Not Self organizing but managed teams 12 Customers can set development Priorities at the beginning of every sprint. Can’t go with priorities 13 As Customers are involved frequent reviews which updates them about the progress, good, bad. Based on the same Customers can change their minds without paying heavy costs Customers will be updated with Reports Till the end of the project. Scrum and Benefits for Service Providers     14. Delivery high quality work Delivery Average quality work 15. Gain the Trust of customer Very low number of projects succeds and who faild lost customer trust 16. Customer Satisfaction Unsatisfied Customer 17. Get More Business If not successfull, Loose customer  

 

 

 

 

To my opinion at least one of the following items should be variable in order to deliver a successful project:

1. -Timing
2. - Budget
3. - Quality
4. - Scope

During my 15 years as a project manager (the last 5 years in e-marketing), I believe that it is easier to have the scope variable rather than timing or budget.   Especially as ideas change over time of the project.

In e-marketing (and web projects) timing is crucial so this is no option to make it variable as the campaign starts at a certain point in time.  The same is true for budget.  It is always very difficult to have your stakeholder ask extra budget to his/her boss.  The solution for this is to have the scope variable with priorities.  I define the scope by means of user stories and than prioritize them together with the stakeholder as Must Have’s, Should Haves, Could Haves and Won’t haves this time.

The Must Haves are necessary in the project to be successful, the Should and Could Haves are the items that we can play with in order to embrace change during the project.  In this case it is easier to tell you boss that a certain could have is dropped in order to stay within budget rather than asking for extra budget.  This functionality was probably not critical to deliver a successful project.

The Should and Could have’s probably will change during progress of the project.  Sometime extra stories arise so that we can add them and remove some minor other stories in order to keep everything within budget and timing.