fbpx

Real-world Software Development at Yukōdit (Part 2 of 3)

At Yukōdit, we are passionate about integrating real-world development practices into our program. By integrating these practices into our program, our students collaborative with a team and build their leadership skills, while learning and practicing the fundamentals of software development. We utilize aspects of the Agile Development Methodology to ensure students’ experience mirrors that of a real development team.

Before Agile became mainstream, software projects typically ran in the following rigidly planned, specified manner.

1) Planning: A customer need is identified and the feasibility of the request is evaluated.

2) Analysis: The customer would specify what they wanted and the technical aspects of the delivery are analyzed (with assistance from a developer or business analyst).

3) Design: The developer would receive the specifications and design a solution.

4) Implementation: The developer (and team) would lock themselves in a dark room (i.e., cave)with pizza and soda, only to emerge many weeks later with a finished (and possibly tested) product.

5) Maintenance: The developer works to fix bugs that may have been introduced and not caught during the testing cycle.

This process worked well, as long as the customer’s needs did not change during steps 4 and 5 and the customer actually knew what they wanted up-front. In practice, this is never the case. Customer needs change constantly in concert with new business opportunities or evolving commercial landscapes. Gathering feedback at the end of the process when the development process is complete often leads to software that is not as useful as it should be, or worse, does not solve the business problem at all.

The Cave and the Waterfall

By the time the development team has emerged from the development cave, the software they have developed is already out of date. Without a constant feedback loop, the software development lifecycle is moving too slow. Every day that passes without the software in use by the customer is an opportunity cost. The business problem still exists during this time, so either there is a lack of market share being captured or there is an inefficiency increasing cost. This process, without a tight feedback loop, is called “waterfall” development, because once the process has started it will carry on to completion and is difficult to change. The water only flows one way. The value proposition of any software delivery is eroded as time elapses within a waterfall practice.

Given these deficiencies in practice, the software development community required a more nimble way of delivering products to ensure the value created by their software is captured as soon as possible, and also to ensure that customer feedback is constantly captured and integrated into the delivery.

This is where Agile comes in. The Agile manifesto lays out 12 principles for software development teams. I will not bore you with all the details of the 12 principles (you can check the manifesto if you like), but they boil down to a few key themes:

• Work collaboratively with your team and constantly look to optimize your practices.
• Deliver simple, quality software in small, frequent increments to maximize the value of your software.
• Embrace change and gather feedback from customers as frequently as possible.
• Work in a transparent manner to ensure issues and questions are addressed quickly.

It has been proven in practice that the implementation of these principles leads to software that is incrementally adding value and which meets actual customer needs.

We would love to hear your thoughts on Agile! Do you think the Agile process is useful in your industry? Does your industry employ any similar practices? Have your kids ever mentioned any Agile concepts to you?

By: Mike Halbert, Co-founder & Parent

, , , , , , , , , , , ,

No comments yet.

Leave a Reply

Powered by WordPress. Designed by WooThemes