Agile software development process

I found that the Principles behind the Agile Manifesto on the web. Here are my comments to these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agreed. Delivering the software timely is important.  If you lost the market window, you lost the customer.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

We still need the change control process. Development cannot work under a moving target.  Change control process ensure that the changes are evaluated and communicated. The change control process is even more important under Agile software development process.

We welcome changes because we know how to control it.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Keep the software working with the incremental changes and daily or weekly (short timescale) "build".  I think that the quantity will be better.  However, it may be that easy for a new development project.  The software industry is being consolidated and maintenance revenue is the focus of many firms.  I think that Agile process fit better for enhancing the existing software.

4. Business people and developers must work together daily throughout the project.

My interpretation is that this is the daily change control process.  Instead of having a weekly or bi-weekly huge "change review board", we need to have a delegated, being trusted, small group of people, consisting of both the engineering side and product management to make "daily" decisions.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is consistent with my comment above.  The agile software process cannot be achieved if any single change requires a huge discussion and raised to the top to make an top-down decision.  "Trust them" is the key.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This could be a challenge nowadays since many if us work remotely.  However, I feel that face-to-face does not means that we have to be physically in one location of one building. Instant messaging, phone,  Internet conference can help a lot.  Since this is a daily change control process, we still need to record the changes, including what decision is made for what reason. 

7. Working software is the primary measure of progress.

This is consistent with the good project management principles. You need to break your scope of work into enough details for tracking, monitoring, and controlling.  Typically, the work should not be more than 2 weeks of your process collecting period.  The status will only be reported as "not started", "started/in process", or "finished".  If the task is in the "in process" more than one cycle, you know you are in trouble.  You can avoid the subjective measurement of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This seems a common sense to me.  I am not sure if I understand what they try to say.

9. Continuous attention to technical excellence and good design enhances agility.

Kaizen - Continuous improvement - the same concept as Deming described in his famous 14 principles.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

My takeaway is : Focus on the "minimal usable solution" we absolutely need to provide.  What exactly the customers are looking for.  Do not do more than that.

Sometimes, especially from architecture perspectives, we want to maximize the reusability or extensibility.  I think that the trend is that we should rethink about it.  The "Reusability", "extensibility", or any traditional "good architecture" criteria, should be justified with business needs.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

No sure what "Self-organizing" means.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sounds like TQM - Quanlity Circle.

My blog is now listed in Blog Hub. If you like my blog, please submit your vote or write a review. Thank you.

Using Process Flow in Requirement Definition and Solution Analysis

Process Flow is a useful tool in describing the business requirements
and product requirements. They may be created for different
purposes: describing the business process or the user system process.

1. There are pure "Business Process" flows. These business
process flows describe the business processes happened in the
organization. They actually do not relate to the software
development. They help the system analyst to understand how the
business work. A business process flow can describe either the
current business processes or the ideal, the best practice. They are
not just only a system analysis tool but a business reengineering
tool.

One of examples is the project management lifecycle described in
PMBOK published by PMI. It describes the typical project
management processes to help the reader become a more successful
project management professional. Their models include different
levels of details. At a very high level, they break down the project
management processes into initiating, planning, executing,
controlling, and closing. For each high level process group, they
provide the detailed, 2nd level processes. For example, you can
find different scope planning, resource planning, activity definition,
activity sequencing, etc. under the planning process group.
PMBOK uses processes to describes the work involved in the
project management function and describe each in details.

Similarly, you can also describe the supply business flow as
create a procurement requisition, create a RFQ, receive quotes from
suppliers, create a purchasing order, receive shipment notice,
receiving goods, inspect the goods, verify the supplier invoice,
create voucher, send the payment, etc.

2. The System Flow is another thing. It describe the use
procedures. It describes step by step how a user may use a
system.

It can be used to describe how the current system is used or what
the system should support. It is a tool to describe the system
requirements. They can be independent from a specific system, but
the flow is created to describe the user-system interaction.

Submit to the Blog Directory and added the GetBlogs link

I just submitted my Blog to the GetBlogs Directory.