Sunday, November 20, 2011

Fixed Price Distributed Agile Projects

I will be delivering a session on 'Fixed Price Distributed Agile Projects' at Agile Tour 2011, Bangalore on 26th Nov 2011.  This session will present the challenges and approaches related to executing Fixed Price projects in Distributed Agile model.

In reality, projects are sanctioned based on pre-approved budgets. Customers prefer to get projects done in fixed-cost. Can the scope remain fixed? Can the schedule also remain fixed?  The challenges of fixed price projects  emerge from changes in requirements.  How do we stick to "Responding to change over following a plan" as mentioned in Agile Manifesto when we execute fixed price projects?  How do we value "Customer Collaboration" over "Contract Negotiation"?

If you are in Bangalore next week, plan to attend Agile Tour 2011.

Friday, November 18, 2011

Requirement Engineering: Specifications in which form?

The day before we started the new project, my team member got curious. He asked, “Are we going to receive requirement specifications from customer? How will the specifications look like? Let us make sure that there are no communication gaps.”

I responded, “In a document with text, and UML notations in our standard format. We will get wireframes too.”

We had a short pause. I continued, “We will have a look at existing data and reports. We will do our best to reduce communication gaps.” He nodded silently.

I could read his mind. We had serious gaps in understanding requirements in our recent project and the result was a huge schedule over run. We wanted to do it better this time.

Specifications come in what form? Obviously in documents with UML diagrams, wireframes, etc. When it comes to requirements, we cannot afford to say, “Let us not worry about form. Substance is critical.”  Both form and substance are equally important.

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to go rectify later”, says Fredrick P. Brooks, Jr. in his book ‘The Mythical Man-Month (Addison-Wesley, 1995).’ He adds, “I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

Can Rapid Prototyping help? Yes. It can help to a certain extent. In fact, Rapid Prototyping can be done at the time of Requirement Gathering and Elicitation. Products meant for this purpose are available in the market these days.

When we combine the power of such tools with the way we create software using methodologies based on iterative and incremental delivery, we get an opportunity to deliver working software early and frequently. Delivering working software early at regular intervals is a way to make your specifications powerful. This is when you reduce the gap between what is specified, what is delivered and what is needed.

When you have specifications in written text, UML notations or wireframes for more than a month or two, chances are that they become obsolete. You need to get them validated. When you do rapid prototyping (on a case-to-case basis) and focus on short-iterations to deliver working software you get an opportunity to demonstrate working software and get feedback. You get to improve what you did.

It is easier said than done. I agree with Brooks. He said it right. Right?

Tuesday, November 1, 2011

Code Quality Metrics: Identification, Collection and Consumption

Unless we identify the code quality metrics we want to consider for a given project or product, before we start coding,  it is highly probable that we will get confused with a huge collection of metrics presented by tools and textual content such as books, white papers, blogs, etc.

We do capture functional and non-functional requirements in software projects. Can we capture requirements that can help us set a common understanding on expected level of code quality? 

When you use a static analysis tool, it is necessary to know acceptable range of values for each metric. Otherwise, how will you access code quality?

Code review tool does not serve the purpose until developers are cognizant of the semantics of code quality metrics and permissible range of values. I am sure we have heard, ‘A fool with a tool is still a fool.’ Don't you agree?

Every project or product team needs to have a code review checklist, coding standards and guidelines that can set a common understanding among developers on code review criteria. This will enable developers write good quality code to begin with.

Prevention is better than cure. Isn’t it?