No post this week as I have written an article that has taken all my time for the Scrum Alliance.
Please keep a look out in a few weeks time for an article on Work Groups and Teams on https://www.scrumalliance.org/community/articles
No post this week as I have written an article that has taken all my time for the Scrum Alliance.
Please keep a look out in a few weeks time for an article on Work Groups and Teams on https://www.scrumalliance.org/community/articles
Here is another interesting post from our friends at Tenfold.
Its an interesting list of 14 words and phrases that can be used to help with a sale, but I think could be used in more general when trying to be persuasive to someone. I’ll have to give it a go in the new year.
Show the advantage of your offering over competing offerings, how it can improve and help. People like to gain an edge generally. You need to show the value and back it up with case studies or statistics.
Everyone wants to be amazed. The word tugs on the emotional strings and encourages action. People don’t generally want something ‘good’, they want something that will ‘wow’ them, especially if they are paying a premium. But remember not to oversell it. Its better to under promise and overachieve then over promise and over achieve. So use the word sparingly.
There is always something people try to avoid. Be it loss, complexity, the unknown or trouble. We want to avoid risk. So show how risk can be avoided. People are more interested if you can show protection against going backwards from the status quo.
This is an interesting one. An experiment (See the post on Tenfold for the link) was done where the experimented wanted to use a copy machine first to make copies for himself before the person who wanted to use the machine at the time.
The experimented made a request using 1 of 3 scripts.
With the first line, they got 60% compliance. With the second, they got 93% compliance with the request, and with the third line, they got 94%. The study concluded that the word ‘because’ was the key differentiator in getting a stranger to comply with the request. The mere fact that a reason was conveyed, even if no information was given is enough to receive a specific outcome.
People love new things, and having exclusivity can grab peoples attention. The first look at a new product. Just look at how much interest rumors of the new iPhone spread. If someone believes that being first is in their advantage, they are likely to listen.
People want solutions to their problems,, When you suggest you have a “fix” for their issue, you can have a captive audience. But remember, in order for them to have loyalty, you need to live up to their expectations, otherwise things can backfire.
Dan Ariely insists that zero has a special price. People become more interested in free. They just have to have it. I’m no exception. I have a Udemy account full of free courses. Most of which I probably will never get around to starting, yet alone completing. But I must have them – just in case. Free gives a no or little risk option, so why not grab it – just in case.
I lot of people try to avoid this phrase. I know that I was taught never to say this phrase, but being honest and simply saying “I don’t know” can be used to build trust for the simple reason you are being honest rather than trying to guess or make something up. Simply admitting although sometimes embarrassing, that you have a gap in your knowledge eliminates the risk of having to backpedal on your words at a later point if you are wrong.
If someone has an understanding on how they will implement something, they will be more likely to agree to having or using that something rather than not. If you imagine the need for something, you are more likely to want it rather than be persuaded if you don’t.
Everyone wants something sooner. Time is too short to wait. By creating a sense of urgency without aggressive pressure, people are more likely to agree sooner rather than weeks or months later.
Just by simply asking for example “What would you do if you had this now?” or similar, you are planting the seed of urgency.
Everyone is cost conscious. So, showing how you can save money, save time or trouble can be seen as a win for the person. This can be similar to “Free”
When you think of simple, you think that there is a small or non-existent learning curve. When it is simple, people are more open to the idea, but be careful if there is a sting. For example, Scrum is simple to Understand – but difficult to Master.
Sometimes people want to try something different. Some on the other hand do not like to deviate from the status quo. A lot of people like to show their individuality, if you show them how they would be different to the rest, some people are willing to listen.
We is a very powerful word. It shows that we are all in the same situation. We share the same, we are together. It puts in a team oriented mindset. Other words like “our”, “together” and “us” also have the same meaning.
Words like “I” or “Your” or “You” take on an adversarial structure. “You should do this” for example. This invites aggression type tendencies back making it hard to be more persuasive.
I was told the other day that Agile only works for Web Development. And guess what, they guy was right.
Agile only works for Web Development, and…
Wikispeed is an automotive manufacturer that develops cars through modular design. The company was founded by Joe Justice to produce a car that would compete for the Progressive Automotive X Prize competition in 2010. They came in 10th place, no mean feat given they were competing with major world wide car manufacturers.
Wikispeed uses Scrum development techniques to improve productivity and development of their cars.
Yes, Wikispeed is a small car manufacturer, run by volunteers, but they are making ripples in the car industry with their rapid development times.
Toyota, this goes without saying. The Toyota Production System is the basis for Lean which is then in turn the basis for Agile Development. Toyota has been in the agile game for over 70 years. They are now the Third Largest (In 2017) car manufacturer. Down from top spot.
Eduscrum is a version of Scrum modified for education in schools. Developed in the Netherlands it teachs kids to be self organizing of their learning.
Students plan and determine their own activities and keep track of their own progress The Teacher determines the assignments, coaches and gives advice.
Students that work under eduScrum have better grades, better understanding of material than their non-Scrum counterparts.
Lonely Planet, the company that develops those travel books, thier legal team here in Melbourne uses Agile techniques to manage their workload.
Grow Cornwall is an experiment for a town in Cornwall England to introduce Agile techniques to businesses. The process has helped companies and businesses improve their workflow, throughput and thus profit.
The Ghana Police Service began adopting Scrum practices for its Police Force in January 2017(Not its IT Division) to become a world class police service. Their goal is to be come one of the top 10 police services world wide in 4 years time.
With roughly 33,000 police offices and an additiona 14,000 community support officers, the task isn’t easy, but they have taken up the challenge.
Tenfold is a software company that has applied Agile to their sales process.
Agile Manufacturing means that things have come full circle. Using techniques from Agile, companies are applying these techniques to manufacturing and are seen to be taking Lean Manufacturing to the next level.
Yep, Agile only works with Web Development – NOT!
Let me know in the comments if you have any other examples of Agile use outside the IT Sector.
If you have a look at the structure of an IT department, well actually any department within a large organisation and you will see everything is usually grouped based on specialties.
For example, you have the people who are in charge of the CRM systems. The ERP systems. Billing systems, Integration systems etc which is all fine and dandy for day to day operation, but what happens when some new work needs to be done? New work is usually done within projects. How are these projects resourced? Well, sometimes people will be taken out of these departments, and they are put onto the project. Other times, resources will be outsourced to the likes of Wipro, Capgemini, Accenture and so forth. This is all well and good, and gets the work done, but what happens at the end of the project?
Handovers are done to the support teams, you may have a warranty period where the developers are around to fix any “defects” and inconsistencies, and eventually the teams break up or in the case of our outsourced resources, they go back to the proverbial bench to be picked up for the next project.
What happens to all that learning on how the system works, the improvement of the development process, the working as a cohesive team? Well, quite frankly it all goes “poof”.
It doesn’t matter if the project is a Waterfall project or an Agile project. All the learning of how to work together, work cohesively, improve the development process all disappears. The worse thing is that this is considered normal.
This is siloing of resources.
This is the concept of Bring the people to the work. You have a job or a piece of work that needs to be done, so you gather the people that have expertise. Do the work and then once they are done, disband them. I see the allure of doing this. You only keep the people you need for the duration of the work to be done. So costs are reduced.
The problem with this paradigm is that it works well with manual low skilled labour or where there is a specific one off job.
The problem comes when the work is more ongoing. Specialized. For example, building a house, or creating software. Sure you can get away with bringing in people short term, but what you will find is that if you bring them in for the long haul, then things get better.
For the example of building a house, a building company will have its own carpenters, plumbers, concreters, bricklayers, electricians etc. They still move from house to house, but the team remains pretty much constant. The team when done right will work cohesively. They work together in each others interests. They get the job done quicker and better.
The same with Software. You have a team that consists of multiple skills. Developers with a range of technologies and systems (CRM, ERP, EAI and Billing systems etc), DBA’s, testers, BA’s etc. Then when you have a new project that needs to be worked on, you bring the work to this team. This team knows how to work together. If they have used Agile methods, they have improved over time. They know how to get things done quickly. This team is long lived.
You may have different teams with a slightly different mix. They work on other segments of the same project or on different projects. To make things even more interesting, these teams also run the system, not just do project work. In this scenario, all learnings during the project remain and continue to the next project, and the next and the next etc. If the people also run the systems, then there is little to no handovers required.
If you use external vendors, then rather than keep these people on the project for the full duration, slowly replace them over time with your own people and have the vendors teach them the technology that you are not proficient with. I have seen too many times where external vendors a brought in, do the work. Hand over to the BAU team, bug out then the BAU team is left scratching their head when something goes wrong because they lack the one thing that would have helped – Experience.
The second problem is within the teams. You have developers, DBA’s, BA’s Testers etc. Each person does their specialty. If the skillset is not present, then everyone continues and work banks up until that skillset comes back.
This is the second level of Siloing and it prevents things from getting done.
In Scrum, there is the concept where there are only 3 roles. The Scrum Master, Product Owner and Developers. There are no sub roles such as Tester, DBA, BA etc under Developers, just Developers. It is expected that each person with that role is willing and capable to an extent to do the job of all roles. Some may be better than others, some may have no experience, but that is irrelevant. Those in the role of Developer are encouraged to understand all disciplines even though they may specialize in one.
For example, say a project has no tester – they are on sick leave. Programmers (as opposed to Developers) continue coding. Work mounts up ready for testing. Nothing gets tested and then at the end of the sprint/iteration, nothing is marked as complete. What happens then? From my experience, either someone external is brought in to do the testing at the last minute – it may even be the scrum master or product owner or the work is taken to be OK and is marked as “Done” or any issues found later and bug tickets are raised or everything goes back onto the backlog until the tester is back. Then they have a large batch of work to get through.
One thing that I have never seem in my limited experience with Agile is for the developers to step up and do the testing. I don’t see the problem with this. There are no sub roles in scrum. Everyone is a Developer, everyone is a tester, everyone is a BA. Everyone has the duty to test. This is the tearing down of the inner silo.
I know, if you test your own code, you may still have bugs from misinterpreting the requirements. Well, testers can have the same problem if the requirements are not clear enough. The concepts of Specifications by Example should take care of situations like this.
Another reason I have been told that this isn’t a good idea is that as a developer testing your own code, you can just pass it through. My thinking on this is that if you are willing to do this, then you are not being professional. Secondly, if you are willing to do this, then there must be an underlying problem with the team, is the team not feeling pride for its work. It may be because the team are being dictated to and have therefore lost engagement, team members may have personal problems, team problems such as not getting along or something else altogether. I don’t believe anyone wants to sabotage their work intentionally.
If you still are unhappy, then have another team member – any member of the development team check the work.
I’m not saying get rid of testers, but I’m saying that if there is no one else available you need to step up and help.
This also holds true if the tester is inundated with work. Step in and bring that WIP down.
I’m reminded of a story in Team of Teams, at least I think that is where it came from. I’m paraphrasing here but…
If you are shot in combat, you don’t want to be sitting there bleeding away while the medic is either working on someone else or shot them self. You want for example the communications officer to be able to patch you up even though they do not have the full training.
So break down the silos. Everyone should learn a little about everything, even though they may specialize on one thing. We are all in it together, we should be helping each other out.
Here is an interesting Blog post again from Tenfold.
I likes this post not because its specific to Sales People, but because its is good advice overall.
The 7 things Smart People Don’t Say are
Again, good advice from our friends at Tenfold.
Apologies for the technical difficulties we had with the site over the last few days.
I decided to install Ruby and it clobbered the site. I didn’t realize until now.
We are back up and running, we haven’t gone away.
Thank you for your patience.
The following article first appeared on the Scrum Alliance Member Articles
To better understand the Scrum Guide, I’ve been deconstructing it by writing it longhand (yes, longhand — I’m a little crazy that way). I worked on the 2013 version of the guide, but I decided to backtrack a little, so I started with the section on Scrum values.
When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
This got me thinking about the Toyota House metaphor that has the foundations of commitment, courage, focus, openness, and respect. Its pillars are made of transparency, inspection, and adaptation. Then, we have the roof of trust.
To me, this is the Scrum Team House.
It has been a while since I listened to Patrick Lencioni’s audiobook The Five Dysfunctions of a Team. This book is one of those fictional management novels that tells a story to get a point across. After reading the above passage, I saw the connection between Scrum values and Lencioni’s work.
Lencioni’s book describes the following five dysfunctions of a team.
This isn’t the type of trust whereby a manager trusts his people to do the job right, although this is part of it. This is the trust whereby a weakness, be it personal or professional, will not be taken advantage of. This is the kind of trust that makes you feel that your team members have your back rather than stab you in the back. If something goes wrong, they will not attack, criticize, blame, and shoot you down. Instead, they will help, they will encourage, and they will listen.
A lack of trust also leads to lack of respect for other team members. Would you respect someone who used your weakness against you? Do you show respect for someone when you have exploited their weakness?
Lack of respect causes fear — fear to voice opinions lest you be criticized. Fear to speak out when you think something is wrong or when you disagree with the team. Fear to try something new.
Things become opaque, convoluted, and complex. Knowledge is hoarded and ideas are not expressed. This lessens the team’s courage to lead constructive discussions and constructive conflict to help problems become openly discussed and explored for alternative solutions.
Fear leads to lack of commitment. Would you commit to something you had no say in? Would you commit to something you didn’t believe in? What you end up getting is compliance. People doing the minimum requirement. Work then transforms into being just a job — something you do for a paycheck. When this occurs, no one will want to take ownership of anything.
To avoid blame, finger-pointing ensues. Why would anyone want to take responsibility for something going wrong if you get in trouble? The blame game prevents the inspection of problems and thus the proper resolution to those problems. You will have one of two outcomes: Only superficial resolutions will be put in place, or the problem will be swept under the proverbial rug.
We have a saying in Australia, “Head down, bum up,” which is a figurative expression for working hard (think of a child kneeling down on the floor, working in deep concentration on something like a drawing). So in this climate, people are working hard, just doing their job, not worrying about their surroundings, and not focusing on results. They do only the hard slog (another Aussie slang term for doing grueling work). The team cannot adapt if it has this mindset.
I can see now that the Scrum values are precise. They exist to help build a team that lasts. They provide the foundation for a high-performing team. But as we also can see from Patrick Lencioni’s work, it does not take much to tear down a high-performing team until it becomes a mediocre team or worse — a team, or at least some members, that actively works against the group’s best interests.
By simply removing the “roof” of trust, a team can deteriorate quickly, and when that trust is gone, it is difficult to get it back. If the cycle repeats, each time trust is lost, it’s even harder to regain it, until trust will eventually reach the point of no return.
At the turn of the century in England, milk was delivered in open glass bottles. There were 2 birds that loved to drink the cream that would settle at the top of the milk. These were the Blue Tits and the Robins.
Then after world war 1, milk was delivered still in bottles, but with an aluminum top to prevent the milk from spoiling.
This also prevented the birds from drinking the cream. At least temporarily. You see, the blue tit learned how to peck through the aluminium foil, where as the Robin did not. Throughout England, Blue Tits would get the cream, but Robins could not figure it out. Now you would probably think that Robins are not as intelligent as Blue Tits, which is why they could not get to the cream, but this isn’t the case.
Robins are territorial birds. They come together when mating, but then quickly stay on their own in their own territory driving off other Robins. This means that they do not get a chance to share knowledge. Whereas Blue Tits are social birds, when one bird figures something out, it is shared among other birds. So if one bird figured out you peck through the aluminium foil to get the cream, soon all birds would know. For a Robin, if one bird figured out how to get to the cream, only that bird would know. The group misses out.
The same can be said with Humans. Those that hoard knowledge may be smart on their own, but the overall system looses out. Whereas those that share knowledge as a group, all benefit and get better.
The same goes for anyone who defends their territory (Those unwilling to learn from others) will also miss out on gained knowledge.
We can see this play out socially at the moment in Facebook. A mother shared how she removes splinters using a syringe by usig suction instead of jabbing her children with a needle to fish the splinter out. This simple tip has made it across the world and is being shared by news organisations, newspapers etc. It just shows how infectious learning is.
So share your knowledge. Write blogs, do talks, not only within your own team, your own company but with all who will listen. In the long run, we all benefit.
We have another guest posing from Tenfold.
i was recently watching a talk I found on YouTube on “Douglas Hubbard” from “How to Measure Anything” and he was talking about having too many data points when making decisions.
He was talking about how bookies with two pieces of information would make a prediction. This would become a baseline. Given 4 or 5 data points their accuracy would go up slightly more.
But given 8 or more pieces of data, their prediction would actually get worse, but their confidence in their predictions gets better.
According to the Tenfold Article, with Agile, you “Need to be comfortable with vague or contradictory information”. In other words, incomplete information. You will actually make better decisions, faster decisions and thus lead your team to success.
I suggest reading the original article at Tenfold to see how Agile can help with sales.
I was recently contacted by a company that had read one of my posts and wanted me to share one of their posts. Usually I would think this is spam and move on, but I do check first.
The reason I’m telling you this, is that the post I think is interesting and I’m willing to share for that reason.
Here Patrick Hogan, one of the co-founders of Tenfold outlines how Agile can be used in sales. Sales in general, not only Software sales.
This fact alone I think deserves a mention. It shows that Scrum and Agile in general is not limited only to Software Development, but not only that. I think he is right.
Its been over 7 years since I worked for a vendor, but I worked for one for over 10 years (SeeBeyond then Sun Microsystems), and although I didn’t work directly in sales, I was on the implementation side – I did work with the sales reps. Especially when we implemented Proof Of Concepts and being a small office, we got to know one another quite well.
I remember the sales process was all about wooing the customer. Telling them and sometimes even showing them how well the software would fit in their organisation and solve their problem. Sales cycles would be in months if not years. Especially in Australia.
Now, things are different. At least I see it from a customer perspective now that I work on the other side of the fence. There is so much open source out there now, customers are more informed. The sales process is much harder. It requires that sales people adapt and change as required and what better way to adapt than to use Agile methods and processes.
Patrick has given a high level overview on how this can be achieved for a sales team.
I suggest you read the article for yourself.