Selling (and Managing) Agile Contracts

Editor's Notes

• #4: Legalese is for EULAS! I am not a lawyer Don’t even play one on TV We generally use simple SOWS for services Sometimes they are more formal Technically they are contracts We really like to think of them as tools for setting mutual expectations
• #5: No big trade secrets here Although I will be talking about some things we are working on Pretty sure most here are not in content management and media/publishing space But even if I am wrong, I am less worried about competition More focused on spreading the gospel as it were Sharing ideas Trying to help change the industry for the benefit of all – us and out clients
• #6: Launched in 2006 Currently at version 4.1 10,000+ daily users Global customer base STM Education Legal Media Technical Publishing Products managed Books Journals Magazines Standards Digital assets JAVA Front End With MarkLogic Native XML (or NoSQL) db on the backend Not familiar with MarkLogic? Suggest you check it out!
• #8: Small virtual teams: x number of JAVA/RSuite Engineers, one or two Content Engineer, and 1 PM/Analyst Most allocated ½ time (split between max of 2 projects – Trying to change that at least with offshore guys) Seasoned vets on shore Knack for talent off shore (Latin America) Offshore team members are first class participants Mix of Scrum, Kanban/ScrumBan Use it for Core and Projects Java architecture (plugins) Success with automated testing, builds, and deployments JIRA, Confluence, IM, Skype, GTM, Yammer
• #9: Clients push for this But fail to recognize that it just does not work – and in fact can’t ever work Cold hard reality is that specs are never perfectly communicated or understood Things always change over time Teams learn along the way Inevitably you end up encountering issues and negotiating scope in an effort to meet schedule and budget with available resources OR you go late or spend more and argue about change orders then someone is unhappy
• #10: Seems like everybody learns this in Project Management 101 and then forgets it Despite that there’s still a lot of truth to it!
• #11: The illusion of big up front analysis As I said never communicated or understood perfectly – especially in the rush at the beginning of the sales cycle
• #12: Another illusion – that of control Had a former colleague, turned consultant for one of our recent large clients actually said this to me… Why would anyone place bets on an approach that has proven itself to be so flawed?
• #13: Don’t want to divert attention and get into debates on this aspect But I shudder when I get RFP’s or requests to include this in SOW If we are doing change management – we are wasting time that could be better spent responding to client priorities or feedback We expect and embrace change vs. resisting it and trying to control it Also we do our best to prevent defects but we know they are going to be found – and we want to be able to build and deploy ondemand and with confidence I would much rather see an image of a Judo practicioner on this slide than that sad blimp!
• #14: Clients do not fully understand and cannot express requirements Teams cannot fully understand requirements immediately People make mistakes, things are discovered, and requirements evolve along the way Allow for all of that But always provide clients with good value for their money Just make sure you don’t go out of business while you are doing that Bottom line the process has to solve your clients problem in a reasonable time and cost And you have to make some money while doing that. If it works out your business will grow > success!
• #15: and here we get to the heart of the matter… First we encourage clients to focus on MVP & simplicity Early Return Point is we fix the schedule 8,10, or 12 weeks for small, med, large Fix the budget use a blended or fully loaded rate for resourcing at a certain level over that period Leave details of the scope to vary based on decisions of the team – with guarantee to meet certain high priority objectives Could call this “Variable Scope” or “Negotiable Scope” It is really just a variant of fixed price where the scope part is fixed at a higher level vs. detailed specs, etc. Dog leg left or Dog leg right… Many paths to the same destination
• #16: Examples… Written by the client Not user stories but could be A bit more technical than we usually like But the key is Describes at a high level what client wants to accomplish Leaves the details AND IMPLEMENTATION CHOICES for the team to work through
• #17: Point here is that client sets priorities Usually include some language stating that the objectives and priorities are provided as an initial starting point but can also change – AT THE CLIENTS DIRECTION Again it is about expecting and allowing OR REALLY EMBRACING CHANGE Also obligates us as the supplier to stand by our work – fix defects make good on the deliverables even if schedule/budget are exhausted – ideally this would not occur but that to me is just the agile way
• #18: Draw some reasonable boundaries Prevent misunderstandings
• #20: Human Kinetics – was first successful “real” agile project at RSI, became basis for approach since 2010. They remain to this day one of our best reference clients. IET – really struggled at first, UK time zone issues, stopped, did do some additional analysis became model for future projects, now to the point were 1) they actually wrote us check prior to having SOW, it is known as perhaps the most successful series of projects internally, converting all projects to agile, and have said publically that while skeptical at first they now would not consider working any other way – sounds familiar to me! Harper – big complicated global enterprise, grown by acquisition, scary RFP, crazy requirements – pioneered use of Kanban for last sprint/warranty period and actually beat our go live date at end of 2nd iteration now. Other stories here too… all a bit different
• #21: This really speaks more to the internal benefits More efficient getting to project closure More efficient resource allocations It is the predictability of it that works And we don’t get into these never ending death marches because we simplify and establish a mindset based on FLEXIBILITY provided we meet the high level objectives (vs. 300 pages of requirements that must be met)
• #22: http://stevehandyblog.wordpress.com/2014/05/28/agile-contracts-the-big-secret/?utm_source=twitterfeed&utm_medium=twitter Don’t really want T&M if I have to report actual hours used – but can make it work, esp in some cases e.g. where you have NO idea how long something will or won’t take Not OK with fixed if they have change management and really super details specs – but sometimes you gotta play…
• #23: More stuff found in my research Don’t pretend to be an expert in gov contracting Will say that we have not seen ANY of this in our gov or quasi gov work (we get some) But thought this doc was really interesting Just published in august Did not review in tremendous detail but like parts I skimmed Sounds like they really get it! Does talk about these two models as relevant Again not an expert – but community seems to be interpreting this as flexible master with lots of pretty tightly defined but shorter addendums. Not sure I really like that. But also describes openness to other/undefined approaches Questions aside, found this surprising but generally in a good way to hear…
• #24: IET experience led to onboarding, essentially a sprint 0, some might quibble with that in another situation but it really works for us… New teams need to get to know each other get familiar with objectives, review requirements, agree on a proposed solution, and get some logistical setup tasks done As I said earlier I hate hate hate reporting hour by hour burn per each resource To me that’s’ our business – we committed to meeting the objective within a given time and budget, how we resource that is our opportunity and/or problem Switch to kanban – not prefined timeframe, are we done yet, are we done yet, are we done yet, yes! And wow – sometimes that can be early! I was interested in WIP limits and believed in them but had no experience, maybe could not explain well enough, management was concerned but we made a good enough case and they agreed – and then the light bulb went on. It worked – but now I know it would have worked better had I been more aggressive. Now somehow people believe me and agree much easier!
• #25: Organizations with inflexible RFP process requirements Internal management: Try to allow early termination But what am I going to get (exactly)? How long will it take (exactly)? How much will it all cost (exactly)? …and the famous: Just give me a rough ballpark for budgeting Sometimes you gotta play esp. if it is a rigid RFP process – then get them on your home field for the follow-up deal Tough to work on that next deal while knee deep in the current one Easy when you have some idea what you are getting into vs. blackbox dev…
• #26: Backlog planning Demos Retrospectives Pairing Automated Testing for long running projects Connecting our build and deployment processes for core and projects Trying to eliminate adversarial conversations around support for core vs. customer, limited warranty, etc.
• #27: Thank you. It has been a pleasure I love this stuff Hope it has helped Please contact me anytime