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
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
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!
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
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
Seems like everybody learns this in Project Management 101 and then forgets it
Despite that there’s still a lot of truth to it!
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
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?
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!
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!
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
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
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
Draw some reasonable boundaries
Prevent misunderstandings
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
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)
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…
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…
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!
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…
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.
Thank you.
It has been a pleasure
I love this stuff
Hope it has helped
Please contact me anytime