August 7, 2010 - 15:00, by Dostalek, Kevin
Wrapped up another DevLink today with my session this morning: Building a SharePoint 2010 Development Environment. It was a full room and a great audience. Thanks very much to all who made it in for the Saturday morning session (I know how rough that can be after Friday night shenanigans :)
Anyway, I've posted below a hires picture version of the mindmap used in the presentation as well as a PDF version of the basic installation walkthrough. Below that is a list of all the places we talked about on the internet so that you have all the links in once place. I'd love to hear any additional feedback from the folks that attended (since at least at the moment they appear to have misplaced the speaker evals from this morning-- I'm sure they will turn up though).
Click one of the two pictures below to download the presentation resources:
April 12, 2010 - 11:30, by Dostalek, Kevin
was in the first slot (8:30AM) and I presented my "Leveraging SharePoint 2010 as a Social Computing Development Platform". Now even under normal circumstances that's a pretty heavy way to start off a morning (it's a 300 level developer presentation). However, after I polled the audience at the start, I found I had a full room with only a handful of developers. So I kind of changed my presentation on the fly and did quite a bit more demo'ing of the social computing features (from an end-user perspective) and completely cut out my 3rd demo (creating an activity feed custom gatherer for twitter). All in all I think it went quite well!
For those that were at the session (or my other ones in the past) know that I had an aversion to slide based presentations. However, posted below is both the mindmap version of the presentation (just click on the thumbnail to get a very large pannable image) as well as a slide deck version (just pretend the SPSIndy logo is SPSCLT).
And finally, as promised, the icon to the right will get you a zip of all the code samples I used in the presentation. If you are going to try and actually make this code work your self, you should probably go read this post
, as it has more information about each VS project and what you may need to do to get it all working (read the comments too).
I want to thank the SPSCLT organizers, especially Brian Gough and Dan Lewis, the speakers, sponsors, and attendees for a great event! I'm very happy I made the trip down and hope to see some of you at other events very soon!
March 26, 2010 - 09:48, by Dostalek, Kevin
I'm honored to be speaking at the SharePoint Saturday in Charlotte, NC on April 10th. I'm doing a slightly tweaked and expanded version of my "Leveraging SharePoint 2010 as a Social Development Platform" presentation which is probably my current favorite session to do (although it doesn't have quite the wow factor and broad audience appeal as my End-User Social Computing w/ SP2010 session). My only big decision point is whether to do the PPT version or the MindMap version of the slide content (but really it's 80% demos anyway).
Anyway, looks to be a great time and I will certainly enjoy meeting lots of new people (it's my first "east coast gig") as well as reconnecting with lots of others.
You can find out more information about this event on their official website:
See ya there!
August 19, 2009 - 13:10, by Dostalek, Kevin
Well I attended DevLink
down in Nashville, TN last week. It was my first time, but certainly won't be my last. John Kellar
and all the volunteers did a great job pulling off a super conference that felt more like a huge extended community code camp than what I traditional think of as an "industry conference" (e.g. TechEd, SxSW, PDC, etc...). Don't read that as a negative in any way- it was a great experience, and by far one of the best values all year (it was $100).
The sessions were great and they had even added a SharePoint track this year, so there was no shortage of good stuff happening each day. One thing that I do regret is not checking out the Open Spaces stuff (sorry Alan
, the timing just never worked out). As is often the case with conferences though, it was the networking that happens informally in the evenings that really provides the incalculable value. From the quiet lobby-bar chats to the loud parties out at the Honky Tonks
(Tootsie's Orchid Lounge
was a favorite) I made a ton of new friends that I'm sure I'll keep in touch with and see again and again.
Lastly, let me post a quick soundbite from the closing panel. It's Richard Campbell telling his Goliath story
. Seriously, this guy is a great story-teller- I can just imagine him on NPR or something listening to this.
December 10, 2008 - 11:45, by Dostalek, Kevin
I just wanted to dump some ideas out there surrounding one of the trickiest pieces of using agile development methodologies in a consulting / outsourced environment: Agile Contracts. Much of the musings below come from other sources with my own thoughts mixed in, but one source I'd like to specifically call out is the PDC 2008 session I attended given by Mary Poppendieck
and Grigori Melnik
The Problem with Two Party Interactions
So the first thing to look at is why we even need contracts in the first place. The conventional wisdom is as follows:
- Companies inevitably look out for their own interests
- Contracts are needed to limit opportunistic behavior
What Mary points out though is that really at the core the problem is that there potentially exists conflicts of interest which drive the paranoia of opportunistic behavior. In an ideal setting though we:
- Assume other party will act in good faith (so this requires a level of trust)
- Let the relationship limit opportunism (again, requires trust, but also some basis for the relationship)
- Use contracts instead to do these things:
- Align the best interests of each party with the best interests of the joint venture
- Eliminate conflicts of interest
I'll come back around to how this type of relationship and contract are formed up in a moment, but first lets look at how the two types of traditional contracts fall short of meeting the ideals above.
Problems with Fixed Price Contracts
- Supplier is at greatest risk
- Customer has little incentive to accept the work as complete
- Generally does not give the lowest cost
- Competent suppliers will include cost of risk in the bid
- Creates the game of low bid with expensive change orders (which blows a hole in the primary reason CFO's like fixed-bids, which is budget predictability)
- Generally does not give the lowest risk
- Selection favors the most optimistic (desperate) supplier
- Least likely to understand project's complexity
- Most likely to need financial rescue
- Most likely to abandon the contract
- Customers are least likely to get what they really want.
Remember, that the "protection" that a fixed-bid contract seemingly provides (if we don't like it, we don't have to pay for it) is all illusory. This is because the value that the project is projected to provide is greater than the price of the effort otherwise the project would not move forward. If the effort is "not-accepted", then the vendor is out the costs of the resources employed on the project. However, the customer is out both the costs of their resources involved in the project as well as the anticipated return of the project (which we already said is greater than even the PRICE, much less the vendor's actual COST). So who is the biggest loser here? Obviously depending on the relative sizes of the vendor and customer it may still "hurt" the vendor more, but clearly the customer has more at stake, and so I would contend that fixed-bid "protection" is a fabrication.
Problems with Time and Materials Contracts
While there are many useful scenarios where T&M projects make sense (staff augmentation, etc...) in general there are quite a few problems with them in an outsourced project model as well:
- Customer is at greatest risk
- Supplier has little incentive to complete the work
- Therefore we believe we need to control supplier opportunism
- ENTER: Project Control Processes
- Detailed oversight generally provided by the least knowledgeable party
- Supplier must justify every action
- LIKELY LEADS TO:
- Increased costs
- Artifact creation that does not add direct business value
- An assumption that the original plan is the optimal plan (the one created at a time of lowest knowledge/information about the project)
Candidate Solution: Target Cost Contracts
Circling back to our idealistic world now that we know some of the problems with traditional contracts, let's look at a different kind of contract. How can we build a contract that has the following properties?
- Target Cost defined and includes all changes
- Target is the joint responsibility of both parties
- Target cost is clearly communicated to workers
- Negotiations occur if target cost is exceeded (or projected to)
- Neither party should benefit under this scenario (it's a failure scenario)
- Primary goal of contract is to remove conflict of interest.
In order for such a contract to work there are a few assumptions that probably need to pre-exist:
- We have some basis for relationship and trust.
- This means we may have to start off with a small project using a traditional contract.
- We are probably using an agile development methodology that utilizes fixed-time, fixed-budget, and prioritized variable-scope mechanisms (backlogs,etc...)
The structure of this contract includes the following:
- An unbrella or framework contract with the legal stuff in it.
- Establishment of a target cost
- Work themes defined in stages (prioritized)
- Stages should be small to limit risk for both parties and to provide everyone with frequent points to revisit the value-proposition of the relationship
- Scope beyond the current stage remains fluid and negotiable
- Contact should describe the relationship, not the deliverables
- Contract should set up a framework for future agreements
- Contract should clearly define a means for mediation if no agreement can be reached. (this is important!)
So what I've found in my almost 15 years in this industry, is that our best customers always seem to end up in this type of contract model anyway (after perhaps a few projects using a traditional contract). But wouldn't it be better if we could actually LEAD into a relationship with this idea in mind and use it as a means to better define our value-proposition and distinguish ourselves from competitors? (or at the very minimum, get to this model sooner than later so that everyone can be more productive).
Those are my thoughts, please share yours!