Home - Category: Uncategorized (Page 2)

Category: Uncategorized

Welcoming Change Whilst in the Realm of Agile Software Development

Posted on August 8, 2017 in Uncategorized

One of the most difficult principles of Agile Software Development to actually implement is the principle of welcoming change. Two of the statements of values in the Agile manifesto are:

  1. Customer collaboration over contract negotiation
  2. Responding to change over following a plan

Both of these statements lead to the idea that Agile Software Development welcomes changes from customers and other stakeholders in the project. The Software Development team aims to gather feedback by developing frequent releases through developing the software in a series of iterations. A customer, changing their minds concerning the requirements of a project, isn’t viewed as a problem, which can be in sharp contrast to how a lot of methodologies approach the topic of requirements changing. This incorporation of feedback and customer involvement is an important contribution to the success of Agile methodologies as it leads to the development of software that customers really want. Following this principle is no easy task because the application of this principle needs to start at the very beginning of a project. Guides to implementing Agile Software Development frequently mention the role of the executive sponsor, and other business oriented roles within a company which need to buy-in and support an initiative to introduce Agile Software Development. But in a Software Development company that develops bespoke software directly for customers, the business people in the company need to understand and stick to the principles of Agile Software Development likewise.

There may be support for Agile Software Development in a project of all members but the general perception amongst the business people is that it is one area which the developers do, and does not directly concern them. As much of the material available on Agile Software Development does specifically concern Software Development teams, that is quite an understandable assumption to make. In a company developing bespoke software, the client needs to be made aware of the nature of an Agile Software Development project, and a contract needs to be negotiated that is compatible with the chosen methodology. And it’s the business people who are associated with a project that usually hold the responsibility of setting the customer’s expectations for a project and negotiating the contract.

Customers not really acquainted with Software Development expect that when negotiating a new project with a Software Development company that the process is quite like purchasing almost every other goods and services. The client explains what they need, they agree a price together with a delivery date, and the customer then waits for it to be achieved. The Software Development company will not want to challenge these expectations for the fear of making a customer uncomfortable, and potentially losing their business. This often leads to a binding agreement that mirrors these expectations. The customer continues to expect that the software, by the release date, is going to be ready and do everything the customer wants, and they only need to wait.

However it is inevitable that the customer will need to provide feedback on the software and will be very keen to make some changes. In the above scenario the client is going to find themselves giving their feedback at a time towards the release date when they actually get to see the software.

These changes are unlikely to be very welcome to the Software Development company at this point. In practice these requests for changes results in friction between the customer and the Software Development company, possibly bringing about arguments between the company and the customer. The company will believe that these requirements wasn’t specified originally when the contract was signed and demand additional cash to implement these changes. If the customer agrees, a new contract will need to be negotiated. On the other hand the company may agree to do these changes for free given that the customer is without a doubt quite upset that the software does not do what the customer wants. The more often these changes are handled for free; the company gets closer to generating a loss on the project. In both of these scenarios, the project is sure to be late.

If the development team itself is trying to be Agile and is developing the project in iterations, the case is often improved through getting feedback from the customer earlier on in the project. But if the contract remains to be the same, these changes will still be unwelcome to the business people associated with the project. They will be seen as an extra expense and the developers are going to be instructed to extend the time on making these changes until a new or revised contract can be negotiated. Once the business people perceive that changes will be happening between iterations and that this needs addressing, they should recognise that a new approach will probably be required in future for making new contracts with customers. An effective option that they might choose is to try to break down the ‘development’ of the project into separate, ready planned phases and then make this the substance of the contract. This approach doesn’t challenge the customer’s expectations of being certain of the outcome of a project, and so it appears like a safe option. At the start of a project, a customer is frequently quite positive that they know what they aspire to. In practice, actually seeing and using the software might most likely make the customer consider the project in a whole lot more depth than they had previously.

This phased approach to making contracts is not going to solve the issue of welcoming changes and introduces new problems. When the first phase of the project completes, the customer gets to use the software for the first time and starts making requests for changes. As a consequence the next phase will have to be planned again. If the original phases were time estimated then the next phase will require a new estimation from the development team. And the business people will have to create a new contract for the next phase. Normally, this approach will demand a large administrative overhead for relatively small amounts of work. The customer can also be likely to get impatient over the length of time it takes just to get some more work done. More steps need to be taken to effectively develop within an iterative fashion.

In an ideal scenario, the people setting the customer’s expectations for the project would have bought in to the concept of Agile Software Development and grasp the principles involved. They would have the responsibility of also convincing the customer of these benefits and negotiating a contract that works well with their chosen methodology. Three typical customer expectations shall be challenged during this process:

  1. that they already know exactly what they want
  2. that they can be certain of what to expect at the end of the project
  3. that the Software Development company is exclusively responsible for the success of the project

To convince the customer that developing the project the Agile way is a good idea; the benefits need to be emphasised:

  • That they can change their minds if they want, when they want
  • Their changes will be incorporated in to their application quickly with minimal administrative overhead
  • They will not have to wait long to see their changes in the software
  • The application developed will be what they want it to be not now but what they want on the release date
  • They will have an important role in guiding the development of the project throughout its development

There are of course trade-offs for these benefits:

  • The customer can’t be certain what they are certain to get at the end of the project when signing the contract
  • The criteria for the success of the project will change with time and will not be stated explicitly in the contract as a detailed specification
  • The customer must take an enthusiastic role participating in the project. The project’s success all hangs on on the effectiveness of the collaboration between the customer and the Software Development team.
  • The customer will have to prioritise their changes, choosing which ones are developed first and which of them have to be dropped when necessary

A compatible contract will likely not state a detailed project plan, and make that plan a binding agreement for the Software Development company. General, advanced level requirements will be used as the success criteria for the project.

In return the contract will enable the customer to request changes to the project when the customer wants to. A formal definition of how changes are handled will be included in the contract. This definition will match the methodology used by the Software Development team. With most Agile methodologies this will mean that the development team will incorporate these changes in the next iteration following the change request from the customer. The contract will also not contain specific time estimations for high level requirements. It will instead contain an iteration schedule. A contract that welcomes change is a contract that does not have to be changed.

While the process described is known as change, this term doesn’t accurately describe the all that is taking place. A changing business environment can motivate changes in requirements but what is happening most often is the creation of new ideas for the software from both the customers and the development team. It is part of the creative process that makes the software and it is definitely something that ought to be welcomed.

Advice on Successfully Choosing an Offshore Partner for Outsourcing Software Development

Posted on August 6, 2017 in Uncategorized

The thought of outsourcing software development to an offshore development company may be daunting. The following tips may make this decision easier for you as you can check whether potential software development outsourcing partners meet the criteria listed below.

One of the most important factors is the quality of development. Most companies seek stable, reliable long-term relations and demand the same high level of quality that their own in-house developers would produce. However, in reality, a new offshore partner always presents the risk of exactly the opposite. From my own experience as the CEO of an outsourcing software development company, which has been operating for many years, I know that it is very difficult or even impossible for a company (for instance, an IT company in Europe or the United States) to be absolutely sure that a potential new partner in India, China, Russia or elsewhere can really deliver top quality. The following advice, however, might help you build successful business relationships with offshore development companies.

The first step should be to research the potential company online. Check the year of their domain registration because sometimes offshore companies state on their website that they have about 10 years of experience, but strangely their domain was only registered the previous year. It is also important to divide all providers of offshore outsourcing software development into two categories: developer groups and legitimate companies with a brand name and reputation. You should be aware from the start who you are working with. Developer groups are unstable and often not very reliable. Their expertise is difficult to verify since the quality varies from one individual developer to the next. If a good developer leaves the team in the middle of your project, deadlines and development quality are likely to be impacted significantly. Developer groups charge less for their services than actual offshore outsourcing companies, and though such groups might work well for small-scale projects (ranging from USD 1,000 to 10,000), they often disappear unexpectedly. Developer groups tend to advertise themselves as reliable and qualified with many years of work experience. If you only have small projects to outsource, I do recommend looking into working with a group of developers. If you do your research well and choose the right group, this can indeed be a very cost-effective option.

However, if you are looking for someone to develop a larger project with a prospective timeframe of three months or longer, I urge you to work with a legitimate offshore company rather than a group of developers. The problems than can result from a developer group disappearing mid-project, not meeting your deadlines, or not delivering the high quality that you need is simply not worth the lower cost.

To minimize this risk, I recommend that you outsource any large projects or long-term development only to large and established companies with a good reputation (good references, big clients, good reputation online, older domain name, etc.). Such companies usually have well-organized software development processes in place and are known to follow modern methodologies and best practices of software development. The most qualified software developers often work in established companies rather than freelancing or working in small groups of developers. When faced with complex projects or unusual tasks, working in a company provides the benefit of always having someone to go to for advice on a specific technical problem. This is only one of the reasons why companies tend to consistently deliver better quality.

Some additional points to keep in mind:

1. If a service provider gives you a price and timeframe for the project but does not include a detailed estimate of the time and costs required for the individual tasks, doubts about the qualification of that particular partner are completely justified. Such a company might not meet deadlines or deliver high-quality software solutions.

2. Development should always include testing. In some cases, testing and bug fixing make up 50 percent of the entire project implementation period. An experienced and professional company knows that extensive testing is absolutely vital in the development of complex projects and puts the necessary QA measures in place.

3. Check the company’s portfolio. I highly recommend finding a company that has already developed projects similar to the one you are looking to outsource. The company that best suits your needs is likely to be one that works in the industrial specialization you are seeking for your project.

Do not make the lowest price your priority. Please keep in mind that you get what you pay for. If a company offers a low price, it may be because they are using junior developers rather than senior or mid-level developers. Another reason may be that you are actually dealing with freelancers or developer groups, who work from home and do not have expenses such as rent for office space, taxes, and other costs that a company generally has to bear.

I also urge you to not rush into a business relationship with a new partner (a policy that I follow myself as well). Start step by step by discussing any issues and details that come to mind and deciding on a model and working style that works well for both parties. Following the abovementioned advice will be sure to help you find an offshore software development center that can be a reliable business partner for many years to come.

Communication is another factor that many clients worry about. Even for people speaking the same language, misunderstandings are a fact of life. The risk of misunderstandings increases exponentially when different languages and cultures, and therefore also different preferences and styles of communication, are involved. Simply having English-speaking contacts at your new Offshore Development Center is not enough. The company should have a system in place that fosters communication by means of the appropriate software, such as issue tracking systems, conference call scheduling, Skype chats, etc. Professional companies tend to be very experienced in setting up effective communication measures.

Last but not least, we have to discuss source code security and intellectual property protection, as this can easily become the most important factor of all. When a company plans to outsource its software development and the software to be developed will be based on existing source code, it is essential that this source code as well as any information about clients remains confidential. For this reason, I do not recommend working with groups of developers if confidential information is involved since these developers cannot ensure serious protection of intellectual property nor is their reputation as important to them as it might be to a large company. For example, as the CEO of the company, I sign NDAs along with all of my developers. I believe that it is the right approach for any company. Please be sure to ask your service provider about their approach to NDAs for all employees.

A Guide To Understanding The Process Of Software Development

Posted on August 5, 2017 in Uncategorized

Many business people don’t fully understand the complexity of a software development process. It’s natural, since specialized books about development are read by developers and other IT people, and many others might still be referring to a software project as ”coding” or ”writing”. With better luck one might add ‘designing’ and ‘testing’. Quite inaccurate.

One can think of several metaphorical comparisons to describe software development, such as writing a book or building a house. Some of them are a good light in the dark, some are rather misleading. And while many people may argue whether creating software is an art, a science, or a precisely elaborated process, we’d leave that choice to someone else. It cannot be described sparsely. But we’ll try to give some descriptions and comparisons in a compact and clear way.

Do We ”Write” Software?

One of the common but rather vague things is comparing creating software with writing. Writing code, writing a book, and so on. You can start writing a book without a plan and go with the flow; with custom software development you cannot, unless developers do a rather small piece of software on their own – and for themselves. Moreover, an outsourced software project never starts with writing code.

Books and software may both have strict deadlines. But once a book is published, what’s written is written; rewriting is not an option. But software keeps being under constant improvement with new versions being released – it’s a natural thing. It’s almost impossible to get every need of your end user, catch up with business and technological changes once and for a lifetime. Books aren’t that dependent on changes; software is. But that’s good: your software, unlike a book, can’t become just another mediocre thing on the market, can’t become irrelevant and outdated. The processes are absolutely different: we prefer using the words ”create” or ”build” software rather than ”write”.

Do We ”Grow” Software?

”Growing” software on a good basis and a good set of documentation is possible to a certain extent. Like with writing, it’s not the best description one can suggest. It partially gets the incremental, agile nature of making and maintaining relevant software. But while ”growing”, the product is rarely tasty until it’s ripe, and the owner has to wait awhile.

The difference is, in software development there are different stages of being ”ripe”. Startups usually demand rolling a minimum viable software product on the market, getting feedback and making corrections and improvements. Each version is more ”ripe” than its predecessor, and it has to be ”watered” by support and maintenance, kept fresh amidst all the business and technological changes.

Do We ”Build” Software?

This one is considered by many specialists the closest way to describe software development, and we can agree with that. Construction works show the huge importance of careful planning, preparing, guiding the work, and performing it. The limits of software depend on how its architecture is constructed. The amount of works doesn’t grow gradually, since every building is different, and requires different approach. There can be a hospital, an office building, a school or a barn, and same physical size doesn’t mean equal amount of labour. Something is done with concrete, something can be done with wood and nails, and the latter doesn’t work well with complex and valuable software for mobile startups and other businesses.

– Everything depends on the kind of a building you need. You need to figure out the problem the software will solve, and conduct the necessary preparations, do market research, gather info, etc. The more complex your software is, the more resources must be spent on planning. Bad planning – and the whole app fails, falls like a house of cards by the first gust of a wind.

– Then you and your chief architect (project manager) can proceed to design that perfectly combines functional requirements and interface, resulting in proper user experience. Sure you want those who will work or live in the building to be fully satisfied with it. Same thing with software. One more good thing, once the design is approved, it’s way easier to give more precise estimations for the remainder of the construction (development) works.

– When furnishing a house, you needn’t building things you can buy: household appliances and furniture. It’s much cheaper and way faster. Same with software: if your software development team is experienced, it will use all the available resources to stay away from writing needless basic things: there are lots of software toolkits, frameworks, classes, and libraries for that, each for a particular case. And if the team means business, they will easily find tools and technologies that will get your tasks done as fast as possible. Custom pieces of furniture take more time and efforts, but in most cases there are already existing pre-built ways to save your time and money without compromising security and efficiency of your software.

– There will always be changes in functional requirements. Again, changes can painlessly happen within the planned architecture. Here we once more emphasize the importance of preparations – although this topic is worthy of a separate article. And we cannot go anywhere without mentioning quality assurance, which constantly checks different aspects of how the software works. What’s more – even a minor change involves testing, so that’s not the place to cut the costs (in fact, QA usually takes about 30% of the whole development time).

– Optimization of software (inner walls of a building) is limited to the approved architecture, and here main expenses are all about labour, not materials. But what you receive in the end is better software and satisfied users. Meanwhile users speak their minds on what they would like the apartments to look – and one should never neglect these opinions.

– One more thing worth noting – a good architect (or a good creative expert in software development) is always ready to consult you on things that should be solved immediately, and what can be left for later without breaking your plans or the quality of your software. You are most likely to not know the subtleties of the technical side – so leave making suggestions and explanations to your team. Unless you are an experienced IT person and you needn’t reading this article to get these insights.

As you can see, the last example is really the closest, and the list of similarities can be continued forever. But the ones we presented here should be enough to understand the process of software development, which is impossible without patience, expertise of the team, and mutual understanding.

Top