Let me ask you a question.
Why do you think Bill Clinton gets paid $200,000 to speak for an hour?
Is it because he is such a good speaker that just hearing the magic words come out of his mouth will make you a better human being and drastically change your life?
Or do you think it might have something to do with the fact that he was the president of the United States of America?
I’m not doubting the Bill Clinton is a good public speaker. He is likely one of the best, but it is not his skill alone that commands such a high price. A large portion of his price tag comes from the name he has built for himself.
You might say that he has…
Style and substance
Just having style is not enough. Style is just a name without anything to back it up.
Have you ever been suckered into buying one of those products on late night TV? You know what I mean, the ones that they sell at 2:00 AM and throw in all kinds of extra things if you only act now?
That is an example of style, but no substance. You aren’t getting what is being sold. The infomercials are advertising a product much better than what you actually receive. When you open the box and try out the product, you feel like you got ripped off—and you did.
Substance alone is not enough either. I’ve known many very skilled people that couldn’t market their skills worth a dime. Often people who focus on developing their skills don’t feel that they have the ability or time to learn how to market those skills, so those kinds of people go underappreciated and never live up to their full potential. As a software developer, you are probably more likely to fall into this category.
To reach the ultimate level of success and truly increase your value, you have to have both style—the ability market yourself and make a name for yourself, and substance –the skills that pay the bills.
Whether you like Bill Clinton or not, you have to admit that he does have both; that is why he commands such a high price tag.
Skills are not as important as you think
One thing that many programmers and software developers find hard to believe is that skills are not the most important thing in advancing your career.
Don’t get me wrong, you have to have some skills and knowledge. Just like the dice-o-matic you bought at 2:00 AM and quickly discovered was actually a piece of junk, if you pretend to have skills and abilities that you don’t actually possess, your customers and clients will be just as disappointed and look for a trash can to drop you off in.
But, at the same time, most people can’t recognize the difference between someone who is in the 95% margin of skill in a field from a person who is in the 80% margin of skill in that field, unless they also happen to be an expert themselves in that field. Unless you are a doctor, or dentist or auto mechanic, you probably don’t have a way of really evaluating how good a doctor or dentist or auto mechanic is—although you can probably quickly spot a phony.
So, why is this important?
Because, if you are like me—or at least how I was—you are probably spending way too much time focused on increasing your skills and not enough time increasing your style; building a name for yourself.
What I mean by this is that if you are at a decent level of skill, you will see much bigger benefits in building a name for yourself than you will in increasing your skill further.
It doesn’t matter if you are an independent software developer trying to get more clients or sell a product, or you are looking to work for someone else who will pay you more money, or you just want to get that promotion at your current job. Whatever your goal or situation is, complimenting substance with style will multiply the value of your skills much more than increasing those skills themselves.
The best way to think about this is like a mathematical equation.
(Style ^ 2) * Substance – Expectation = Value
Let’s break it down.
Style is more important than substance, because while skills are essentially capped and become harder to increase over time, style can be increased to a much larger degree—you can always build a bigger name; get a bigger audience.
Plus, the effect of having a larger audience tends to increase exponentially. That is why commercial spots for the Superbowl are so expensive.
Now, from the style and substance multiplication we have to subtract expectation to get a true sense of value.
Consider the case where you bought that dice-o-matic from a late night infomercial. The style points were pretty high. Lots of great marketing techniques were at play to get you to make that purchase, but those techniques also tend to setup some pretty high expectations of what the product should do. When you see the guy on TV using the dice-o-matic to chop an iPhone into tiny pieces, it sets a pretty high level of expectation.
Style is high, but substance is pretty close to zero and expectations are high, so in many cases value can actually be negative.
You have to consider the same thing in your career, when you are marketing yourself and your skills. Some of the marketing techniques you could use to get a quick audience would also produce a very high expectation, so if you don’t have the skills to measure up, you are going to create some negative or very low value.
On the other hand, if you have a high enough level of substance behind what you are promoting and you are able to promote yourself in a way that doesn’t build up more expectation than you can deliver, you are going to be able to bring a pretty high amount of value.
Increasing your value
So, for many of us software developers and programmers the answer is simple. The most effective way we can increase our value is to learn how to market ourselves; a skill that I have found many IT people tend to lack. Of course there are some great examples of developers who do not lack this “style.” Most conference speakers and well known authors or consultants are very good at promoting themselves and really increasing their value by carefully paying attention to the equation above.
Now, of course, this is much easier said than done. I’ve also found that most software developers don’t really know how to go about marketing themselves. I didn’t either for too long of a time—and I am still learning how to do it every day. But, I have learned some valuable techniques that I think just about anyone can apply to build some points on the style side.
If you are interested in learning about how to market yourself to really increase your value, sign up for my newsletter here, so I can keep you updated on my future posts and videos covering that topic and much more.
I am planning some pretty exciting content around all of the information I’ve gathered over the years about marketing yourself as a software developer and I’ll be sharing a large amount of that information here on this blog.
It seems just yesterday I was trying to push forward the idea of developing software in an Agile way, but somehow now it seems like that battle is over.
As if we won without a fight.
When I look around now, I don’t see software development shops doing big upfront design. I don’t see consultants knocking down doors to certify you as a Scrum Master.
It seems that we have now entered a phase where Agile is accepted as the default and now instead of everyone trying to pitch the idea of Agile, everyone is trying to fix their broken Agile implementations.
The funny thing is, still no one even knows what Agile is
The big problem with Agile from the beginning has always been trying to define it.
Pretty early on, this problem was solved by calling it Scrum. Scrum was something that was easily definable, and something you could get certified in.
Scrum was a set of rules you follow that makes you Agile.
At least that is how it was pitched too often.
I predicted that Scrum would die, and I am pretty ready to call that prediction as correct.
Sure, there are plenty of development shops still using Scrum today, but it isn’t really growing and less and less organizations are following it strictly. (I can’t back this up, just my feel.)
I am a pretty firm believer in most of the value of Scrum being that it contains a firm set of rules that doesn’t require debate or judgment calls. If most organizations are just taking the idea of a 2 week sprint and having daily scrum meetings, they are not likely getting much of the value out of Scrum.
But, the problem is that Scrum itself was never Agile. Scrum was a defined set of process, that if you followed, would give you the framework you needed to actually be Agile.
To me Agile has always meant stopping the BS about software development.
To me Agile meant stop building this plan that you know is going to fail and rules lawyering your customers to death to get them to pay for something they didn’t want, because that is what they agreed to.
To me Agile meant to instead try to develop software as honestly as possible. To go in and find out exactly what the customer wanted at the moment, try to build that thing and as openly as possible and as quickly as possible get further feedback to refine and improve. To focus on doing a good job and know that if you are doing that everything else will fall into place. To me that is what Agile has always been.
So when I say where is Agile now, I am probably asking a different question than most people
I have to ask myself: are software development shops doing what I define as Agile? Has that idea permeated the software development community as a whole?
I don’t think so, but I don’t think it has died, nor will it ever.
But, I have seen some things that make me hopeful.
I’ve seen a large amount of talk about MVP, Minimum Viable Product.
I’ve seen many start-ups launching MVPs and being successful doing so. And I’ve seen awesome companies like Buffer using this idea to build a product that is exactly what I want, because their plan is completely based on the customer and it adapts to the customer.
Why am I saying all this?
Simple, I think that what the world thought was Agile was two things:
- Iterative development
For the most part the software development world has ditched Scrum, at least the only form of useful Scrum, which is strict by-the-book Scrum, and adopted Scrum meetings and iterative development. Honestly, I could do without the Scrum meetings, because although they are a good idea, no one actually does them correctly.
So, in essence, we won the wrong battle and we did so with major concessions. But, that is ok, because what the consultants packaged up, certified people in and sold as Agile, wasn’t really Agile at all.
Instead the real Agile movement has been gaining traction and it isn’t being sold by consultants, it is being championed by small start-up companies that are producing products that are 100 times more weighted on the side of results in the results to employees ratio than traditional software development shops and they are calling it MVP.
This is where the true spirit and ideas of Agile live and thrive and as more and more of these companies become successful and more and more researchers dissect their results, they are going to find that these small software boutiques were the ones who were actually practicing Agile, because they were cutting through all the BS of software development and focusing and developing and building exactly what the customer wanted—tools, process, contracts, plans be damned!
My routine is pretty crazy.
I get up in the morning, make my strict bodybuilding diet breakfast, and get to work at my first job by around 8:00 AM.
I’ll take a few short breaks before lunch to cook usually some fish or chicken in order to fit in my 6 to 7 meals a day. (I eat the same exact thing every single day.)
At lunch time I’ll either head to the gym or out on the road for a run.
Around 5:00 I’ll be done with my work for the day at TrackAbout, and take about a 2 hour break to eat dinner and spend some time with the family before heading back to my office to start recording.
Most nights I spend from 7:30ish till 11:00-12:00 planning course work, recording, or editing videos for my Pluralsight courses.
On weekends I usually spend one day finishing up whatever I didn’t get done during the week and writing a blog post.
I’ve been doing this for just about 2 years.
But, that is about to change.
February 13th will be my last day working at one of the best companies I have ever worked for, TrackAbout.
It is really difficult to leave a company that is full of so many good people. In the two and a half years I was at TrackAbout, I cannot recall one heated argument that I have ever been in with any person at that company. I don’t even know of anyone else having a quarrel either. That really says a lot about the values and temperance of the employees and owners of the company.
Here are some of the awesome things I liked about working for TrackAbout:
- Completely remote development team. Everyone works from home.
- No bureaucracy! One layer of management, developers report directly to our CTO.
- Our CTO, Larry Silverman, is highly technical. You can’t BS him! He knows software development and is able to make good choices that are highly relevant to the work being done. (No death marches, no mandates from on high.)
- Autonomy. As long as you are doing your job, how you do it is mostly up to you. Even what we do to some extent is decided by our teams.
- Respect. In the whole time I was at TrackAbout, I never was pushed to lower an estimate or questioned about how I did my job. TrackAbout empowers its employees by trusting them and believing they are competent.
- Flexibility. I always found that if I thought we were doing something the wrong way at TrackAbout, I could say why and how to make it better and things would actually change.
- Developer free time. Every 2 weeks we get 4 hours to work on whatever project we want.
I don’t intend to make this an advertisement, but they are hiring an entry level position. (Web and Mobile .NET Developer – Entry Level – TELECOMMUTE)
So why am I leaving then?
You might be wondering if I enjoyed working at TrackAbout so much, why I would leave.
As I said, it was not an easy decision, but my true passion—the basis of this blog—has always been to make things that seem complicated simple. I really enjoy being able to take a complex thing and break it down so anyone can understand it.
Pluralsight got $27.5 million in funding this year with the goal of expanding their course catalog by a large amount this year.
I realized that I needed to do everything I can to help with that goal, and that this kind of opportunity would not likely come again in my life. For me, this represents an opportunity to independently support myself and to devote full time to doing the thing I am most passionate about, taking the complex and making it simple.
Come February 14th of this year, I’ll be devoting almost all my time to producing Pluralsight courses.
Stepping away from stability
I have to admit, it is a bit scary to not have a regular paycheck coming in.
I’ll be a completely independent author making a living off of the courses I produce. Both exciting, and scary.
I’ve been used to getting that steady two week paycheck and having benefits provided for me, but now my fate is entirely in my own hands.
It is a step I know that I had to take, I just had not planned on taking it so soon.
Where to from here?
This year will primarily be focused on Pluralsight course development and possibly a small amount of consulting.
After that, the road is unwritten. I’ll be keeping this blog going, and I definitely plan to have a redesign this year.
I used to be very confident in my abilities as a software developer.
I used to be able to walk up to a group of software developers and tell them exactly what they were doing wrong and exactly what was the “right” way to do things.
I used to be sure of this myself.
It wasn’t even that long ago. Heck, when I look at the blog posts I wrote 3 years ago I have to slap myself upside my head in realization of just how stupid I was.
Not only was my writing bad, but some of my thoughts seem so immature and uneducated that it feels like a completely different person wrote them.
And I wrote those posts back when I knew it all.
The more I learn, the less I know
Lately I’ve been running into situations more and more often where I don’t have a good answer for problems.
I’ve found myself much more often giving 3 pieces of advice attached with pros and cons rather than giving a single absolute—like I would have done perhaps 3 years ago.
I’ve been finding as I have been learning more and more (the past 3 years have been an accelerated pace of growth for me,) that I am becoming less and less sure of what I know and more and more convinced that there is no such thing as a set of best practices.
I’ve even spent some time postulating on whether or not commonly held beliefs of best practices would be thrown completely out the window given a significant enough motivation to succeed.
My point is that the more doors I open, the more aware I become of the multitude of doors that exist.
It is not just the realization of what I don’t know, but also the realization of weakness of the foundation I am already standing on.
Taking it out of the meta-physical
Let’s drop down out of the philosophical discussion for a bit and talk about a real example.
Perhaps the biggest quandary I struggle with is whether or not to unit test or practice TDD and its variants.
The 3 years ago know-it-all version of me would tell you emphatically “yes, it is a best practice and you should definitely do it all the time.”
The more pragmatic version of me today says, in a much more uncertain tone, “perhaps.”
I don’t want to delve into the topic in this post since I am sure I could write volumes on my ponderings in this area, but I’ve come to a conclusion that it makes sense to write unit tests for code that has few or no dependencies and that it does not make sense to do so for other code.
From that I’ve also derived that I should strive to write code that separates algorithms from coordinators.
I still even feel today that my advice is not wholly sound. I am convinced it is a better approach than 100% TDD and units tests, or no TDD and unit tests, but I am not convinced there isn’t a deeper understanding and truth that supersedes my current thoughts on the matter.
As you can imagine this is quite frustrating and unsettling.
Silver bullets and best practices
What I am coming to realize more and more is that there are no silver bullets and more surprisingly there are not even any such things as best practices.
Now I’ve heard the adage of there being no silver bullets so many times that it makes me physically sick when I hear someone say it, because it is so cliché.
But, I’ve had a hard time swallowing the no best practices pill.
I feel like when I abandon this ship then I am sailing on my life raft in the middle of a vast ocean with no sails and no sense of what direction to go.
A corner-stone of my development career has been in the learning, applying and teaching of best practices. If these things don’t exist, have I just been pedaling snake oil and drinking it myself?
Best practices are simply concrete applications of abstract principles in software development that we cannot directly grasp or see clearly enough to absolutely identify.
Breaking this down a bit, what I am saying is that best practices are not the things themselves to seek, but through the pursuit of best practices we can arrive at a better understanding of the principles that actually are unchanging and absolute.
Best practices are optimal strategies for dealing with the problems of software development based on a particular context. That context is primarily defined by:
- Language and technology choice
- Meta-game (what other software developers and perceived best practices are generally in place and how software development is viewed and understood at a given time.)
- Individual skill and growth (what keeps me straight might slow you down; depends on where you are in your journey.)
There is a gentle balance between process and pragmatism.
When you decide to make your cuts without the cutting guide, it can make you go faster, but only if you know exactly what you are doing.
Where I am now
Every time I open my mouth I feel like I am spewing a bunch of bull crap.
I don’t trust half of what I say, because I know so much of it is wrong.
Yet I have perhaps 10 times more knowledge and quite a bit more experience in regards to software development than I did just 3 years ago.
So what gives?
Overall, I think I am giving better advice based on more practical experience and knowledge, it is just that I am far more aware of my own short-comings and how stupid I am even today.
I have the curse and blessing of knowing that only half of what I am saying has any merit and the other half is utter crap.
Much of this stems from the realization that there are no absolute right ways to do things and best answers for many of the problems of software development.
I used to be under the impression that someone out there had the answer to the question of what is the right way to develop software.
I used to think that I was picking up bit of knowledge, clues, that were unraveling the mystery of software development. That someday I would have all the pieces of understanding and tell others exactly how they should be developing software.
What I found instead was that not only does nobody know the “right” way to develop software, but that it is perhaps an unknowable truth.
The best we can do is try to learn from obvious mistakes we have made before, start with a process that has had some level of success, and modify what we do based on our observations.
We can’t even accurately measure anything about software development and to think we can is just foolishness.
From story points, to velocity, to lines of code per defect and so on and so forth, all of those things are not only impossible to accurately measure, but they don’t really tell us if we are doing better or not.
So, what is my point?
My point is simple.
I have learned that not only do I not have all the answers, but I never will.
What I have learned is always subject for debate and is very rarely absolute, so I should have strong convictions, but hold onto them loosely.
And most importantly, don’t be deceived into thinking there is a right way to develop software that can be known. You can improve the way you develop software and your software development skills, but it will never be based on an absolute set of rules that come down from some magical process or technology.
I wrote a post talking about how you have to either choose to release based on features or time, but not both.
I got a comment on that post basically stating: “I like the idea, but how do I sell it to my clients?”
The commenter pointed out that there are two things he could say:
- We agree on which features you get, but I can’t say when you will get them.
- You will have some features on a date, but I can’t tell you which or how many.
I thought this was a very excellent point because neither of those sounds very good to your client. I addressed it a bit in my post, but I thought this question really deserved a longer and better answer.
Many people have asked me about Agile contract negotiation. I don’t think there is a really great answer out there.
Honestly, the best answer you can possibly give basically equates to “trust me.”
I’m going to show you how to say “trust me” in a little more diplomatic word choice while at the same time showing you how to demonstrate why you are trustworthy and why other vendors you are competing with may not be.
Why you are trustworthy
It is a lot to ask a client to just trust you.
Unless of course you have some good reasons to be trusted.
One huge issue in trust is transparency. The more transparent a person or process is, the more likely someone is to trust that person or process.
A good example of this might be your 401k.
Most people trust the 401k plan at their work. (In fact too many people blindly trust it.) Now, imagine that you had a 401k plan at your work and you got no description or choice of what funds to invest into. You just take part of your salary each month and put it in the “plan,” and when it is time to retire, you will be set. You don’t get to see statements each month or anything. You just have to trust that your money is being taken care of.
What I did there is remove the transparency and the choice or control.
If you want to add trust, you add transparency and control.
Compare this to most software development contracts. In general, you hire a company to build some software and they promise to have it done by a certain date for a certain amount of money, but you don’t see anything until it is supposed to be done, and you don’t see how they are building it.
If you are following an Agile methodology like Scrum, Kanban or XP, you are offering a much more trustworthy position than traditional waterfall development.
Use this as your selling point. Don’t try to hide it in a box. The reason you are trustworthy is because you are going to let your client see exactly what you are accomplishing each week and let them set the future direction. They are able to know exactly what they are getting in relation to what they are paying for.
You should be constantly showing a working product at the end of each cycle and letting the customer prioritize what you work on next. You don’t have to draw up a contract that says a date and a number of features. Instead, let the client figure out that data themselves from the progress you are making.
The great advantage of this approach is that your client is constantly getting up-to-date information to base projections of time and budget on. Using the data you are giving them, they can accurately predict how long it will take before you are done with what they need.
They also have the option of doing things like:
- Scale down the features in order to make a time window.
- Release or go live early, because they know they can.
- Increase the length of the project to get a few more key features done which will add significant value that is worth being a little later.
- Change the set of features to optimize for ones that are less risky or can be done more quickly.
- Realize which features are absolutely needed and save money by only building those.
I believe 100% that if you can clearly communicate this point there is no reason why any reasonable client wouldn’t trust you.
Most of your clients are used to having smoke blown up at them. They understand that vendors and consultants lie. They understand to some degree that software development is unpredictable. You won’t have to convince them of those points.
You will only have to convince them that you won’t lie, and you will be transparent.
Why people promising dates and features are liars
You can read my post about features or time as a refresher, but it is pretty basic common sense that you can’t promise both without being either a liar or a cheat.
Strong words, but it is absolutely true. You are either telling your client that you can make a date with a certain number of features without having any facts to back up that claim (lying), or you are padding enough to make sure that you can deliver even though you know a true estimate would be much less (cheating).
The truth of the matter is that no one can accurately predict the intersection of features and time for any significant product.
You can have the best intentions and you can try as best as you can to be as accurate as possible, but in most cases you are going to be lying if you try to claim it is anything but a wild guess.
I am not going to go into the details of why this is the case in this post, since I already covered it earlier.
If you want to destroy your competition, just ask your client to compare what information you are going to provide them against what your competition is providing.
Ask them about what kind of assurance they have that vendor x will actually deliver the 20 features that aren’t even clearly defined yet in 6 months.
You can be assured that they do not have good answers for these questions, because there is no method of accurately predicting the time it takes to build software. Unless your competition is clairvoyant, you can indicate that if they are predicting a set of features in a particular time frame that they are not being honest.
On the other hand, you can come from a position of complete honesty and transparency.
How to say it
Obviously you don’t want to do something like this:
You: “Okay, here is the deal. My company is super Agile. What does that mean? It means that you can trust me and my competition is basically all a bunch of dirty scum bag liars.”
Client: “Umm, ok. So how do we write up a contract?”
You: “Don’t worry about that. Just trust me. I am Agile. You can track my velocity n00b!”
You don’t want to bash the competition. That is never good, but you do want to highlight the difference between your company and the competition.
You want to hammer in the points that you are transparent and that you give them control. You want to talk about how anyone who tries to promise a date for a set of features that aren’t really even defined yet may have good intentions, but has no possible way of accurately making that prediction.
Ultimately, your competition is going to be pitching a fixed price contract with a fixed duration and you are going to be pitching a time and materials contract.
Here is the problem. Most clients are going to prefer that fake security of the fixed price and time contracts. Sure it is a false security, but you need an additional selling point to be able to make your choice more appealing.
Offer the early out.
What is the worst part about signing a 1 year contract for x dollars? You are committed. If something goes bad or wrong, you still have to pay up. Your client is aware of this, and it is a scary part of inking the deal.
You have a better offer. You can win by saying that when you are building the software, you will be delivering a working product at the end of each cycle. In addition, they can abort or change directions any time. Your progress is visible at regular intervals, and your client has the option to have you stop building the product if they feel that you are not making the progress they need.
You have the competitive advantage of your client being able to choose to work with you without having to commit to a large timeframe or budget. They have the ability to evaluate the progress at each step along the way.
Worst case scenario for them is that you partially build a product for a month and if it isn’t working out, they ask you to quit and they choose someone else.
Worst case scenario for someone pitching a fixed cost and fixed time contract is that your client looses x amount of dollars and time and doesn’t know about it until the deadline comes and goes.
So, yes it is harder to pitch a time and materials contract, but mainly because of two reasons:
- You don’t know how. You don’t have the experience doing it because you have been doing fixed price contracts for so long.
- Your client isn’t used to it.
If you are willing to devote the time and energy into educating your client, you will find that you can be successful and you don’t have to be a liar to do it.
Now that I am not a consultant anymore, I can finally write about this topic.
This is one of those likely to piss people off topics, but this is something I feel every consultant should know.
So, what am I talking about?
Basically, I am saying if you are working as a contractor, or other type of consultant, and there is a middle-man between you and the direct client, you need to know what you are being billed out at.
Why does it matter?
The main reason is that you need to be able to know how to negotiate your rate. Over the course of your career in software development, negotiating your rate can be worth hundreds of thousands of dollars.
That is kind of a big deal!
It just makes good business sense. If you are working as a consultant, you are, to some degree, running your own business. A good businessperson knows what everyone is making on the deal. It isn’t an unreasonable thing.
Let’s consider an example. Have you ever bought a car? If you have, did you walk into the dealership and pay the sticker price?
When I go to buy a car, I ask for one thing. The dealer’s invoice. Then after he gives me the fake one, I ask for the real one. I want to know what their cut on the deal is. The dealer deserves a fair markup for the service he is providing, but as a customer and businessperson, I also deserve to get a decent price.
Taking that example a little further, what if you went in to buy a car and the sticker price was $25,000. Then the dealer and you negotiated and he came down to $23,000. Now, let’s suppose you found out that he got the car from the factory at $20,000. The seems fairly reasonable. 3k is a decent amount to make on a car, but the dealer is going to have some overhead and other costs associated with being in business.
Now, imagine in that same scenario the dealer bought the car for $10,000. If you found out that piece of information, you might be pretty outraged. You might consider why you need the dealer. Is he providing 13k of value to the transaction? Should you get your own dealer’s license?
In any kind of business deal, everyone should have a good idea of who is adding value and at what cost.
I’ve been in the real estate business, the software development business, and a few other industries, and one thing I have learned is that the best business deals have the most transparency. Nothing will ruin a deal or make a sour relationship more than missing disclosures.
In business everyone has to make money, but everyone wants to feel like they are getting a fair shake. When I am selling something, I will gladly state my cost. When I am buying something I expect someone to be able to tell me what their cost is.
If you are a consultant you need to be making sure you are in a good deal, otherwise you are in risk of under pricing yourself. You need to push for transparency. If it is a good deal, it should be a good deal for everyone.
They won’t tell me my bill rate
Did you ask? How did you approach negotiations?
One important thing I have found is not to talk about hourly rates. Instead, you should be talking about margins and markups. As a consultant doing 1099 work through my corporation, I always state that I allow for a 15% markup on my services.
In my opinion, this is more than reasonable. And yes, I am flexible to a degree, but the point is: from the beginning I am talking about markups and margins, not about hourly rates. Make sure you start the conversation there. You are a professional and a business person, act like one. If you don’t want to be treated like a commodity don’t act like a commodity.
You may not be able to get the exact numbers, but you should be able to get a general idea of what the bill rate is. There is no reason why any professional should be billed at 2-3 times what they are being paid. The middle-man does not provide the value that deserves that kind of markup, yet it happens all the time. Don’t be a victim.
Don’t be afraid to do some research yourself. It is fine to say “I know that you are probably billing the client around $100/hr… “ Don’t be afraid to fish a little.
One word of caution here. A middle-man does deserve to make some money. If they found the job and found you, and they are handling the payroll, that service has value. You cannot expect them to make nothing, just make sure it is a fair amount in regards to the service they are providing.
In doing so, I had to really think about why exactly I think waterfall is bad.
The feedback loop
It really came back to one central thing for me, which is the length of the feedback loop. When we are using a waterfall process for software development, the customer doesn’t really have a chance for feedback until the end of the project. Even the testing is done at the end of the project, so that feedback is coming very late.
The biggest strength Agile gives over Waterfall, is the tightening of that feedback loop. The quicker you can get the feedback, the quicker you can respond to it and the less time you spend going in the wrong direction.
From a programmer’s perspective, think about how many of us used to write code before the tools came along to help us, and before we knew any better.
Write a bunch of code for 2 hours
- Run the compiler
- Fix an error
- Repeat 2-3 until all errors are fixed
That wasted a large amount of time. Especially when we had some syntax wrong that affected large portions of code.
Using a modern IDE, we are able to see syntax errors getting highlighted the second we type them. We can start to type a method name and auto-complete can take over and offer us suggestions. It it difficult to write bad syntax because we are getting constant and immediate feedback as we write out code. The feedback loop is so tight that we don’t even consider compiling to be a separate step. There are even some IDE plugins which will continuously run any unit tests which may be affected by your code change in the background as you are making the change.
If the modern IDE experience is Agile, then Waterfall is punch cards.
Taking the best of all
So, here is my prezi presentation. Please give feedback if you have some. Remember this presentation is designed to be a very basic beginner’s guide to why someone should choose Agile over Waterfall. It is not going to go into very detailed topics about Agile.
Also, at the end of the presentation you will notice that I suggest taking some of the process of Scrum, and the XP best practices, and running Kanban using those guiding principles. I currently believe that is the best mix of what Agile has to offer.
Oh what an ethical dilemma.
I’m about to piss off a lot of people.
But, I am going to tell the truth.
Often a person has to make a choice between standing by their convictions and doing what they believe is right or doing the more profitable thing at the cost of integrity. I don’t like to use this blog as an avenue to bash anyone, but I have held myself to the requirement of being honest. Honest in the most tactful way that I can.
I am also not always 100% correct. Sometimes I am plain wrong, but I have to call things as I see them until corrected and shown otherwise. I am open to being corrected. That is how to learn. Learning is more important than being right.
One last disclaimer. I don’t hate Scrum. I think it is good. I think it is really good, and if implemented correctly can provide enormous benefits. I think most of the ideas are sound, even though I do believe it has some major flaws. I think if 90% of software companies stopped doing their broken process and at least tried to adopt Scrum, the world would be a better place. But… I also think Scrum is not the end. It is just the beginning of an eye opening and awakening of problems in developing software.
If I attack Scrum, it is for two reasons.
- To push us to build on the principles of Scrum and go beyond it to iteratively find an even better process.
- To fight against the blood-thirsty vampire consultants, trainers and organizations preying on the uninformed and making Scrum a commercial enterprise which sacrifices its integrity.
Today I will talk about the latter
Perhaps this isn’t a smart move. Perhaps this will remove opportunities from my path and make people angry with me. So be it. If I am wrong, teach me.
What sparked this whole post is the relaunch of scrum.org. I listened to Pluralcast #12: The Future of Scrum with Ken Schwaber. I truly listened to this with an open mind and was optimistic about the new programs being launched. I bought into the story about the Scrum Alliance becoming a money making scheme and selling certifications. I welcomed the fresh clean break to “free certifications” and altruistic motives. I thought teaming up with Microsoft to bring in a .NET track, and later a Java track, was a great idea. Until I visited the website and found the only difference between scrumalliance.org and scrum.org is who is taking your money.
But please, don’t take my word for it. Let’s look at the pages together.
This is the assessments page, let’s click Professional Scrum Master.
Hmm, there is also a Professional ScrumMaster II on the page below. Let me register and add them both to my cart, so I can take this test and get certified.
WOW! Umm, what is going on here? Didn’t they just talk about how Scrum Alliance was ripping us off and turning Scrum into a money making venture?
Ok, how about Professional Scrum Developer, that one I am really interested in.
Okay, can’t take the test on here the first year. Have to take a course first. That sounds pretty reasonable. Let’s check out the prices of the courses.
Umm. $2000? Then I can be a Certified Scrum Master? How is this different than Scrum Alliance? Okay, what about the Certified Scrum Developer?
Okay, sorry, I’m not sipping that Kool-Aid anymore.
The ScrumAlliance.org courses are even cheaper. (Although, they are still a rip off IMO)
It’s all about the Benjamins
My current assessment of the Scrum consulting world just got worse instead of better. I really wanted to believe in what I heard on that podcast. It seemed really good to me. I even bet the classes will be really good. I know one of the instructors and he is awesome!
The problem is, I can’t trust Scrum.org, and I can’t trust ScrumAlliance.org, not when they are about making money. (That little .org domain on the end is kind of ridiculous). It is pretty clear to me that this is what the whole Scrum movement has become. When all the dust settles and the consultants have certified every Scrum Master in the world, will software development really be better?
If I am wrong, tell me. I won’t filter the comments here. Ken, if you want to, address this post. Do so, you have a right to and I won’t filter your response. Sorry if I am “hurting your guys business”, but my conscious does not allow me to stand by and say nothing.