Benefits of Fixed Price

Usually preferred engagement model for software service companies is Time & Material. Payment is rather stable and depends on FTE numbers then. The evil comes in some time, when it's evident that the principal delivery is often not working software, but humans.

New approach is to work via fixed price with special terms of selling specific volumes of action points or story points. Then the focus is on the work and performance criteria, as velocity, quality, technology profitability, and product value.

So Agile T&M wrapped into FP language matters!

Trunk or Branch

A strong team of ten developers deliver quick and smooth. You can count on numerous enhancements at one hop. Development is ongoing. One app component is being changed from several places by several programmers.

And then request for urgent release drop appears. Feature #N should be deployed now. Other features implemented in the same component did not pass QA yet. Tricky moment. In this case branching helps greatly.

Please note that time is consumed heavily anyway on incorporating of the feature into previous version of code.

Added value

The value of a role and a person acting this role is to be visible and clear. It's like a dish. If ingredient is taken out, the taste is different.

If PM is out of a cooking pan, these goals should not be lost out of sight:
- Delivery schedule is accommodated with customer expectations
- Assignments are spread equally through the resources
- In/out streams between analysts, developers (UI, database, middleware), QA, infrastructure, support, management, customer, and user communities are handled properly, quick in time and without missing parts. E.g. traceability matrix is supported.
- Resources are performing in acceptable zone (green, might be yellow, but not read)
- Achievements and various experience of parallel streams is taken into account

Why Ukraine

Reasons why Ukraine is worth to look at with regards to software outsourcing:

- Strong engineering traditions inherited from strong USSR science, resulting into visible positions in aircraft and aerospace industries

- About 5 000 engineers graduating each year from ~20 technical universities through the country
- About 15 000 professional working in ~50 companies on the market
- Network of dedicated development centers in 5 major locations (Kiev, Dniepropetrovsk, Kharkiv, Odessa, Lviv)
- Bandwidth Internet easy available throughout country at offices and home locations

- Special easy tax mode for working individuals

- English of developers at sufficient level to communicate directly with customer

- Location for Agile Eastern Europe conferences
- Top 5 of software outsourcing world destinations since 2007
- Named as best software outsourcing destination 2010

- Time zone close to UK (GMT +2)
- No VISA needed for holders of US and EU countries passports

Does it work

Certain professionals are experienced at generating spreadsheets with numerous list of issues, its color-highlighted priorities, types and comments. It's a pity when these state-of-art docs do not find their intended reader.

Especially it's a pity when app does not work after so many docs generated.
I believe, summary in free text with bullet points are more useful for the delivery.

Perfomance

IT happens. The application works fine until stakeholders are concerned about functional requirements only. When real data arrives, non-functional requirements are starting to be an important factor. 10 transactions are performing fast enough. Let's try 10 000 - picture is different. Timeouts, exceptions, batches - these are new artifacts. Anyway, this hassle is nice.

Interfacing

The new application is delivered in time, works good, does not produce issues, and looks self-sufficient. That's the state until interfacing is not applied. Data publishing to consumers via API should be covered with visible time&resource reserve. Invisible configurations take time, not allowed to be modified when needed.

Same with inbound data sourcing - supplying systems modify the format/content and do not provide quality deliverables at the first iteration.

Useful to keep this notion at back of mind.

Resource leveling

Raise your right hand! Sounds easy, eh. What about making 10 000 people to raise a right hand together at one moment?

Something similar happens with software development in one big group, where it's needed to deliver many-components solution with 20 000 lines of code.

Twenty developers able to work smoothly many days in line configuring interfaces between the parts to work fine? That's the goal. Hidden requirements are identified, track of risks not lost, environments are steady. That's how we work.

Two tunnels

"If our two tunnels don't meet, instead of one we will give you two tunnels."

Quite often patterns are not re-used even between three developers in 1 room.

Need a grid? Here are three implementations from three different persons.
Need a grid? Estimation is one week, since anyway we're writing it from the scratch.

Wanna have same grid in 1 day? Then pattern components are to be developed and used within the project or program.

Re-use or do it from scratch

There is a constant discussion if "doing from scratch" is good when a lot of historical and supporting materials are available.

Some say, that copy-cat of the successful project, including documentation (requirements, test plans) is good for new one.

The concern is that in case of copying of documentation and its almost automatic approval, than the real requirements are not identified. Also copy-cat does not allow the stakeholders to investigate the product and process with sufficient level of details.

Contra argument is that proper product already contains features of best-on-the-market, and superior-for-business features. And requirements of the particular organization might be much worse than build-in features of the product. Example is SAP that does not allow much to change in its pre-configured business processes.

Anyway, Know Your Business is crucial success criteria. Vote for "Do from scratch, can read, but No Copy-Paste"!

Master Data Management

This is not a new idea to have common data available through the enterprise to various consuming applications. The example of master data might be list of clients, various codes, e.g. regions, codes, exchanges and so on.

These days with numerous corporates merges and acquisitions, the importance of one golden data source in the big organisation comes into play again.

The challenge is to justify that big investment of corporate MDM, when there is always a temptation to create "quick and easy" shadow storage of the data taken from one-off data load. The argument on the risk of data to be out-of-date with these shadow solutions is often not taken into account.

Indeed, the smart mind can take the decision to implement and support MDM through the corporation.

Less is Better

Agree with Apple's leads that a strong will is required not only to decide what's needed, but the strong will is especially required to decide what is not needed, at can be skipped. That specifically matters for product management. For sure, excessive product features make efforts higher, whereas sells and revenue get lower.

UBS 2

Discussions on UBS $2bln loss are mostly about risk monitoring process and potential impact on taxpayers. Another point is whether bank suppliers will feel the change, specifically software development off-shore ones. I believe, this was not application bug with trading limits!

Moneybookers

Moneybookers, European peer of Paypal, verifying post-address by sending letter to the address in the profile. Thus, limit for operations is increased.

Odesk

Odesk.com offering personal experience in freelance outsourcing. Analysis, development, QA, data entry - anybody cam find work to the own taste.
Skills not enough? Extensive list of tests (english, programming) will be of use!
Build your own marketing strategy with price growing in line with new experience.

New Word of Apache Hadoop

Please note that Big fish companies are going ahead with new Apache product for distributed data processing - Apache Hadoop.

Forrester Reseach, Accenture, Cloudera, Informatica setting open questions:
- Rethinking Data Strategy in the Era of Big Data with Hadoop
- Where Does Hadoop Fin in Your Vision of "Data as a Platform" Architecture

Bridging the Communication Gap

The book to read:
Bridging the Communication Gap
Specification by Example and Agile Acceptance Testing