Rolling out large scale IT systems into global organizations

Talk at Charles University Prague.

Transcript

1. ROLLING OUT LARGE SCALE IT SYSTEMS INTO GLOBAL CORPORATIONS Ondřej Krajíček, Y Soft Corporation, a.s. 1
2. ABOUT THIS TALK • When I was studying, I was wondering what the real projects are about. • Today, I would like to share some insight, so that you know what awaits you... 2
3. ABOUT ME • 1999 - 2007 Faculty of Informatics, Masaryk University in Brno (Bc., Mgr. and unfinished PhD) • Institute of Computer Science, System Analyst and Chief Developer • 2007 - 2012 General Manager R&D,
 Y Soft • 2013: Chief Research Officer
 Y Soft & Y Soft Venture Capital • linkedin.com/in/ondrejkrajicek 3
4. ABOUT Y SOFT 4
5. Y SOFT VISION • Build first modern globally operating company without venture capital, managed from the Czech Republic. • Why? • Because we want to show that it can be done and set an example for others. 5
6. Y SOFT PRODUCTS - SAFEQ • SafeQ is a Print Management System • Three major use cases • Measure the volume, costs and ecological impact of printing (incl. device statuses) • Improve security of printing environment (authentication, auditing, non repudiation) • Increase convenience • SafeQ is not a big brother solution 6
7. WHY BOTHER? • 1 ton of paper • 7,2 cubic meters of soft wood • 46 kg of sulphur • 1,2 tons of coal • 112 kW/hours of electricity • 1 liter of toner substance • 266 times more expensive than petrol • ranks among 20 most expensive materials on our planet 7
8. LARGE SCALE SYSTEMS AND GLOBAL CORPORATIONS? 8
9. LARGE SCALE MEANS THAT A CUSTOMER CONSUMES 1 TON OF PAPER IN... (?) 9
10. ONE WORKDAY AFTERNOON (4-6 HOURS) 10
11. WHAT DOES IT MEAN LARGE SCALE? • Thousands of workstations • Hundreds of servers • Tens of thousands of users • Thousands of printers • Millions of printed pages • 1 ton of paper = ? Pages 11
12. WHAT DOES IT MEAN GLOBAL? • Different languages • Multiple time zones • No single service window • Different countries with different legislation • Different business needs to be addressed by a single system • Global collaboration • Users may want to share data on a global scale • Global identity management • Global reporting and data processing 12
13. THE OUTLINE • Winning the customer • Setting up the project... • ...and processes • Building the right software... • ...in a right way • Deployment / Implementation • Acceptance • Lessons to Learn • Summary 13
14. WINNING THE CUSTOMER 14
15. CUSTOMERS NEVER KNOW WHAT THEY WANT, BUT WILL ALWAYS INSIST ON GETTING IT. 15
16. WHAT CAN WE DO ABOUT IT? • Lean Software Development: Build Quality In • What does it mean? • Garbage In - Garbage Out • What does this mean? • It means that quality starts at the beginning. 16
17. TWO THINGS TO REMEMBER 17
18. TWO THINGS TO REMEMBER • If you are good, you deliver what customers want. If you are the best, you deliver what customers need. • What does it mean in practice? • You seek the motivation and the real needs hidden behind the piles of requests and specifications. • You protect your customers from making bad decisions. It is our job as developers / software engineers / architects to find out what the users / customers 18
19. PROJECT SETUP 19
20. BASIC THINGS TO DO • Disclaimer: I am not a project manager (IPMA Certification does not count ;-), but I have participated in roll out of our products to all global major customers on different positions. • What are you goals and objectives? What is the difference between goals and objectives? • How do you know that you have succeeded? • What is your vision? 20
21. On September 12, 1962, at Rice Stadium in Houston, Texas, John F. Kennedy gave America an historical challenge. He said, "the United States was not built by those who waited and rested and wished to look behind them. This country was conquered by those who moved forward." And later, "we set sail on this new sea because there is new knowledge to be gained, and new rights to be won, and they must be won and used for the progress of all people. We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win." 21
22. HOW TO START A PROJECT • Every project needs a vision • Every large customer is different. • Customer is not the only stakeholder. • We will deploy SafeQ to this large customer in 3 countries to open our doors for worldwide cooperation, which in turn will help us in our growth this year. We will create means, tools and learn necessary skills to make it happen. • Vision statement? • Who manages the project? 22
23. MANAGEMENT STRUCTURE Steering committee Managing vs. Doing Things Project Managers Sponsors Project Teams 23
24. HOW TO COMMUNICATE? Communication Matrix Customer
 Project Manager Customer
 IT Manager Customer
 Quality Manager Customer
 IT Administrator Supplier
 Project Manager YES YES YES NO Supplier
 Delivery Manager NO YES YES NO Supplier
 Product Manager NO NO YES NO Supplier
 IT Consultant NO NO NO YES 24
25. WHAT IF SOMETHING GOES WRONG? 25
26. HOW TO DEFINE RESPONSIBILITIES? Responsibilities Project Manager IT Manager Quality Manager IT Consultant System Architecture Document C R A R Scope of Work I A R R Service Level Agreement C A R C Project Plan A C C I Acceptance Criteria I C A R 26
27. HOW TO DEFINE RESPONSIBILITIES? • CAIRO (Consulted, Accountable, Informed, Responsible, Ommitted) • Consulted: whom we ask for his opinion or advice? • Accountable: who has the authority to approve/disapprove the result? • Informed: who is informed on the result? • Responsible: who actually does it? • Omitted: who stands out of the loop? • The trick is to create such map and show it to everybody... • ...so that everybody knows their role and place. 27
28. BUILDING THE RIGHT SOFTWARE 28
29. THE IMPACT OF SPECIFICATIONS • Each major problem in specification (such as ambiguity) leads to approximately 10 wasted man hours. • Each three major problems translate into a major (or more severe) defect in the resulting code. • See http://www.amazon.com/Software-Inspection-Tom-Gilb/dp/0201631814/ 29
30. DEFINING WHAT THE CUSTOMER NEEDS • Good practice is to beging with the system as a black box and capture the customer needs using: User Stories, Requirements, Use Cases • Root Cause Analysis Techniques applied from the beginning 30
31. USER STORIES • Agile Technique to capture user needs as an alternative to (older) Use Cases • What is a user story? • Statement: I as a Role want to do something so that I gain a tangible benefit • Constraints: performance, security, availability, platform, etc. • Acceptance Test: how to evaluate that the user story has been implemented properly - shall be clear enough for developers. • What are the problems? In my experience... • User Stories are often unclear and are abused as a unit of work. • User Stories often omit important requirements from some stakeholders. • What are the benefits? • Good User Stories are test driven - so that the acceptance test(s) are part of the specification. • Good User Stories capture what and why. 31
32. USE CASES • Use Cases • Objectives • Interaction of an Actor with Black Box System (no implementation details disclosed) • Preconditions / Postconditions • Main Flow • Alternate Flow • Recommended Reading: http://www.amazon.com/Writing-Effective-Cases-Alistair- Cockburn/dp/0201702258 • Problems? • Usually no tests. • Too complex for the users to understand. • Usually not in context. • No tests. • What is the purpose of an use case model? 32
33. REQUIREMENTS • What is a requirement? • Usually a statement in a structured language indicating what the actor/system should do. System shall enable users to print their documents on any connected printers. • Problems? • Unclear, not testable, ambiguous • Benefits? • Requirements, if properly structured, can capture all required aspects of a system. • Different kinds of requirements: • Vision, Function, Resources, Budget, Condition Constraints, Design Constraints, ... • Few rules to follow: Identify all stakeholders. Discuss their requirements with them. Do not force stakeholders to follow your structure. Write their requirements for them. The process of writing the requirements and discussing with stakeholders si as valuable and important as the result! • Recommended reading:
 http://www.gilb.com/dl463
 33
34. REQUIREMENTS • Three key properties of requirements • Clear so that they are unambiguous for the intended audience. • Quantified and testable so that we can always measure whether we have succeeded in meeting the requirement. • Contain no unintentional design. • Example: • For the user to perceive the system user interface as responsible, all points of interaction must respond within two seconds. 34
35. BEST PRACTICES • Identify all stakeholders. • Start with user stories - they are understandable to the stakeholders. Make them test driven, so that you have initial specification for tests and acceptance criteria. • Based on user stories, define business processes - i.e. the flows of information and actions between actors and systems. • Individual activities in the business processes shall be detailed using use cases. Actor in one use case can be a system in another. • Based on reviewed user stories, business processes and use cases, define clear, quantified requirements and review them again with your stakeholders. 35
36. ENVIRONMENT • Having standardized environment helps you getting people up to speed quickly. • Prepare development environment, test environment, issue tracking, source code configuration management (such as Git), binary artifact repository, build mangement (Maven, Gradle), versioning / lifecycle. • Imagine the difference between preparing your own test environment for a 10-node clustered system and having a tool to deploy such environment automatically in 5 minutes. • In many agile frameworks, there is iteration 0 intended for these tasks. • Agile Unified Process has a dedicated discipline for Environment. 36
37. QUALITY • What is Quality? • The degree of excellence in something. Durability, Responsiveness, Availability, Intuitiveness, etc. • Is quality important? ;-) 37
38. QUALITY ASSURANCE AND QUALITY MANAGEMENT • Quality Assurance is testing - verifying that the product (software) meets the test criteria. • Quality Management is a process focused on preventing waste, such as defects or unintended features. • Many teams and companies perform QA: at some point of time the specifications and the software is handed over to QA to test it and report defects. This process is performed in iterations to refine the quality of the result. • Is this really productive? 38
40. HOW TO PREVENT DEFECTS? • The biggest defect in a system is when the system does exactly what has been specified, but it still does not fulfill the customer expectations or meet their needs. • Try to identify what are the real needs of your customers / stakeholders. How? • By performing analysis and defining quantified requirements. • Working in iterations and demonstrating prototypes. • By introducing customer advocate in your team (Scrum Product Owner). 40
41. HOW TO PREVENT DEFECTS • Defining and testing constraints early in the process. • Using automated code inspection tools (checkstyle, findbugs, pmd, pmd-cp, etc.). • But beware false sense of safety! • Continuous integration techniques and continuous unit testing. • If you write bad code, your tests probably suck too. • Test-driven development. 41
42. AUTOMATED TESTING • Automated tests are good to improve quality assurance productivity, but does not replace other forms of testing. • How to compensate for the artificiality of the test environment? • Stress test of a print management system: • Software emulation of multi-function printers • Measurement of peak throughput in real customer environment • The tested load for the system was 10x bigger than the peak load, 24x7 for 8 weeks • You need to compenstate for artificiality (because of emulation) by overloading of the system 42
43. DEPLOYMENT / ROLL OUT 43
44. DEPLOYMENT / ROLL OUT • IT Systems are usually implemented / rolled out in several stages: • Experimental Environment Tests • Pre-production Environment Tests • Pilot Run • Roll Out • Each phase is terminated with acceptance tests. 44
45. ACCEPTANCE CRITERIA • The purpose of acceptance tests is to evaluate acceptance criteria. The purpose of the acceptance criteria is to reflect the customer satisfaction. • This means that... • If you are in a state, when your system met the acceptace criteria, but the customer needs are not satisfied, you have probably failed. • That is why you shall have acceptance criteria as part of... • the system specification from the very beginning, • part of the contract (if possible), • verified by the customer on a live prototype as soon as possible. • As well as requirements, good acceptance criteria are quantified and easily testable. 45
46. THE “ACAS” PHENOMENON • ACAS = Acceptance Criteria As a Surprise • Many projects get into the state when it is unclear whether the system works or not. • In such case, the supplier usually tries to define acceptance criteria to quantify the situlation. • This is not a bad idea (if you failed to start with the acceptace criteria at the beginning), but... • You will probably meet with unanticipated customer expectations. • Customer will most probably specify acceptance criteria which you do not meet at the moment. • It is really important to work with acceptance criteria from the beginning. • And remember... • Acceptance criteria are here to streamline the project, not to prevent the customer from expressing their needs. 46
47. THE CHANGE MANAGEMENT • How to change the project when customer realizes that he needs something different. • Believe it or not, these things happen :-). • And it is not a bad thing... for example, the customer needs to change their servers, consolidate into virtual environment, hire more employees, change business processes. • True professionals do not resist the change, they embrace it. • Thus change management... • Change Management is a process of introducing change to a project. Important part of the process is the change impact analysis. 47
48. EMBRACING CHANGE • System specification (such as requirements) to put the change into context and establish its impact. • Traceability between the specification and the system itself (from specification to architecture, design, code, tests and documentation). • Change Management is then a tradeoff between accepting the impact or avoiding the change. Customers are ready to accept the impact if it is communicated properly. 48
49. LESSONS TO LEARN 49
50. HOW TO AVOID A CLICHÉ? 50
51. HOW TO LEARN FROM MISTAKES? • Many teams organize a “Lessons Learned” session to learn from mistakes and implement some improvements. • How would you organize such session? 51
52. RETROSPECTIVES • The goal of this session is to give the team the opportunity to improve on their own. • http://agileretrospectivewiki.org/index.php?title=Retrospective_Plans • Some rules of thumb • Lessons Learned is not evaluation (and definitely not a blamestorm or fingerpointing session) • Always focus on the problem (not a natural way of thinking for Czechs) • Let the team do it • Use faciliator or moderator, not manager • And when we are talking about implementation projects... bring your customers in, if they are interested. 52
53. SUMMARY 53
54. • We have discussed the specifics of large scale and global projects. • I have explained the important things to do before the project starts and omitted many many more... • We have seen some not-that-obvious techniques which might help you do the project right, such as implementing proper environment. • And we have discussed how important it is to set up the project with the end (acceptance) in mind. 54
55. QUESTIONS ondrej.krajicek@ysoft.com 55