Thursday, April 27, 2006

Shameless Promotion 4: Rapid, Affordable Application Development

I am available to help Clients develop applications cheaply and quickly, applications that help them to reach more customers and reduce costs. I can help clients use the Web to make breakthroughs in marketing, sales, and operations.

I have built dozens of successful applications for the Web and other environments. I can provide hands-on expertise across the software development lifecycle: from strategy and requirements to architecture and design to development and testing.
I also provide project management and "general contractor" services, so I can bring the right talent to the table for most any web development project.

The following is a quick summary of the skills and capabilities I provide to help you achieve robust solutions quickly and at affordable rates:
  • Experience in online communication, eCommerce, and improving efficiencies.
  • Technical lead, architect, and developer experience on dozens of projects, including complex applications for Sheraton Hotels, Travelocity, Budget Rent-A-Car, and the Veteran's Administration.
  • Programming experience in Java (5+ years), C (3), VB/ASP (3), Perl (2), and lately Ruby.
  • Effective, hands-on skills as a software engineer, architect, and business/systems analyst.
  • MBA and a Bachelor's in Computer Science.
  • Extensive network of software and Design professionals for general contracting services.
  • Very competitive rates, for myself and subcontractors.

My Resume describes my skills in much more detail. I'd love to make your development project a huge success, drop me a line if you are interested.

- John

Wednesday, April 26, 2006

Software Success Factor #1: Manage for Agility UPDATED

The ability of an organization to Manage for Agility is one of the most important success factors for modern software development. This factor encompasses the critical role that Management--or the project Client or Sponsor--plays in Iterative Development. In this post, I will attempt to address what this factor entails and how it is accomplished. I will also briefly recap why this management style is superior. I have yet to complete the Overview of the Reference Model, but Agile Management is so important that I wanted to flesh out this success factor first.

Iterative development is perhaps the key attribute of modern software success, but without management support it is impossible. To manage for agility, leaders must go against many traditional management styles and ingrained practices. It is a natural for successful business people to try to avoid future change through detailed planning and up-front analysis, but changes are inevitable. Trusting the team and the process to produce the best solution, allowing the scope, the design, and even the process to emerge, is what it means to Manage for Agility.

To manage agile projects, sponsors must resist the desire to plan and design the entire project before starting any development. To be agile, management must instead embrace a flexible model that responds to changing requirements and an evolving understanding of the solution. Management must trust the process and the team to produce top quality software, without a relying on a rigid scope.

Often it is the "commercial Model," contracts, SOWS, etc., that most influences the interaction between management and the project team. To manage for agility, the commercial model must provide for evolving scope and design. Put another way, attempting to fix the scope in agreements up-front is simply at odds with an agile style. When using consultants or contractors, a Time-And-Materials approach allows for the most agility, or the agreement can employ separate SOWs created at the start of each iteration. Another approach offered by Kent Beck is the use of "Optional Scope Contracts."
It is also important to understand that agile does not mean that no planning or requirements are done up front. The project still needs a first cut at the inventory of requirements--e.g. a Scrum backlog or a Use-case survey--that is the source from which iteration requirements are selected, refined, and built. An agile project can also develop a detailed, "pro-forma" project plan, but managers should not feel compelled to stick to the original as the team adjusts to accumulating change.

Why should managers buy into this approach, when traditional project management techniques have worked on all kinds of projects, from construction to aerospace engineering? Because software development is fundamentally different from construction or engineering, and treating it like these disciplines magnifies the risk of failure, raises costs, and produces worse software.
Change is unavoidable in Software Development, more so than most any field. Alan Shalloway made the claim, at a recent Agile Denver meeting, that software development is not like building a bridge; it is more like building the first bridge... or the design phase of a bridge project. An analogy is also often drawn between construction and software development. However, many experts claim that software development is essentially all design work, and the only step that is really like construction is the compile/build cycle.
The highly successful Scrum process is based on proven new-product development processes used by Japanese companies. Indeed, the Scrum proponents and many others have claimed, accurately I believe, that software development is very like new product development. If we look at software development as roughly analogous to the design and development of a new kind of car, or a new consumer electronics gadget, it becomes clear that the nature of the process is unpredictable and should be managed accordingly. Agile management uses an empirical process management approach to produce a better product. One need look no further for evidence than the difference between American cars and Japanese, at least until very recently.
Alistair Cockburn expands on the idea of "responding to change over following a plan:"

...traditional process management—by continuous measurement, error identification, and process refinements—strove to drive variations out of processes. This approach assumes that variations are the result of errors. Today, while process problems certainly cause some errors, external environmental changes cause critical variations. Because we cannot eliminate these changes, driving down the cost of responding to them is the only viable strategy. Rather than eliminating rework, the new strategy is to reduce its cost.

[NOTE: I think he means code rework--Big Up-Front planning and design will result in more rework of other work products, assuming the effort is not wasted entirely as these products are abandoned.]

Business needs, priorities, understanding of user needs, expertise with the
technical platform, market forces, and available technologies... All of these
can and usually do change over the life of a project. Agile management rolls
with these changes and capitalizes on them to make the best software possible.
Smart project sponsors can use agile management to build better software for
less money.

Friday, April 14, 2006

The Software Success Reference Model - Overivew

Here, again, is my Reference Model: a 30,000 ft. view of software success. This post will provide an overview of the categories from the model--sort of a taxonomy of success. See my previous post for more information on how I derived this model.

Organization and Project Management
Perhaps this should be entitled simply Organization and Management. This grouping deals with factors that are beyond the scope of any project team--organization and management at the highest levels.

Project Team
These factors deal more specifically with the project team involved directly with producing the software.

Iterative Development
This category contains factors that relate to producing software in an iterative, incremental, adaptive manner.

Productive Culture
Factors dealing with the kind of people the Organization employs and how the Organization fosters a culture that promotes productivity.

Productive Practices
Specific practices that help the Project Team develop software efficiently.

Software Engineering (for Large Projects)
Factors necessary for projects with a large number of developers and/or critical consequences of failure.

Manage for Agility
This factor encompasses the critical role that Management--or the Client--plays in Iterative Development. Leadership must be willing to launch a project without detailed plans or specs, and trust the team and the process. Further, project clients must realize that the agile approach is a Good Thing, allowing the team to respond nimbly to a changing world, and producing more relevant software in less time.
Deliver Value Quickly & Often
Another aspect of Iterative Development, this factor focuses on the ultimate goal of software development: working software. Teams must focus on producing working software from the very first iteration, and keeping implementation as relevant to the needs as possible by avoiding unnecessary interim work products and long time lags.
Continuously Learn & Optimize
The final component of Iterative Development is the concept of continuous improvement. Iterations afford the team with the opportunity to exercise all lifecycle activities in short bursts. This means they can reflect, learn, and optimize their process and practices with each cycle.
Empower the Project Team
Also solely in the Management arena, the client of the project must provide the project team with the tools, resources, and support necessary to succeed. As much as possible, the team must be allowed to organize and direct itself however necessary to deliver the requirements.
Enable Open Communication
Software development is inherently a team design activity. Communicating ideas and building a shared mental model of the solution are critical. Organizations must strive to achieve "osmotic" communication, provide access to experts, and involve users throughout the process.
Demand Quality
Teams must develop a high standard of quality as a norm, and internalize quality validations within the team, rather than "throwing" code "over the wall."
Use More Realistic Specification(s)
Just as a picture is worth a thousand words, the richer, higher-fidelity one can achieve in software specifications the better. Teams should use mock-ups, prototypes, and visual models as much as possible, while still constraining specification to whatever is "minimally sufficient" for the current increment.
Use Automation and Tracking Tools
The value of SCM, task & issue tracking, automated tests, etc. is well established. Just do it.
TODO: Software Engineering factors