That makes the outsourcing company both a developer, consultant, and often .... strongly encourage you to use one of the
Table of Contents: 1. Introduction 2. Why do outsourcing? a. Organisation’s culture is the first step 3. Why Scrum? a. How does Scrum work? b. Scrum vs Scrum-but c. To Scrum or not to Scrum? d. Which companies use Scrum? 4. How to choose the right team? 5. The art of cooperation a. How to cooperate? b. Cultural fit c. How to gain trust? d. How to choose the right cooperation model? e. Fixed time, fixed prices, fixed scope f.
Time and Material
g. Agile, Scrum 6. This is an investment 7. Why not to outsource? 8. Useful tips 9. Are your ready ? 10. Want to know more?
2
1 Introduction This is a document which fulfils the need for information. It answers the questions that inseparably go together with modern challenges of running a business. Modern business more and more often creates a vision and influences consumers towards following this vision and the product value it implies. Rather than creating a product alone, it creates a need and value. That’s why this free e-book is for business owners and managers. For decision makers, who need tailored software which realises the initial idea for the application. As the authors of this publication, we believe in Scrum, we are its everyday users. If there’s a need to get familiar with it, this document provides the necessary knowledge and practical tips. We have made it to help decide on choosing the best possible way to outsource software projects. We have also addressed the issue of Agile and Scrum and the very important company’s culture, as a part of natural conjunction between the quality expectations and the final outcome. The envisaged result of reading this document would be a better understanding of the outsourcing itself and the challenges it predicates. The process of making this e-book was based on the knowledge of the topic itself. After researching the common and available knowledge (some of which was used here, along with some graphic materials), we decided on making something of our own authorship. If the Reader knows Scrum already, we suggest skipping the contents and heading straight to section 4. The Authors
3
2 Why do outsourcing?
Outsourcing is today’s prime tool for managing risk, resources, and projects. By outsourcing software development one can find companies which understand the value of the Partners’ business and product, help develop and elevate it, cutting noncrucial functionalities and introducing new ones. That makes the outsourcing company both a developer, consultant, and often business advisor. The other perspective is that over 85% of startups and enterprises have problems with attracting and retaining tech talents1 . And those are just few of the problems companies face within the development field. Outsourcing, a cheaper and more convenient way, solves those problems. Due to this, process costs of HR, maintaining workplaces and leaves, are irrelevant. Moreover, software development is complex and outsourcing companies solely focused on software services are often more effective. Those are merely statistics. Important, but not essential. What really matters is how an outsourcing company will fit into the organisation of the Partner both culture and process wise.
1
Venture Pact 4
Software development outsourcing could be demanding in terms of research, time, and risk. That’s why it’s important to choose the right developer.
Organisation’s culture is the first step To achieve the best results you have to start with the organisation’s culture. What is your culture and what is the culture of the company you want to outsource your development to? But let’s come back to what organisation culture is: this is how it’s done.2 The picture above shows four different organisational cultures.
Schneider's Culture Model, source: http://www.methodsandtools.com/
There is no wrong model of collaboration and culture. Every single model featured above has its own limits, environment, and scope. In Agile, though, collaboration culture is desired. Control is a big no-no, competence is for companies driven by a single goal or set of goals. Cultivation is for visionaries. Collaboration is for… well, everyone. Everyone who is prepared for it, that is. Trust, diversity, partnership - these are the words that fuel Agile projects. If your organisation’s Culture is Control and Competence, does the outsourcing company have a similar one? If your outsourcing company of 2
http://bit.ly/1H7r83H
5
choice has no Culture of Collaboration and your idea is to share the knowledge across in-house and outsource teams, can you make it? If you work in iterations, does the outsourcing company as well? Communication how are you doing it? Through Project Manager, or is the team used to communicate with everyone by themselves? In the process of outsourcing, many Partners find themselves awaken. Developers making the software product can point to new solutions, correct the view on particular functionalities, suggest changes. Forwarding the process to other companies can also free the company’s employees and make time for future endeavours3 . The primary concern regarding software development outsourcing should be minimising functional disjunction. This is the threat of lacking proper communication, project management, and general vision due to geographically dispersed development. Outsourcing everything should be based on the ability to properly manage and receive the feedback, not only the code itself. Working in the same cultural context gives the Partner and Scrum Team the ability to hear the same message that’s getting across, not the words themselves. Project management is equally vital. It means the necessity to attend the meetings (even via Skype or Google Hangouts) by the Partner and Scrum Team. General vision should be respected across the board and influence every part of the project. This is also the case of motivated vs engaged developers. Those motivated by money will be simply making code. Those motivated by creating the best possible business value will overcome the presence of possible disjunction. The best way of making the software work is to make it correctly, with the Partner, all the way. This is the way of Agile, the philosophy of success. It covers the basic principles of everchanging circumstances. Agile developers believe that changes in technologies, trends, and most important - needs of users - demand quick reactions. That’s why they operate on a set of Agile guidelines4 . One of them is Scrum, a framework to organise and optimise the process of development. Quote: ‘Never
was so much owed by so many to so few’. Winston Churchill
3 4
http://bit.ly/1ELHrSX http://bit.ly/17RD3H2
6
3 Why Scrum? The immanent characteristic of software is that it’s open to constant development. Years ago, programmers noticed that traditional methods of making software were less efficient than expected. Then some of the developers started to find more effective frameworks to what they did everyday. Nobody wanted to waste time and money. On the other hand, a popular approach to outsourcing is still the Waterfall: highly structured physical environments in which after-the-fact changes are prohibitively costly. It is a sequential design process in which progress is seen as flowing through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. Once it’s done - it’s done. Changing or shifting things during the period of making the software brings consequences - longer time of making the software, longer exposure to stress produced over the process of change. In Scrum it’s possible to make changes on-the-fly and mandatory to cooperate.
By Peter Kemp / Paul Smith (Adapted from Paul Smith's work at W ikipedia ).
7
A key principle in Scrum is its recognition that customers can change their minds about what they want and need. This allows to recognise the requirements late and cleverly respond to emerging business changes without budget overruns.5 Scrum adopts an empirical approach: a problem cannot be fully understood and defined, therefore the focus should be on delivering quickly and responding to changes. Scrum fulfils the Manifesto for Agile Software Development6, which says:
‘We are uncovering better ways of developing software by doing it and helping others do it’. Through this work, we have come to value:
Individuals and interactions over processes and tools Working software over c omprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Following this come 12 Principles of Agile Software Development7 1.
The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customers’ competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
5
http://bit.ly/1GlOq9S http://bit.ly/1vDH6iO 7 http://bit.ly/1aLadtO 6
8
9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity–the art of maximising the amount of work not done–is essential. 11. The best architectures, requirements, and designs emerge from self-organising teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
How does Scrum work? Software development processes should be built around the three pillars of Scrum method: Transparency, Inspection, and Adaptation. Scrum Team is focused on understanding the Partner’s vision and expectations at first. Customer and Provider become partners in development. Throughout the project, the team is flexible for changes. They use iterative approach, where the Partner gets ‘increments’ of his or her product in less than 30 days that are called Sprints. Developer takes care of the Partners’ investment by avoiding the ‘big design up front’ and ‘technical debts’ traps.
The Scrum Process, source: http://en.wikipedia.org/
Building complex products for Partners is an inherently difficult task. Scrum provides a framework that allows teams to deal with this difficulty. This process is very simple, however difficult to master, especially for young development teams. The process is governed by the three main roles of Scrum Team: Product Owner, Scrum Master, and Development Team. Product Owner takes care of the business value of the product as well as helps in communication with the Partner. Scrum Master provides the right pipeline for communication between all the developers, Product Owner, 9
and the Partner, and makes sure the process supports Transparency, Inspection, and Adaptation. And there goes the Development Team: in Scrum it’s a self-organised team, which delivers a working product every Sprint. The progress of work of the Development Team is transparent and visible to all product’s stakeholders. The main advantage of iterative approach is that the Partner receives a working, and therefore valuable product, every Sprint. In Waterfall, a part of the system can be delivered during the project, but these parts are not designed to give business value before the project is finished:
Waterfall Process, credits: XSolve
In Scrum, Product Owner is responsible for prioritising requirements in Product Backlog for the Partner to receive a (business) valuable working product every Sprint:
Scrum Process, credits: XSolve
Scrum vs Scrum-but Scrum is easy to learn, but difficult to master. And Scrum is the most wanted method in the modern software development. These reasons make some developers unable to deliver Scrum Teams, even if they want to prove they can. Sometimes the Partner can hear software companies saying: ‘Yes, we work in Scrum, but we found that only parts work for us…’. This might be the first signal that such development company didn’t master Scrum. Scrum-but isn’t Scrum and might be dangerous because it puts Scrum Team off the balance and often results in Development being not predictable and not accountable at all. 10
How to check if a given developer really mastered Scrum? Ask for a number of successfully finished projects in Scrum; ask for certificates, ask for experience with Scrum, check their company blog. Ask them how their organisation supports their teams and develops them. Ask them if they have Scrum Coaches. One of the most powerful questions might be asking them what they think about Scrum Retrospective and what value it brings to the Partner. If you don’t have the knowledge to verify that by yourself, we strongly encourage you to use one of the Scrum Experts that can be found here: https://www.scrum.org/Find-a-Scrum-Expert
To Scrum or not to Scrum? Not every project needs Scrum: for some, the natural environment is a more traditional approach, which puts the primary focus on specifications and detailed project plans. For example, the Waterfall method is founded on sequential development model with clearly defined deliverables accompanied by a task plan for every phase.
Comparing Scrum and Plan-Driven, source: http://www.slideshare.net/gerardbeckerleg/
In Waterfall there’s a slim chance of making alterations during the project; it’s very difficult and can cause a lot of problems. Another drawback is that the effect of long-term working is always invisible until the end. In Waterfall everybody must strictly respect the established plan, schedule and changes can be adapted during the product development but it’s a disturbing process, costly and complicated. Therefore, it works for environments where business and technical requirements, technology and deliverables are known, well defined, and do not change throughout the project. The results of the executed projects depend on dozens or hundreds of factors, most of which we do not even begin to realise. Both Scrum and Waterfall are effective if they are applied correctly , suited to the circumstances, organisations, projects, and teams. However, applying the adequate work method to the circumstances is very often extremely 11
challenging and therefore so many Software Development projects fail or face challenges. In most cases, business requirements and technology (API, languages, libraries) may change during the product development. The rule of thumb for such complex projects might be using Scrum as a process framework. In general, the success ratio of Scrum projects is higher than in the Waterfall method8 .
Waterfall and Agile, source: The Chaos Manifesto. http://www.standishgroup.com/
Which companies use Scrum? Intel, Microsoft, Amazon, Salesforce, Google, Yahoo, Facebook, Adobe, Nokia, Siemens, BBC, CNN, General Electric, Bank of America, Novell, Unisys, and many more all over the world.
8
We are showing this example, but the outcome of cases above depends on research methodology and we encourage readers to look into the matter.
12
4 How to choose the right team? The chart below shows the correlation among technology, requirements, and people building a software product. Based on their nature, software projects are complex, rarely complicated. But if a good team is found, ‘complex’ might become ‘complicated’, because most of the times technology is not certain, requirements are not certain, and people are changing. And a good team means a permanent one. They’ve had the time to develop communication patterns. They can provide reasonable increment every single time, in every single Sprint. This can lower the ‘chaos factor’ and a complex software project suddenly becomes just complicated. A great team can build the software from the bottom up9 .
Stacey Graph, source http://pm.stackexchange.com/questions/389/when-to-use-waterfall-when-to-use-scrum
9
http://bit.ly/1EsoWoC
13
Here are some key factors worth considering when looking for the right Scrum Team: ● Knowing and accepting the complicated nature of technology and possible changes in the requirements regarding the product, the team is capable of addressing challenges along the way properly. Can they prove it by showing a number of completed, successful projects? How would they approach a problem if the business needed to change; when would they introduce the change? What is their standard Definition of Done? ● How responsive is the team and to what level does it welcome the changes to the vision, direction, and the code itself? Do they treat email/chat/video communication as a part of the job, or as a distractor from programming? Do they welcome changes during a Sprint and if so, would they later blame you for not delivering the software? Who do they think is able to change requirements besides Product Owner? ● Is the team focused enough on a specific technology? What is their technology stack of choice? How long have they used it? What is their quality process? Can they name the biggest downsides of the development stack? How do they assess if the given technology is able to solve a business problem efficiently? What is their most remembered problem when it comes to the technology, and how did they deal with it? ● Are the members tight together and have they got cohesive skills, or are they a bunch of individuals? Do they understand consequences of the changes in the code provided by themselves and the team10? How long have they worked with each other? How many projects have they left behind finished? In Agile, understanding each other is the key. Can the outsourcing company tell you whether the team assigned to the project will be a project team (the one that is built for the project) or a permanent team? If it is a permanent team, at which stage of teams development is the particular team now?
10
http://bit.ly/1ajdqk1
14
Stages of a team development, source: https://programmentor.wordpress.com/tag/team-development/
● Tuckman’s stages development model11 shows the characteristics of an effective team. In the ‘forming’ stage, team members get to know each other. In the ‘performing’ stage, everything is right in the place. If your team is to be formed for the project, you have to be aware that these stages will affect your project and the velocity of development of your Development Team. A properly formed team becomes a High Performing Team and can be 100% more productive than a Working Group (Forming Team).
‘A collocated self-organising team is 100% more productive than otherwise’ - Boston Consulting Group. ● What percentage of developers have an engineer degree? How many of them can speak English and/or any other popular language? Statistically, developers with higher education and languages are more mature and disciplined, they can bring the software to the end. On the other hand, what are the team members software development years of experience? A reasonable median might be 3 to 6 years. ● Do developers run in the same cultural circles as the Partner? Laughing at the same jokes, understanding the same context and background brings people closer. More importantly, the same context helps developers understand the Partners’ business12 . ● Price. Lower prices don’t mean bad quality, it’s just the geographic, cultural, and economic reality. However, unexpectedly good prices often mean a ‘too-good-to-be-true’ situation and contract. And as a result - the lower quality of the product itself.
11 12
http://bit.ly/1emDuLI http://bit.ly/1MQQaZL
15
5 The art of cooperation
Bespoke craftsmanship, credits: XSolve
How to cooperate? When a decision to outsource is made, there is the matter of how to work with a subcontractor. The goal is to make your project proceed in the right way. Cooperating with the Partner benefits from understanding and trusting each other and not hiding problems . Properly built cooperation is an important factor in achieving dedicated business goals, so it’s important to find the right way of cooperation. Product Owner might be the incarnation of the Partner or may work on the developers’ team side. Product Owner is like the Partner’s eye, ear, and hand. Thus, the Product Owner’s principal task is to take care of the business like it was their own. That’s why this is the first person with whom the Partner needs to build a relationship wisely. If it is possible (and it should be), the Partner should meet Product Owner face to face, it would allow the PO to better represent the Partner’s point of view. However, even if for some reason it’s impossible to meet directly with the PO, there are many ways/tools of constant communication with the PO and the entire team. A good opportunity to meet the team and to familiarise with them is Project 13 Workshop . Project Workshop is the analysis of the Partner’s requirements, vision of the product, its needs and expectations. Does it have an impact on the business value? Of course – the better the team understands the Partner’s needs and requirements, the greater is the chance for the realisation of
13
http://bit.ly/1FgxbFh
16
business objectives. There’s no doubt that well thought software brings the desirable benefits . The first step is to find the right way of cooperation. Software development is a complex and multistage process extended in time. The process binds the cooperation of many people that have to go in one direction. Therefore, all participants must have a sense of community. If you let one another to know your goals, it will be a successful and satisfying journey for all of you.
Cultural fit We must keep in mind that the team is not a set of robots, but a bunch of real people. A team is more than the sum of its members. The Partner should treat the team as confident co-workers . Most of programmers are very ambitious, and if the Partner gains their reliance, they’ll do what they can best and with high commitment. Cooperation should get smoothly through every Sprint and finally they should become well-oiled (moisturised) machinery that works on high speed with high quality. In a few Sprints they are going to work almost without any needless words. But most often it takes some time to upgrade on this level of cooperation. Obviously, it’s easier to work together if the Partner and the provider are culturally aligned to each other. Some of these aspects of cooperation matter a lot and must be highlighted: for example, fluent English and common culture. Insight in the technical and non-technical universum has its importance as well. Do the Partner and the developer have the same ground, laugh at same jokes, can they tackle challenges from the same perspective?
How to gain trust? As in any business arrangement, outsourcing is risky, and here it’s a risk for both parties. The process of building dedicated software is quite complicated and multistage, thus the trust means the desired values. Trust requires a lot of effort and commitment from both sides. Very often at the early stage a business project doesn’t have any specific requirements. Building software is like a journey to a destination you might know, but most often you meet unexpected obstacles and barriers, and sometimes there’s a need to change or to choose another target. Business environment is dynamic, so it’s worth building a team able to adapt flexibly to upcoming challenges. Moreover, a committed team is ready to give advice, not only of technical, but also of business nature. Flexible project management is one of the most useful and advantageous attributes of the Agile approach . 17
To work with the PO and the team is to create the optimal process and habits of working. The other side is to not be dominated by the process. Of course, everyone has to respect commonly established rules, but rules are to serve the realisation of the Partner’s goals, not vice versa. M aking bespoke software that is founded on specific business assumptions one needs to stay
openminded and aware to provide flexible responses to problems which appear . It is
really worth reacting together. In addition, a proper relationship with the team allows the Partner to spectate the creation of the project at every stage: nothing is hidden from the Partner’s eyes. A well synchronised team becomes acquainted with project and the Partner can rely and count on them . So, how to gain trust? Developers should meet with the Partner in person, visit the company. Shower the Partner with questions about the business and the project itself. The more questions will be asked, the clearer the purpose of making the software will become. If the developer doesn’t ask, there might be a reason to be concerned. The next step is the practice of Scrum - holding daily meetings and talking over Sprints is a must. And finally, it’s always best to check the developer under the light of velocity of story points. A developer should always under-promise and always over-deliver.
How to choose the right cooperation model? There are several kinds of cooperation models. Let's take a look at the three which are the most common.
●
Fixed time, fixed prices, fixed scope
The Partner pays only for the order and only within the given time. This model refers to the implementation of a predetermined scope of the project, for predetermined costs, at a predetermined time. The scope of the project is defined during Project Workshop. This model is designed for Partners who are able to fully define their expectations (functionalities), who don't anticipate the impact of any changes in business or ecosystem on the project, and are sure that functional and non-functional requirements will not change for the entire project.
18
● Time and Material This is a body or a team leasing model. Here the Partner pays for the time of the team dedicated towards meeting the goal. In this model the Partner can benefit from extensive capacity of engineers specialised in fields of software development and solution design, web application design, or user interface design. You only pay for the actual time of the service provided. Engineers can be either deployed at the Partner’s company’s location or work for them remotely. This is the most popular model. It's very important that in this model the Partner should have knowledge and experience within the areas of project management, team management, change management, risk management, test management, and design & architecture of IT systems.
● Agile, Scrum This is the model in which the Partner pays for a Sprint, with some Sprints ahead. That’s because the provider cannot guarantee the continuation of the work on the project by a particular team. Choosing another team and then making payment for another Sprint requires the new team to make themselves familiar with the project. The continuation of one team’s work limits the risks. An integral characteristic of IT projects is their complexity. In every IT project, which takes at least several months, there are many request for changes in the scope of work (from 30% to 50%) in response to the changing needs of the business. Agile and Scrum require the competence (know-how) and operational expertise from the developer . During the first meeting with the Partner’s product, vision and high-level requirements are gathered, based on which the division into system functionalities (Product Backlog) is taking place. These functionalities are constantly prioritised by the Partner. Next, there is the planning of a project schedule (Release Backlog). During every iteration (Sprint), according to the priorities, functionalities are created and delivered to the Partner. There’s a need for introducing changes to the project scope during its development. Partners should be encouraged to cooperate in the Scrum model , where changes are natural and can be added between Sprints to Product Backlog.
19
Using the Agile approach is great. Even if the project has some constraints (fixed time, fixed price, fixed scope), with this approach developers can see an improvement in quality and productivity. Fix-time, fix-price:
Time and Material
Scrum:
Generally, it doesn’t fit the Scrum requirements. It’s good when the Partner is up to check on credences of the provider. In this model it’s good to order a short-term, monthly project to see how the provider is performing and then sign a long-term contract in Scrum.
This type of cooperation can satisfy the need for freedom. The Partner doesn’t have to know Scrum and there is no need for him or her to have a Product Owner on his or her side of the business.
I n this model of
cooperation the Partner has the guarantee of delivery after each Sprint but he or she has to know Scrum and needs to have a Product Owner on his or her side.
Main models of cooperation in software development business
20
6 This is an investment Working with a developer in outsourcing environment is demanding, both sides should invest in the relation; developer’s Partner should ask if they are ready for it. The Partner should reserve time for conference calls with the developer, should prepare him- or herself for talking over the potentially problematic points (e.g. adding extra functionalities and impact on future sprints). The Partner isn’t just a Client and we don’t use the word in this e-book even once. The Partner is the vital part of the process and the awareness of that should be there . That also means appointing a Product Owner on the Partner’s side, that will be achieved by talking with the development team and keeping a finger on the pulse of things. Outsourcing is a complex investment, not just buying a ready-to-use thing. But Partners start with a ready-to-use team, and they head together to the designated point - a valuable software product. Therefore, there’s a strong need for special awareness and commitment from the both parties. Such a venture requires something else than the Partner’s money. And the providers shouldn’t represent the ‘take-money-and-run’ approach. The Partner must take under consideration all factors: threats, risks, opportunities, and benefits. A mature development team, with an experienced Product Owner ahead, should serve with all the already acquired knowledge and skills . Below you can find the advantages of outsourced software development: ● Professional team. Self-organised, aware of the Partner’s business. ● Professional consulting: development with on-going notes and remarks regarding possible functionalities. ● ‘Dedicated project management’. Every stage of emerging software has the attention of both Product Owner and Scrum Master; they also stay up-to-date with the Partner’s feedback.
‘An investment in knowledge pays the best interest’. Benjamin Franklin
21
7 Why not to outsource? Outsourcing software development and software services is a great opportunity to scale business, provide high-quality software faster, and focus on core elements of the business instead of developing tools supporting it. But not always. There are certain situations and reasons against outsourcing that should be known before taking the decision. First of all, the Partner might be simply not yet ready for outsourcing. For many entrepreneurs, outsourcing is not only a tool to optimise cost and timeline, but a serious risk of transferring unique product know-how out of the company’s country. Building a trust-based relationship with a developer is the key. Secondly, outsourcing is neither good for the Partner nor for his or her business if he or she doesn’t know Agile software development or doesn’t see any value in it. The Scrum framework, even though it appears to be simple, is a difficult and disciplined approach that ignites change and helps organisation evolve more rapidly with a better risk control, which requires full focus, openness, and courage. If the Partner is not ready to take up the glove - we recommend that he or she doesn’t, although some evangelisation always takes place. Thirdly, outsourcing is always a risk of lower communication and a lack of transparency between a Partner and a developer. Especially if the Partner and developer represent different cultures. If the Partner’s not ready to invest in online communication channels and regular meetings with a subcontractor nor to be asked many questions not only before development, but also during the entire collaboration - we'd rather recommend reconsideration of the aims related to outsourcing. It’s smart to be careful with quality. Although the result of development will be easily visible, the quality of software is usually concealed. It's easier to measure it in the Partner’s own playground than in the developer’s one. Thus, if you are not sure if a developer tests the software properly, it's may be a good idea to look for an alternative . Finally, not only IT companies search for outsourcing opportunities. Perhaps a reader of this e-book represents a different industry and is only looking for a software house to develop and deliver what he or she needs. If so, we're coming back to the trust. 22
Selection tree: when to outscource, credits: XSolve
23
8 Useful tips ● Over 50% of decision makers have difficulties establishing requirements of the project14 . And over 50% of those change them during the development. That is why some tips might be helpful. ● To avoid throwing money and unnecessary delays, the Partner might want to consider a few aspects of the project. It’s worth asking these questions: ❖ What is the subject of the product? (What do we want to do?) ❖ What tools, people, and methodologies do we want to use? (How do we want to do it?) ❖ What happens when all fails? (What is the safety net?) ● Make sure a team you choose takes care of the process of making software as much as you do15 . This directly means that the price should not be a factor. Good and cheaper teams can be found all over the world. Good teams that actively participate in the process are hard to come by. ● Take care of Definition of Done in the contract itself. If the software has passed the required tests, all documentation has been gathered, and software has the previously assumed code quality, DoD has been met. DoD should exist as an attachment to the contract and be established during the negotiations of it. ● Analyse who owns the copyright in the created code and make sure you get the rights to the source code after the release of the software.
‘ Everybody in the real world will agree - the moment a project is behind deadline, quality assurance tends to go out the window’ Alan Cox, British developer, co-author of a Linux core
14 15
http://bit.ly/1qJlek0 http://bit.ly/1FnHsfP
24
9 Are your ready ? Are you ready to have your project made in Scrum? Answer the questions below and find out.
✔ Can you see the value in outsourcing and the direction from where it came?
✔ Can you see yourself working in Scrum with the developer?
Attending periodic reviews, asking questions, actively taking part in the process?
✔ Can you see the reasons why some teams are better suited for
Agile/Scrum projects? Can you see working with them on a project or delegating a Project Manager or Product Owner?
✔ Are you aware of the necessity of having one decision maker for the whole time of a project? Can you see the reason why they can establish contact with you on a cultural level?
✔ Are you aware of Scrum requirements with reference to you as the Partner on the project?
✔ Can you invest time to give feedback to the development team, for instance, when they give you feedback on the new ideas and solutions?
✔ Do you want to follow the changing business environment,
Partners’ expectations, new challenges? Do you want to develop your business continuously? Do you need a scalable product opened to new implementations and features?
‘Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work’. Vince Lombardi
25
Want to know more? Join our free webinar with certified Agile coach:
[email protected]
Credits: This e-book was made under collective effort of XSolve crew:
Piotr Majchrzak
Leszek Pietrzkiewicz
Jaroslaw Scislak
26
Tell us about your software project or the software team you need.
We'll be in touch right away!
[email protected] xsolve.pl/contact/
Managing Director: Piotr Majchrzak Contact details: +48 32 739 09 00
[email protected] http://www.xsolve.pl http://www.xsolve.pl/blog/
See our social profiles to feel the atmosphere around us:
Designed by Chilid Agency This document can be viewed and shared under the license Creative Commons 3.0 BY-NC-ND. http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode
27
