Selling Kanban
•
2 j'aime•1,113 vues
How to sell managers, sales teams, and clients on the value of lean and agile processes
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (11)
Similaire à Selling Kanban
Similaire à Selling Kanban (20)
Plus de Paul Klipp, paul@paulklipp.com
Plus de Paul Klipp, paul@paulklipp.com (6)
Dernier
Dernier (20)
Selling Kanban
- 3. Programmers
- 5. Testers
- 11. Sales People
- 13. Agenda Managers Today Sales Teams We will talk about how to sell lean and agile practices to: Clients Lean/Agile Contracts In Addition If we have time, we’ll review types:
- 14. Project Managers
- 15. Project Managers Project Managers
- 18. Dissa=sfac=on Driver for Change Understand the It Involves hours Most projects go PM’s life of meetings over budget
- 19. What can lean/agile offer a project manager? Fast and accurate The opportunity to spend reporting! their days doing more ! More structure! value-adding activities" Shared responsibility Better relationships with Less time spent for success! co-workers and clients! in CYA activities!
- 20. Documenta=on and Planning rt a n expo ary I ca m d oc tor, nt sum er e th As a treatm ail to o nt m p atie ort to e ivers. s. rep reg 8 pt ca John
- 21. Daily tracking !"#$%&'()**+$,( !"#$%&"'&"("#)")'
- 22. Meaningful, Objec=ve Tools 14
- 23. How to Start? 1 Map the value chain and identify Classes of Service 2 Create a visual kanban board 3 Set initial WIP limits (with team and stakeholders) 4 Schedule daily meetings / look for bottlenecks 5 Reflect and adapt using objective measures
- 25. Sales People
- 26. The life of a soNware salesperson Selling the intangible is just selling promises Salespeople may have stats on past projects, but the key selling points are o?en difficult to describe There is a strong temptaBon to oversell, leading to client dissaBsfacBon and low return business and no referral business
- 27. Key points to stress 1 The benefits of lean and agile are easy to understand 2 Happy clients lead to repeat business and referrals Experienced buyers know the cost of poor quality and 3 inexperienced buyers fear it. Quality is an easy sell. 4 You can use the experience as a differenBaBng factor
- 28. Selling Agile Processes to Clients Selling Agile and Lean Processes to Clients
- 29. Key Points to Stress 1 High quality process leads to far lower maintenance costs 2 The client remains in control of the project 3 The client has an enormous degree of flexibility 4 Lean and Agile processes produce lower cost software 5 Considerable insight into the process
- 34. Chaos Report ‐ 2000 64% of all requested features are a waste of money and introduce bugs
- 36. Agile and Lean fix Quality If the triple constraints are Bme/cost, features/scope, and quality then:
- 37. Agile and Lean fix Quality If the triple constraints are Bme/cost, features/scope, and quality then: Sc Sc e – Fixed =me and scope op op Tim project must let e e quality slip because there is always risk – Lean and Agile processes fix quality Quality at the expense of either =me or scope
- 39. Stop when you like Release as Benefits of oNen as you Con=nuous or want to itera=ve Change Deployment vendors easily Control scope
- 40. Sell the Experience The customer is the master of Put responsibility in the hands of those most able to deliver business value Define features using the simplest Planning method that is responsible, Define classes of service and SLAs Development Answer quesBons Demo Review, reflect, feedback
- 53. Your clients have very few points of contact. iniBal sales call recepBonist contract leVer planning status reports meeBngs Make every point of contact into a markeBng exercise. Make every one beVer, and then make them beVer again.
- 56. That’s it!
Notes de l'éditeur
- All right, what I am going to talk about today is selling Agile and Lean development. Selling Lean approaches inside an organization and to external clients. I’m not going to waste any time talking about myself, my background and whatever; you can find me later if you are interested. But I do want to know a little about you so I can tailor this presentation as necessary to your interests. \n\n
- So, first, how many people in this room would describe themselves primarily as programmers? \n
- Testers?\n
- Scrummasters or agile coaches?\n
- Project managers?\n
- And how many of you are in one way or another involved in sales?\n
- So what I am going to talk about is how to go about convincing people inside your organization, especially your Project Managers, to consider adopting Lean practices and principles. How to convince your sales teams that it’s easier to sell a lean process then alternatives and and finally how the sales team can go about communicating the benefits of an lean and agile development to your customers.\n\n
- So what I am going to talk about is how to go about convincing people inside your organization, especially your Project Managers, to consider adopting Lean practices and principles. How to convince your sales teams that it’s easier to sell a lean process then alternatives and and finally how the sales team can go about communicating the benefits of an lean and agile development to your customers.\n\n
- So what I am going to talk about is how to go about convincing people inside your organization, especially your Project Managers, to consider adopting Lean practices and principles. How to convince your sales teams that it’s easier to sell a lean process then alternatives and and finally how the sales team can go about communicating the benefits of an lean and agile development to your customers.\n\n
- So what I am going to talk about is how to go about convincing people inside your organization, especially your Project Managers, to consider adopting Lean practices and principles. How to convince your sales teams that it’s easier to sell a lean process then alternatives and and finally how the sales team can go about communicating the benefits of an lean and agile development to your customers.\n\n
- Okay, so, first, Project Managers. You can’t really begin to speak to a Project Manager about how their life might be different if they had tried a different approach unless we get into the mind of a Project Manager to understand what their world is like.\n
- Okay, that’s been around for a while but I never get tired of it. Has anyone never seen that before? Good. I saw that for the first time back in the days when I hadn’t discovered XP yet. And it spoke to me. So, what is it like to be a Project Manager on waterfall style, traditional project. It’s important to understand that no matter how enamored you are with whatever Agile development approach that people are sitting in the comfort zone which is called the comfort zone for a reason. It is comfortable. Now I use to be a Project Manager on projects large and small using standard, traditional waterfall practices and I’m going to tell you what if feels like. \n\n
- Okay, that’s been around for a while but I never get tired of it. Has anyone never seen that before? Good. I saw that for the first time back in the days when I hadn’t discovered XP yet. And it spoke to me. So, what is it like to be a Project Manager on waterfall style, traditional project. It’s important to understand that no matter how enamored you are with whatever Agile development approach that people are sitting in the comfort zone which is called the comfort zone for a reason. It is comfortable. Now I use to be a Project Manager on projects large and small using standard, traditional waterfall practices and I’m going to tell you what if feels like. \n\n
- Okay, that’s been around for a while but I never get tired of it. Has anyone never seen that before? Good. I saw that for the first time back in the days when I hadn’t discovered XP yet. And it spoke to me. So, what is it like to be a Project Manager on waterfall style, traditional project. It’s important to understand that no matter how enamored you are with whatever Agile development approach that people are sitting in the comfort zone which is called the comfort zone for a reason. It is comfortable. Now I use to be a Project Manager on projects large and small using standard, traditional waterfall practices and I’m going to tell you what if feels like. \n\n
- When a project first comes to you it comes in the form of a group of people or an individual who have some need and some vision and some idea. And you become, for a little while their saviour. You’re the only person they are talking to about this. And they talk to you a lot. So for a large project that might span years, you’re going to be married to the person for three to six months and your job is to write the “Doc”. And writing the document as much as people may dread the idea of that big functional specification, writing the document is a very creative and absorbing process. \n\nAnd so during that time the Project Manager and client and other stakeholders who might be involved spend a lot of time sitting in meetings and when they’re not in meeting they are working on documentation. And what this feels like from a Project Manager's standpoint is a very structured day in which they know exactly what they are doing, exactly what’s expected of them and there are lots of donuts. A lot more donuts in waterfall then in Agile. There’s lots of meetings. And the best part about it is the Project Manager is really in control of the entire process. If you’re talking about like a two year involved multimillion dollar project then the first three to six months the Project Manager is king. He knows where he is supposed to be, he knows what he’s supposed to be doing and he’s creating something of value and because the definition of what a complete functional specification is, is so flexible it is something they have a lot of control over. And so almost in every instance this phase of the project is done on time, on budget and when it’s finished everyone celebrates that their one third of the way through the project and they’re still on time and on budget cause they wrote the book. \n\nAnd that’s when they being to lose control. Talking to a Project Manager about less documentation and such is probably not the best approach. But it’s when they begin to lose control which is when they’ve taken this documentation to the technical teams and they get their first estimates and the technical teams sit down and they break down all the functionality that’s in detail in the document and the tasks and they estimate all of the tasks using whatever mechanism that they use and they come back and they say that these are all of the tasks and these are the dependencies and these are the estimates and they all add up to X which will cost so much. \n\nThen the Project Manager has to take that to the client and the negotiation begins. But even here it’s not that bad because usually there is a discrepancy between what the client expected it to cost and what the client expected it to take in terms of time and what the technical team has come back well there still talking about something that’s really fuzzy, they’re talking about resources as though they weren't people with specific skills and abilities, they’re talking about tasks as though they were real things rather than just an expectation and so once you’ve got all this into your Gantt chart you can still tweak a lot of things. You can toss some more resources on here and take some resources on here and you can make this a little simpler and they estimated that in ten hours but if we just take this thing out we can save the client five hours until they get this thing looking like it’s supposed to. So they’re still somewhat in control. \n\nAnd then it’s when development begins that it becomes very uncomfortable for a Project Manager. Because up until now they know exactly what’s going on with the project. But from this point on they only have one tool for finding out what’s going on with the project. \n\nProject Manager: Are you almost done?\nResource: No, not yet.\nProject Manager: How far along?\nResource: Twenty four hours.\nProject Manager: Like?\nResource: Like that much.\n\nOkay. And that is the essence of the reporting they get for the next nine months. Everything is ninety percent done, almost done, finished my part just waiting on Bob, what have you. And within a matter of days things start to slip just a little bit. And with any large project, if you’ve broken down your Gantt charts into small enough task based components things are slipping within the first week or two. But you still have a lot of things you can work with. You can still shuffle resources in the future. But as the future becomes the present you get less and less flexibility. Luckily you’ve built in a huge buffer at the end of this project. Anyone know what that buffer is called? Testing. Testing is your buffer because come on the project has taken longer than you expected which means the guys have been working harder than you expected so the code's got to be solid, they are not going to find anything in testing anyway. So you budgeted two months for testing but two weeks will have to do. And then of course, when the testers get hold of it and bugs start blossoming and blooming and you’ve got fifty bugs, a hundred, two hundred, four hundred, six hundred. I’ve seen projects with development teams as small as fifty people that were juggling two thousand plus bugs in the bug tracking system. \n\nHas anyone seen that?\n\nAnd then most of the time, according to the Standish group study, most of the time it will go dramatically over and it then becomes the Project Manager's job to try to control and contain the problem as much as possible. Like getting the damn thing shipped before the company goes out of business.\n
- So this is what it looks like to be a Project Manager on a traditional project. What you should approach your Project Manager with is the idea of what it could be like if it was different by tackling the specific issues in which the Project Manager is uncomfortable because you cannot institute change in a person or an organization without first creating or identifying dissatisfaction. So these are some of the things that an Agile or a lean process can give your Project Managers. More structure throughout the process in terms of knowing exactly what they are supposed to be doing. Faster and more accurate reporting rather than sticking their heads into a developer's cubicle and saying “still ninety percent, you’ve been at ninety percent for two weeks now.” You’ve got kanban boards, you’ve got definitions of done, you've got lead and cycle time trend reports, delivery against service level agreements, you’ve got a lean philosophy, you’ve got much better tools for reporting on what’s really happening in the project even in the very early days.\n\nThe opportunity of spending their days doing value adding activities. So the first chunk of the project feels value adding but the creation of this big document doesn’t actually bring any value whatsoever to the stake holders or the end users. But the idea as a Project Manager of spending your days of first creating a document and then trying to cover your ass, instead being responsible for making sure the process is going as smoothly as they can, making sure people are learning from their experiences to make sure the best practices are being followed and removing impediments and creating helpful metrics. These things directly add value to the end user and that can be very satisfying throughout the process. \n\nShared responsibilities for success also means shared responsibility for failure. It takes a lot of weight off a Project Managers shoulders when they have a self-directed team that’s taking responsibility when they are working closely with a client and the client is sharing responsibility for helping to identify and solve problems as the project progresses. Better working relationship with clients and co-workers. Instead of having a client who they are constantly making excuses to or constantly answering very uncomfortable questions and having a bunch of co-workers who they have to micromanage and put pressure on and motivate. Instead they are facilitating, they’re solving the problems, they’re part of the solution, they’re part of the team which makes for much better more comfortable working relationships and as I said less time spent trying to cover their ass or their company's and instead working on solving problems rather than finding blame. \n
- The high level view of what’s different for a Project Manager in an Lean and Agile project the primary role is facilitation. Right now the primary role is reporting. Facilitation is a much more comfortable and much more meaningful role to have. Less upfront planning and more ongoing planning. So instead of spending three months writing documentation and the rest of the time trying to keep it from completely becoming a train wreck they’ll be constantly involved in working with ongoing planning. Less subjective reporting and a whole lot more talking and real, objective metrics. A big chunk of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly update meetings and what have you and instead of creating all of these reporting documents they will spend a lot more time talking to the team and a lot more time talking to the clients in structured ways that keep everybody on the same page. \n\nFewer long meetings and more short meetings. So it’s not that they are being relieved of the responsibility for meetings and it’s certainly not that “oh my goodness I am trading six meetings for six hundred meetings.” Generally speaking, in my experience, total commitment is about the same. Instead of having those four hour, six hour and eight hour long meetings that go on for weeks at the beginning of the project they have a fifteen minute meeting every single day plus periodic retrospectives and planning meetings. And like I said less time trying to avoid blame and more time acting in a real problem solving capacity. \n
- The high level view of what’s different for a Project Manager in an Lean and Agile project the primary role is facilitation. Right now the primary role is reporting. Facilitation is a much more comfortable and much more meaningful role to have. Less upfront planning and more ongoing planning. So instead of spending three months writing documentation and the rest of the time trying to keep it from completely becoming a train wreck they’ll be constantly involved in working with ongoing planning. Less subjective reporting and a whole lot more talking and real, objective metrics. A big chunk of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly update meetings and what have you and instead of creating all of these reporting documents they will spend a lot more time talking to the team and a lot more time talking to the clients in structured ways that keep everybody on the same page. \n\nFewer long meetings and more short meetings. So it’s not that they are being relieved of the responsibility for meetings and it’s certainly not that “oh my goodness I am trading six meetings for six hundred meetings.” Generally speaking, in my experience, total commitment is about the same. Instead of having those four hour, six hour and eight hour long meetings that go on for weeks at the beginning of the project they have a fifteen minute meeting every single day plus periodic retrospectives and planning meetings. And like I said less time trying to avoid blame and more time acting in a real problem solving capacity. \n
- The high level view of what’s different for a Project Manager in an Lean and Agile project the primary role is facilitation. Right now the primary role is reporting. Facilitation is a much more comfortable and much more meaningful role to have. Less upfront planning and more ongoing planning. So instead of spending three months writing documentation and the rest of the time trying to keep it from completely becoming a train wreck they’ll be constantly involved in working with ongoing planning. Less subjective reporting and a whole lot more talking and real, objective metrics. A big chunk of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly update meetings and what have you and instead of creating all of these reporting documents they will spend a lot more time talking to the team and a lot more time talking to the clients in structured ways that keep everybody on the same page. \n\nFewer long meetings and more short meetings. So it’s not that they are being relieved of the responsibility for meetings and it’s certainly not that “oh my goodness I am trading six meetings for six hundred meetings.” Generally speaking, in my experience, total commitment is about the same. Instead of having those four hour, six hour and eight hour long meetings that go on for weeks at the beginning of the project they have a fifteen minute meeting every single day plus periodic retrospectives and planning meetings. And like I said less time trying to avoid blame and more time acting in a real problem solving capacity. \n
- The high level view of what’s different for a Project Manager in an Lean and Agile project the primary role is facilitation. Right now the primary role is reporting. Facilitation is a much more comfortable and much more meaningful role to have. Less upfront planning and more ongoing planning. So instead of spending three months writing documentation and the rest of the time trying to keep it from completely becoming a train wreck they’ll be constantly involved in working with ongoing planning. Less subjective reporting and a whole lot more talking and real, objective metrics. A big chunk of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly update meetings and what have you and instead of creating all of these reporting documents they will spend a lot more time talking to the team and a lot more time talking to the clients in structured ways that keep everybody on the same page. \n\nFewer long meetings and more short meetings. So it’s not that they are being relieved of the responsibility for meetings and it’s certainly not that “oh my goodness I am trading six meetings for six hundred meetings.” Generally speaking, in my experience, total commitment is about the same. Instead of having those four hour, six hour and eight hour long meetings that go on for weeks at the beginning of the project they have a fifteen minute meeting every single day plus periodic retrospectives and planning meetings. And like I said less time trying to avoid blame and more time acting in a real problem solving capacity. \n
- The high level view of what’s different for a Project Manager in an Lean and Agile project the primary role is facilitation. Right now the primary role is reporting. Facilitation is a much more comfortable and much more meaningful role to have. Less upfront planning and more ongoing planning. So instead of spending three months writing documentation and the rest of the time trying to keep it from completely becoming a train wreck they’ll be constantly involved in working with ongoing planning. Less subjective reporting and a whole lot more talking and real, objective metrics. A big chunk of the Project Managers job is writing weekly reports or monthly reports or sitting in monthly update meetings and what have you and instead of creating all of these reporting documents they will spend a lot more time talking to the team and a lot more time talking to the clients in structured ways that keep everybody on the same page. \n\nFewer long meetings and more short meetings. So it’s not that they are being relieved of the responsibility for meetings and it’s certainly not that “oh my goodness I am trading six meetings for six hundred meetings.” Generally speaking, in my experience, total commitment is about the same. Instead of having those four hour, six hour and eight hour long meetings that go on for weeks at the beginning of the project they have a fifteen minute meeting every single day plus periodic retrospectives and planning meetings. And like I said less time trying to avoid blame and more time acting in a real problem solving capacity. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- So this first step is building the right team. And this is a topic for a whole other presentation. You can tell your Project Manager that if they put together the right team for the project then the whole rest of the job becomes a whole lot easier. Picking the right people with the right set of skills with the right personalities to work together. And then helping them to understand the problem that needs to be solved. This is something I love about the software industry. My very first management experience was working in prison and a couple of years my job was cooking food for a fifteen hundred inmates and my team was a bunch of rapists, murderers and drug dealers. And after that then going to software where suddenly I’m surrounded by people who are more intelligent than me, it’s terrific if you help and get the team on board with what it is that they’re trying to solve, the problems that the customer’s trying to have. You harness all of that brainpower and then them from code monkeys, fulfilling tasks on the Gannt Chart into part of a creative solution to problems and then give them space, time and the structure and sources they need to do their job and you get a motivated team and you don’t have to have all-night pizza debugging sessions or threaten or cajole or whatever in order to try to accomplish the client’s purposes and your purposes. They’re motivated themselves because they're emotionally connected in what you’re doing. \n
- \n
- There’s still planning and using a kanban approach doesn't require that you change anything that's working for you already, but it does open the door to more streamlined, real-time planning. Identifying classes of service lets you also set rules for planning based on class of service, so that you can adjust the amount of time and effort involved in task planning to the value delivered.\n\nIn terms of documentation instead of the the huge piles of documents to manage and piles of reports to manage but there’s a lot more conversations to manage. The big visible charts like the kanban board which allow everyone to see exactly what’s going on in the project. \n\n
- In terms of daily tracking, they’ve got these stand-up meeting, instead of sticking their heads into cubicles. They’ve got the kanban boards which gives them really accurate data that they don’t have to go and wrangle out of the heads of the programmers. They get to actually see features as they’re being finished and they get to see them with clients and get real time feedback. \n\n
- \n
- And they also get a set of tools like the cumulative flow diagram, lead and cycle time reports and such that they can use to identify weak areas in the process and see objective evidence of continuous improvement.\n\nSo once the project manager says that sounds really good, that’s the kind of life I would like to be living with my family and in this workplace with all of you, how do I do it? There’s a school of thought that will dramatically disagree with my who says that the only way to introduce new processes is doing it with a professional coach who can make sure the team doesn’t make any common mistakes leading to bad experiences and scrapping the idea entirely and they have a point. I’m sure that happens in some organizations. All of my experience leads me to believe that taking your best shot at it, as long as you do it with an open mind, leads to enough improvement to create a continuous cycle of improvement. So it will take longer without bringing in an expert coach but I believe that the best way to start doing a lean or agile process is you take project, you get a good small team – preferably something that’s internal, maybe something that’s not being too highly scrutinized by the outside for your first few months. \n
- anyone's delighted with the status quo, you'll have trouble initiating change. Chances are, on most software projects, everyone will agree that quality, or reporting, or efficiency could be better. Decide together what you want to get out of the change initiative, whether it's better visibility, lower defects, continuous or more frequent deployment, just make sure everyone has the same goals.\n\nMap the real value chain, not the ideal one. Identify all the steps that requests go through before they become finished, released features. Decide what to call all the things a team work on, such as planned features, stakeholder requests, bugs, livesite emergencies, etc. Talk to stakeholders about how each of those types of work should be handled in terms of priority, delivery speed, approval. Create a kanban board based on the value chain map. You can use a physical board, an electronic board like Kanbanery, or both. The benefit of a physical board lies in it's high visibility, simplicity of use, and flexibility. An electronic board offers ease of access, especially for non-co-located teams or remote clients and it makes tracking metrics much easier as most calculations and graphs are produced automatically. Agree as a team on initial work in progress limits. Involving the stakeholders in that conversation is helpful so that they understand the reason for WIP limits and are more likely to respect them in the future. This is a good opportunity to explain the implications of Little's Law and why reduced WIP leads to shorter lead times and more frequent releases. If that's a stretch, it doesn't take a genius to understand that one guy does one thing at a time better than he does five things. I've worked with teams new to kanban who have set high initial WIP limits and those who have set very low initial WIP limits. There are arguments for both approaches. Low initial WIP limits put stress on the team faster and lead to more rapid improvements, but painful ones. High initial WIP limits are more comfortable, but it will take longer for the team to find an ideal cadence. Therefore, if the team is really committed to improvement through kanban, I prefer low initial WIP limits, but if they are lukewarm about it, or suspicious, then high initial WIP limits are better. Schedule a standup meeting to review the kanban board at the same time every day and invite the stakeholders to observe. Agree on an initial schedule for releases and reviews, which can be based on the team's current release schedule. Schedule a date to hold a retrospective meeting. Then, on that date, sit together as a team, review the period's metrics and reflect on what that felt like and try to identify areas for improvement.\n\nIf you do that and you do it with an open mind with a group of intelligent people that want to see it work, I believe you’ll see dramatic improvements in your process. I've heard it said, and I think I agree, that any team that’s intelligent and open minded and does retrospectives will eventually come across Agile process whether they’ve been trained in it or not. There’s so much in it that’s just common sense. Lean practices are somewhat less intuitive, but once introduced, again to intelligent people open to change, they are likely to see the value quickly.\n
- Now, selling Agile to sales people. \n
- Sales in software is really, really difficult mostly because sales people are not technical and what they’re selling needs to be a very technical thing, software. And so not being able to clearly understand the technology they start selling software but what they’re actually selling is a service. And how do you sell software? It’s kind of like ‘we need it to do this.’ You say okay and I need to do this too. And you say ‘sure, our guys could do that.’ And I need to have it before Christmas. We’ll make it happen, buddy.’ Without really necessarily understanding what goes into the promises they’re making, you’ll end up with that Dilbert kind of scenario in which marketing makes the promises and then maybe come in with the problem and then somehow or other either has to solve the problem or again, as Standish Group's studies reveal, usually they fail. I think one of the big areas in which projects collapse is because when the contract is signed most sales people get their commission and then they’re done. \n\nWell again, think about what motivates sales people. Mostly it’s that commission or a person involved in sales is also an owner or senior manager in the company so their interest in the company is success. Nothing brings higher commissions or more success than repeat business and good references and so creating a great customer experience leads to repeat business or leads to customer recommendations and referrals is a great way to automate the sales process. If you do this well enough long enough you can stop selling altogether, people will be pounding on your door to ask you to build their software for them, which is essentially the situation that I find myself in now. I do no marketing anymore. \n
- So what generally you should be telling the sales people is that the benefits of an Agile and lean process are easy to understand – and we go over that in the next segment – that happy clients bring repeat business, that experienced buyers know the cost of poor quality because they’ve seen cost overruns, they’ve seen budget overruns and they’ve seen the enormous maintenance costs that come from overly complex projects that are poorly architected and that have spent the last several months of their life being cobbled together by a bunch of unpaid interns because it was so far over budget that nobody wanted to put a good team on it and they just had to get the darn thing done. Then it cost a fortune to maintain so it’s eventually scrapped. If they’re experienced they’ve seen this and they fear it and if they’re inexperienced they’ve heard the stories and they fear it. \n\nSo if you can sell quality, quality in process, that addresses that fundamental fear most clients have and you can sell the experience of being a purchaser of an Agile and lead software service, the experience of being a product owner as a key benefit, the key differentiating benefit, which is a rather easy sell and this is how you do it. \n
- For clients, the main points you want to make to the clients – and I’ll explain these in a bit more detail – \n
- is that a high quality process leads to lower maintenance cost, to a lower full cost of ownership. The client remains in control of the project. Clients are not used to having any measure of control at all once a software project is initiated. That they have greater flexibility. Most clients have experienced the dreaded change requests. How many of you are in companies where a client has to submit a change request for evaluation? That’s a horrible experience for a client to have a great idea and toss it into a bureaucracy of grumbling managers and programmers who all say this is going to screw up everything. So the idea that they can get new ideas and incorporate them into the process or if the competitor comes up with a great new feature that they didn’t think of they can do that without going through that process. It’s very compelling. \n\nThat Agile agile and lean process minimize waste and lead to lower cost software.\n\nAnd that they have a lot of insight into the process so they’re not going to be stressed about what’s going on. \n\nLet’s take a look at how your clients think about software. \n
- How many of you have seen this video? What you’re about to witness is a buffer overflow. Okay, I can go on and give a list of all the big catastrophic software failures. Google the term ‘famous bugs’ and you come up with a list of all the projects where software bugs killed people with radiation overexposing and things like that. But even closer to home, just take a look at the software that your clients use every day. I remember a time – and anyone my age or older will remember a time when a perfectly good, fully functional word processor that did everything you needed with advanced formatting and mail merge and everything fit onto a 360K floppy and now it takes a DVD to hold all 4.7 gig of Microsoft Word and you still have to download patches every week. Software in general is faulty, awkward, difficult to use, bloated, buggy and full of security holes. This is the kind of software that’s written by some of the best minds who have been working on it for years and it’s in widespread use worldwide. Just think how a custom project would look compared to that with a fraction of the testing and a fraction of the real world usage. \n\nCustomers expect the software that you write for them to suck even worse than the stuff they use every day and when somebody expects software to suck the natural thing to do is to not pay any more for it than they have to. So this is the problem that you’re running into. They expect to have a miserable experience of throwing their ideas over a wall and then getting a bunch of excuses back and then finally having to force the project out however it is that they can get it with no other tool at their disposal than\n
- How many of you have seen this video? What you’re about to witness is a buffer overflow. Okay, I can go on and give a list of all the big catastrophic software failures. Google the term ‘famous bugs’ and you come up with a list of all the projects where software bugs killed people with radiation overexposing and things like that. But even closer to home, just take a look at the software that your clients use every day. I remember a time – and anyone my age or older will remember a time when a perfectly good, fully functional word processor that did everything you needed with advanced formatting and mail merge and everything fit onto a 360K floppy and now it takes a DVD to hold all 4.7 gig of Microsoft Word and you still have to download patches every week. Software in general is faulty, awkward, difficult to use, bloated, buggy and full of security holes. This is the kind of software that’s written by some of the best minds who have been working on it for years and it’s in widespread use worldwide. Just think how a custom project would look compared to that with a fraction of the testing and a fraction of the real world usage. \n\nCustomers expect the software that you write for them to suck even worse than the stuff they use every day and when somebody expects software to suck the natural thing to do is to not pay any more for it than they have to. So this is the problem that you’re running into. They expect to have a miserable experience of throwing their ideas over a wall and then getting a bunch of excuses back and then finally having to force the project out however it is that they can get it with no other tool at their disposal than\n
- How many of you have seen this video? What you’re about to witness is a buffer overflow. Okay, I can go on and give a list of all the big catastrophic software failures. Google the term ‘famous bugs’ and you come up with a list of all the projects where software bugs killed people with radiation overexposing and things like that. But even closer to home, just take a look at the software that your clients use every day. I remember a time – and anyone my age or older will remember a time when a perfectly good, fully functional word processor that did everything you needed with advanced formatting and mail merge and everything fit onto a 360K floppy and now it takes a DVD to hold all 4.7 gig of Microsoft Word and you still have to download patches every week. Software in general is faulty, awkward, difficult to use, bloated, buggy and full of security holes. This is the kind of software that’s written by some of the best minds who have been working on it for years and it’s in widespread use worldwide. Just think how a custom project would look compared to that with a fraction of the testing and a fraction of the real world usage. \n\nCustomers expect the software that you write for them to suck even worse than the stuff they use every day and when somebody expects software to suck the natural thing to do is to not pay any more for it than they have to. So this is the problem that you’re running into. They expect to have a miserable experience of throwing their ideas over a wall and then getting a bunch of excuses back and then finally having to force the project out however it is that they can get it with no other tool at their disposal than\n
- volume based motivation. If you can give a guy who's used to dealing with the software company in this way where there’s cost overruns and they’re not satisfied in the way in which the product works, an alternative which is compelling, a positive experience in which they are in control and get what they want, they will choose it every time.\n\n
- More code leaks, more bugs, the best way to produce errors is to write less code – \n\n
- you’ve seen this? Everybody using this stuff? This is an old study. This is from the 2000 study. My goodness, we should all know this. By the way, side note, never ever trust the conclusions of any study you haven’t read, really! The number of times that I’ve seen some study quoted in the press and I go and I read the study and the press expressed the conclusions that was not what the study was about at all. Go to the site and see the report. It takes about a half an hour to read, it’s not a big read and very enlightening and the projects they use in the study may have nothing whatsoever to do with the kind of work that you’re doing. But in any case, obviously the best way to produce less buggy, less complex software faster and cheaper is just to write less of it.\n\n
- you’ve seen this? Everybody using this stuff? This is an old study. This is from the 2000 study. My goodness, we should all know this. By the way, side note, never ever trust the conclusions of any study you haven’t read, really! The number of times that I’ve seen some study quoted in the press and I go and I read the study and the press expressed the conclusions that was not what the study was about at all. Go to the site and see the report. It takes about a half an hour to read, it’s not a big read and very enlightening and the projects they use in the study may have nothing whatsoever to do with the kind of work that you’re doing. But in any case, obviously the best way to produce less buggy, less complex software faster and cheaper is just to write less of it.\n\n
- you’ve seen this? Everybody using this stuff? This is an old study. This is from the 2000 study. My goodness, we should all know this. By the way, side note, never ever trust the conclusions of any study you haven’t read, really! The number of times that I’ve seen some study quoted in the press and I go and I read the study and the press expressed the conclusions that was not what the study was about at all. Go to the site and see the report. It takes about a half an hour to read, it’s not a big read and very enlightening and the projects they use in the study may have nothing whatsoever to do with the kind of work that you’re doing. But in any case, obviously the best way to produce less buggy, less complex software faster and cheaper is just to write less of it.\n\n
- you’ve seen this? Everybody using this stuff? This is an old study. This is from the 2000 study. My goodness, we should all know this. By the way, side note, never ever trust the conclusions of any study you haven’t read, really! The number of times that I’ve seen some study quoted in the press and I go and I read the study and the press expressed the conclusions that was not what the study was about at all. Go to the site and see the report. It takes about a half an hour to read, it’s not a big read and very enlightening and the projects they use in the study may have nothing whatsoever to do with the kind of work that you’re doing. But in any case, obviously the best way to produce less buggy, less complex software faster and cheaper is just to write less of it.\n\n
- Another compelling and clear argument for the value of a continuous or regular deployment process is that the core features get tested more often. That's not rocket science. Clients can understand that.\n\n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- I have always liked talking about the triple constraints a little bit differently than everybody else does because I’ve seen what happens when a company starts losing money every day because the project is over budget, it’s fixed price and what-have-you and they start taking their best people off because it’s too expensive and they start working long hours when people don't do their best work and such. So these are the constraints: the amount of time it takes to do it, what gets done and how high quality it is, because it’s quality that suffers when you start trying to finish a project that’s so over budget. This is the kind of thing that a client can understand. You can tell this to a customer and they get it, which is that if you want to force a fixed time and fixed scope contract on somebody you are going to sacrifice quality and you always pay for quality in the end, you always do. \n\nMy father used to say something about used cars, and this is a bit dated but he used to say a used car costs you $1000. You can either buy one for $100 and it’s going to cost you $900 to get it running smoothly or you can buy it for $1000. Same thing with software except I think even more exaggerated, its poor quality costs far more later on than building in quality would cost. So you sell them that idea of getting what they can afford, the best software that they can afford without all of those maintenance costs. It’s a very, very compelling argument. One of the things that I’ve found is if you do a convincing enough job, selling something, especially if you have clients coming to you and saying we’re putting this out to bid, we’d like you to enter a bid, we’re talking to 20 other software companies. If you can get them on the phone and you can talk to them the way I’m talking to you right now and you can get them nodding their head and saying yes, yes in fact I would like is control, I would like high quality and I would like a process that’s transparent and the next thing that happens is they get 19 proposals in from other companies who’ve just filled in the proposal like they always do based on the RFP but that’s not what they’re looking for anymore. What they’re looking for is this experience, that delivers high quality software in the way that keeps them in the driver’s seat and you’re not even competing against them anymore. You’ve already won because the business changed, the request has changed. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- Continuous delivery is a great selling point. The main things that I like to talk about with clients is one you stop when you want to. This may be – I once had a client who stopped just a few iterations into a project because he was trying to create something that was already operating in a larger market and that company moved into his market and he realized he just couldn’t compete so he stopped. Sometimes clients stop, in fact usually clients stop because they’re done. My experience is that customers who do come to me with a functional specification or a list of a hundred features they want generally are happy and cancel the project and release when they have about 80% of those features done and some other things that they thought of along the way. So the idea that they can release when there’s enough value to release. What’s more, you can also get early releases if you want to. If you’re building a big accounting system with hundreds of features for your whole accounting department but at the end of the second iteration it generates this one report that Bob has to run every Friday and it takes him a whole day to get the numbers together and now it’s automated, if eight hours a week of Bob’s time is worth more to you than the cost of deployment then you can go ahead and deploy that product as it is and all of a sudden Bob is really happy and is using your product and giving you valuable feedback and becoming an enthusiastic supporter of the project. \n\nYou can change vendors easily. This makes some people uncomfortable but the fact of the matter is that right now you’re just trying to get a customer to make a decision and the biggest fear is that they’re going to be tied into a never ending relationship with the wrong person because they don’t know until they’re well into their commitment whether or not you’re actually capable of doing what you said you were going to do. So when you tell them typically when you do a big project halfway through it if you pick it up and take it to another team you’re going to have a bunch of half finished features, you don’t know what the quality of the project is and most of the time the other team will say we can’t work with this, it’s too complex, it’s not tested well enough, there’s a bunch of half finished features that we don’t know what they’re supposed to do, a bunch of code we don't understand. You’re better off just writing it from scratch and you can trust us, we won’t do to you what just happened. Of course they will. \n\nBut when you're releasing production quality work on a regular basis you’ve got something you can take that code to another team if for some reason the first team goes out of business or you’re not satisfied with the relationship or whatever you can take it to another team and say this is a piece of software, it works, it’s fully functional, there’s nothing half finished in this, there’s not spaghetti code, we just need you to add these ten more features to what’s already there. It’s a much easier thing for them to do with another client so this makes your customers feel very comfortable.\n\nAnd finally, they have control over the scope. Clients don’t often know that this means they can pull things out. That’s not what they’re thinking but being able to put these things in without causing a complete disaster and going through that big bureaucratic change request process is very comforting for a client. \n
- And then you can sell them on the experience – what they’re going to be doing, what their role is and the fact that they’ll have a role. A lot of clients don’t realize once the planning process is over, they’re not used to having any role other than receiving reports and getting on the phone and yelling at the project manager when it looks like things aren’t going well, even though that doesn’t actually accomplish anything. Having that kind of ongoing role in which they get to meet every single human being who’s coding on the project, they get to see features and give immediate feedback to make sure everything is done right from the start as opposed to getting something at the end they’re not fully satisfied with is really exciting and compelling and it can be the huge differentiator if your competitors are not doing this. \n\nSo they’re the ones who are going to be living this project for the next month, six months, year, two years, however long it’s going to be. Let them know that their life is going to be good. It’s going to be positive, it’s going to be pleasant, it’s going to be social, it’s going to be informed, they’re going to be part of the process. They're going to know what’s going on they’re going to have control. If you’re your competitors aren't doing that, you've won the sale already because everyone fears what the next months or years are going to look like in their life with a waterfall project. \n\nAll right, so more general observations about sales in general that I just want to share. \n
- \n
- One, a lot of people try to sell the technical expertise. If you’re on the phone with the client, they’ve already decided that your qualified. Most clients are not competent to assess your abilities as a development company. What clients are incredibly good at is figuring out if you’re paying attention to them, whether you understand them and whether you care about them. So when the time comes to make a decision between one or another service provider, that’s going to be the deciding factor, not the guy who’s got 100 years combined experience but the guy who gets them, has some ideas and has some enthusiasm and can communicate with them and value them. \n\n
- Another point that I’ve noticed over the years of working with other software companies is I like to create cooperative competitive environments wherever I work. If that’s internally within the ecosystem companies might compare themselves to each other but it’s not very helpful when you do that with your customers, when you say we are great because we do this and everybody else does this or we are better than them because we have more people, we have more experience or what-have-you. Because your biggest competitor is not the other team down the street, \n\n
- you’re biggest competitor is that the client is afraid that none of you are any good because everything they know about the software development experience was very negative and maybe it would be better if you were in-house or maybe \n\n
- it would be better not to do it at all. \n\n
- \n
- \n
- So I encourage people to focus on one thing they’re really good at, one thing – and I think the experience of being a client in an Lean and Agile process where the quality differentiation can happen. When you focus on the quality rather than fixed scope, fixed time engagement is a poor differentiator rather than trying to compare yourself to others. \n\nSo get one thing to stand out. It’s another mistake that sales people across service industries always make is they say you should choose us because this, this, this, this and this. When everyone is saying that to a person making purchase decision they end up saying there’s 10 things good about this company, there’s 20 about this company, there are 6 things that are good about this company and they don’t remember any of them. But if you tell a client one thing, one real compelling differentiator and you drive it home with everything that you do, whether it’s quality, quality, quality or control, control, control or fun, fun, fun or whatever it is.\n\nIn my case it’s fun. I’ve had customers – this is a funny story and it leads into my next slide. I had a customer once I asked him what his budget was to build what he wanted to build and he said I’m not telling anybody my budget because I’m afraid you’d spend all of it. I said that’s no problem, I’ll find out because in my experience if you make the software building process fun and engaging and the client really enjoys how easy it is to get their ideas and turn them into reality they’ll spend every last penny they have. So their budget is what they’re going to end up spending. \n\nOne of the things that we’ve done in my company and we’re doing now, which is kind of funny is we’ve actually bought a hostel and we’ve outfitted a hotel room in it for our customers to stay there on the theory that when they come to visit us they don’t have to pay for a hotel they’ll end up putting that money into the software development too. \n
- Lastly, be honest with clients, talk simply, don’t try to overwhelm them. Don’t use jargon. For example, let’s say you want to hire a house painter to paint your home and I come to you and say you should choose me because I’m committed to excellence. Jargon goes in one ear, out the other and actually lowers the credibility of whoever is saying it whereas if you can just be honest and open, expose your flaws. I’ve had clients ask me how do you guarantee that you’ll complete this within the estimate and I say I can’t. We’ve done over a hundred projects now and I’ve got some real doozies under my belt that have blown the hell out a budget. But what we found is of all of these projects I’ve had four that have gone dramatically over budget, more than 15% and three of them have almost doubled budget, and the one thing that they all had in common is they were all really small projects. They were projects that were originally estimated at two to six weeks so what we’ve learned from this is we really, really suck at estimating small projects because there’s just too many factors that can influence it and not enough time to adapt. \n\nAnd the client then trusts me, unless they have a very small project, then they don’t trust me. Or least, even if you do have a small project and you hear that and I say you know I've had projects this small go 200 percent over, but everybody else is saying, no, right on the money, our estimates are always correct because we’re committed to excellence. Then they’re still more inclined to trust me and not believe those other people. Because if a guy like me can have three projects go dramatically out of budget, then how can all these other people be doing everything exactly right? So be honest with your flaws, talk simply, use plain English, and don’t try to use jargon. It doesn’t work, yes, tell them straight through without embellishment.\n
- Your prospect is overwhelmed with options and details. Give them less to think about and they will trust you more. Give them one, just one, good reason to choose your service.\n
- Okay, oh, and the last important point is a lot of people make the mistake of thinking that when they’ve got the signature on the contract they won, that the client had some of their infinite wisdom look through all of the options and said, you guys, you are the best possible development partner for this project. But that’s not what’s happened at all and it leads to some of the biggest problems that people have with their clients during the first weeks or months of a project. And the problem is this. When the client’s signing a contract they’re not saying you guys are the best. What they’re doing is they’re saying, okay I’m willing to do a huge favor and give you guys a chance to prove that you can actually pull this off. \n\nAnd it’s a huge favor the client is doing when you're talking about a software project. Because they’re not going to start realizing value to even with an lean/agile process for weeks and they’re committing a lot of time and energy and resources and actual money to you. And so you’re starting the project with the balance on their side. They have given you something, their giving you a great deal of trust, they’ve made a big commitment in you and they expect you to appreciate that. \n
- Okay, oh, and the last important point is a lot of people make the mistake of thinking that when they’ve got the signature on the contract they won, that the client had some of their infinite wisdom look through all of the options and said, you guys, you are the best possible development partner for this project. But that’s not what’s happened at all and it leads to some of the biggest problems that people have with their clients during the first weeks or months of a project. And the problem is this. When the client’s signing a contract they’re not saying you guys are the best. What they’re doing is they’re saying, okay I’m willing to do a huge favor and give you guys a chance to prove that you can actually pull this off. \n\nAnd it’s a huge favor the client is doing when you're talking about a software project. Because they’re not going to start realizing value to even with an lean/agile process for weeks and they’re committing a lot of time and energy and resources and actual money to you. And so you’re starting the project with the balance on their side. They have given you something, their giving you a great deal of trust, they’ve made a big commitment in you and they expect you to appreciate that. \n
- Okay, oh, and the last important point is a lot of people make the mistake of thinking that when they’ve got the signature on the contract they won, that the client had some of their infinite wisdom look through all of the options and said, you guys, you are the best possible development partner for this project. But that’s not what’s happened at all and it leads to some of the biggest problems that people have with their clients during the first weeks or months of a project. And the problem is this. When the client’s signing a contract they’re not saying you guys are the best. What they’re doing is they’re saying, okay I’m willing to do a huge favor and give you guys a chance to prove that you can actually pull this off. \n\nAnd it’s a huge favor the client is doing when you're talking about a software project. Because they’re not going to start realizing value to even with an lean/agile process for weeks and they’re committing a lot of time and energy and resources and actual money to you. And so you’re starting the project with the balance on their side. They have given you something, their giving you a great deal of trust, they’ve made a big commitment in you and they expect you to appreciate that. \n
- Okay, oh, and the last important point is a lot of people make the mistake of thinking that when they’ve got the signature on the contract they won, that the client had some of their infinite wisdom look through all of the options and said, you guys, you are the best possible development partner for this project. But that’s not what’s happened at all and it leads to some of the biggest problems that people have with their clients during the first weeks or months of a project. And the problem is this. When the client’s signing a contract they’re not saying you guys are the best. What they’re doing is they’re saying, okay I’m willing to do a huge favor and give you guys a chance to prove that you can actually pull this off. \n\nAnd it’s a huge favor the client is doing when you're talking about a software project. Because they’re not going to start realizing value to even with an lean/agile process for weeks and they’re committing a lot of time and energy and resources and actual money to you. And so you’re starting the project with the balance on their side. They have given you something, their giving you a great deal of trust, they’ve made a big commitment in you and they expect you to appreciate that. \n
- So, show gratitude before you start. How do you show gratitude, by creating a great experience for the customer, by showing your appreciation for being part of the project.\n\n
- Never stop marketing, don’t stop marketing when you get that signature on the contract. Every single point of contact that your company has with a customer is marketing. If they come to visit it’s marketing. If they call in and your receptionist answers, the way that he answers that phone is marketing. If you send the contract to be signed, that’s marketing. And if it’s not as good as it can possibly be your missing the opportunity to cement the relationship. Especially at a time when buyer’s remorse is at it’s highest. I’m not giving away all my secrets but one of the things I do that’s made a big difference in the quality of the relationships that I’ve had with clients in the early days, with a number of referrals that I got from the client, is a simple thing. It used to be when I finished the sales call and the clients said okay let’s do it. \n\nI would then email them a contract that said, please print this sign, and fax it back to me. Does that sound common enough? When I started thinking about these things I decided how can I make that experience, the experience of signing my contract better and better, and better, and better, and better, until it’s as good as it can possibly be. And so I commissioned a company to design and make a box, a very nice black box, black on black printing, embossed logo, Apple set the standard for packaging, I thought, and that's the standard I wanted to match. So we’ve got a nice box and in the box I put a copy of Scrum and XP from the Trenches or David Anderson's Kanban book, depending on the approach we've agreed to take.\n\nI hired a designer to do a brilliant design for planning poker cards and I had the best printing company I could, to do the best quality printing on poker card, plastic laminate them, put that look in there. I had custom printed Moleskine notebooks with our logo on it. Because Moleskine is a top quality brand and I wanted to associate my brand with other top quality brands. So that goes in there. Then there’s two copies of the contract printed on the highest quality paper I could find good letterhead, a handwritten letter from me thanking them for their trust their putting in us. And then I put in a self-addressed envelope ready to be returned. \n\nAnd I collect postage from every country I go to, so I have postage from every country that my clients were in. They don’t have to go to the post office and they don’t have to ask how much do I have to put on this envelope in order to send a copy of the contract to Poland. It’s already British, Belgian, American, Greman postage on the letter and each little detail. And we’ve taken this similar approach to every single point of contact you have with the clients. And the result is, oh, and we sent it by FedEx overnight, so person you talked to on the phone who says okay I want to work with, before it launched the next day it sits on their desk. That affirms all the trust that they just put into me when they said yes I’ll work with you. \n\nAnd it really changes the atmosphere of those early interactions when there’s a developer on the team who doesn’t understand how something has to happen before we begin. The client mustn’t think he must be an idiot. So the client comes into this already feeling like this is something different, this is something special. And you have to keep that feeling alive in the client. Otherwise they interpret everything they see through some other filter which may not be so flattering.\n\n
- And finally, selling agile is easier than selling lean, for three major reasons. Lean processes are less intuitive, metrics are more complex, and the idea of continuous improvement implies that you're not doing your best work from the start. The two things I recommend regarding selling a kanban process to a client are to sell your commitment to continuous improvement in general, so they have the satisfaction of feeling that they are getting a great experience at some previous client's expense and secondly, don't go into too much detail initially about cumulative flow diagrams, cycle times, statistical process control and the like. You'll probably scare them. Remember, if you can't explain it to a child, you're probably going to shoot yourself in the foot if you try to explain it to a prospective customer. Keep it simple and keep it honest so you can effortlessly drive home your single key selling point. Good luck!\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n