I constantly encounter developers that just flat-out hate SharePoint. Which is totally okay, because it has warts, for sure. An easy comparison, as an example, is versioning your database. Let's do this:
To say the least, SharePoint provides some easy targets.
Developers always point out how much they hate SharePoint in hopes that I will be able to tell them why they're wrong, or at least be able to give them some extra perspective as to why I'm okay with SharePoint. We're not going to get into the full "why use SharePoint at all" question for now—I don't think I'm qualified to give the answer to an unknown audience in written form. What I will give instead is my throwaway response:
"You lose control with SharePoint."
Hopefully by the end of this post, you'll get an idea of what I mean by lose control.
I was most fascinated by this "Position of no power" presentation from the Agile Toolkit podcast series, apparently recorded at Agile 2006. Yes, 2006; that's not a typo.
Anyway, I was fascinated by a story told at 29:27 of the episode (transcribed below is 29:27 through 31:30):
[context: Q&A session; previous comment was about cutting features from a sprint]
"Just a quick comment, I'm with the same company…I witnessed a meeting on that note where developers and Lex got together. There were a whole bunch of storycards, and they added to more time than allowed, and yet—they were all needed.
Lex: About twice the time.
Yeah, about twice the time! It was a pretty big factor! And Lex—you talk about being stubborn—it was really cool to watch. Lex stubbornly said "We cannot cut business value. We must meet this business value at this time. We cannot do it. And, I don't want you guys killing yourselves working overtime, so let's get creative." Several of the newer developers kept coming back to "Well! Well! Time for you to cut scope!" And Lex stubbornly said, "Nope, we're not leaving this room until we get this into the time allotted!" And then, magic started happening, and it was really cool! And it took…it actually had to go through that stubborn phase. And then one of the developers said "ok fine", and picked up a card with a big estimate, and said "Okay, well, why do you need this?" And Lex explained it, and the developer said "well, wait a minute! But if that's why you need it, would this work instead?" and gave an example of a totally different feature, and Lex said "well, that would be so much better; I hadn't even thought that was possible. That would meet my need even better than I had asked for!" Developer said, "that will take a tenth of the time." And everybody wins! And we kept doing that, story after story! The team did. It was really cool. I think that is the heart of Agile, and especially for Agile developers, one of the things we as leaders can do, is to keep that strong focus on "it's not just about 'cut scope';" it's about finding the creative solution to get more need met in less time and cost. That is absolutely critical.
Lex: It works better, I've found, if you do it right before a meal, too. Timebox it with food.
What fascinated me most about this story is that a) following standard estimation practices, developers gave an estimate; b) customer declared we cannot cut business value; c) something magical happened, d) developers (legitimately!) reduced their estimates.
What happened in magical step c above? What does this have to do with anything? Let's roll onward and find out!
Let's go at this from another (more direct) angle. Check out DotNetRocks #268 with Vishwas Lele, and DotNetRocks #307 with Sahil Malik. They both start off by describing the fact that you get a great deal of value out of SharePoint if you are allowed to give an "80% solution". I.e., this may not be exactly what you wanted, but it gets 80% of the job done, and it took me three minutes to implement, while you were discussing who has the A for setting up teleconferencing for the next meeting. It's already done.
They both agree that this magical place is where you gain value out of SharePoint as an application development platform.
I'd like to draw together these two facts:
From the Agile 2006 presentation above, in order to reach this magical state we need what amounts to a pressure cooker: squeeze, and eventually you'll get toothpaste. But as she mentioned, they had to go through the stubborn phase first. This sort of thing did not occur naturally.
And now for SharePoint. It is my proposal that with SharePoint's wealth of built-in features, we are constantly attempting to fit the customer's "first pass at requirements" into SharePoint's existing featureset. If we don't find a fit, and if we don't find a solution, then we haggle—maybe they can change their human process, just a little? Maybe the formatting of that email alert doesn't matter so much? Maybe we don't need to format the web part precisely the way they asked? Maybe it's okay if the SharePoint site looks like a SharePoint site?
With SharePoint, we (both we the developers and we the customers) are forced to think creatively, and as such, are given a great competitive advantage over slimmer frameworks ("slim" like vanilla ASP.NET; yes, I know how ridiculous that sounds). This is my perspective. With SharePoint, you lose precise control over your technical solution, but you gain a different type of flexibility—you are thinking creatively, "out of the box."
Remember Me
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u
Powered by: newtelligence dasBlog 2.2.8279.16125
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2008, Peter Seale
E-mail
E-mail