doing agile with an iso-20000 telco (agilept 2015)
TRANSCRIPT
Doing Agile with an ISO-20000 Telco
a story from the trenches
Manuel PadilhaCTO
«I don’t think anyone could object to a ban on the word [Agile] when it is used as a noun. That’s just plain wrong. (...) Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”»
Dave Thomashttp://pragdave.me/blog/2014/03/04/time-to-kill-agile/
So, lets change the title of this presentation
Developing software with Agility with an ISO-20000 Telco
Project Scope
So, translating from marketing-speak:
1. build something from scratch
2. mimic existing functions (that were organically added over the course of the last 15 years)
3. dramatically change architecture
4. add new stuff while we’re at it
“Replace a set of legacy applications with a brand new, distributed, fault-tolerant, high-performance system, keeping all existing functions intact [and, by the way, we also need this and that].”
A film distribution and exhibition companywhich is part of a larger Telco
The Customer
Two very different cultures
one is a small (core team is < 50 people), mostly autonomous company with a vertical structure
the other is a telco behemoth, with rigidly defined processes and a mostly horizontal structure
In this project
The small company provides “requirements”
The large company manages the project and deals with the IT side of things
Project kick-off conversation(October) We need this done by mid June. You
must start right away and we’ll clear things up as you move along.
First we must write the spec. And the test plan. Then we’ll discuss migration, deployment and roll-out strategies. After that we can refine the project plan and agree on milestones and deliverables. Meanwhile we’ll ask IT to provision Dev and QA environments, and once that’s set up you can start building software - this should happen around February. Oh, and we need 3 months to do acceptance and load tests, a production pilot and a phased roll-out, so you’ll need to be finished by March.
small company sponsor
large company project manager
small company sponsor large company project manager
has a hard deadlineis comfortable with flexible scope
trusts their “life-time” partnerdoesn’t care about document signoffs
cares a lot about the product quality and maintainability (he will be paying for it!)
will enforce hard deadlineneeds a fully defined scope
distrusts partner by principledocument signoffs are part of the process
maintenance is someone else’s jobcares a lot about the quality of the documentation
*but you still have to play it
No.
Pack your bags and go home? Give up and do waterfall?
No. No!
*but you still have to play it
Let your development team use Scrum and keep them isolated from Project Management.
Allow customer interaction at sprint reviews (and whenever needed), but make sure there is a separate meeting with the PM.
Prioritize the backlog according to the milestones agreed with the PM. Be prepared to negotiate changes.
Never forget
You’ll be judged by what you deliver, not how well you play the game*
The Project Plan vs. The Product Backlog
Scrum says you should keep a product / project backlog and feed a sprint backlog from it. There is no master plan.
Project Management procedures say we need a Project Plan with deliverables and milestones that is signed out by the Project Manager and key stakeholders before the project starts.
So, what now?
You can’t escape the Project Plan, so guess. Guess the best you can, but with no fear of failing.
Project Plans need to be signed out, but they can be changed later on.
Use the Project Plan as a kind of informal Product / Project Roadmap and stick it to your Scrum wall.
Do not impose it on your team. Listen.
a) We need to replace our current self-vending eletronic payment provider. Your software should interface with the hardware directly.
- No, it would take forever to obtain the mandatory software approval from the payment broker.
- Yes, we have inside connections, we can do it “really fast”(inside information: it didn’t happen).
Change Management
b) We need to change the way we perform eletronic payments online.
- Oh wait, we can’t, it’s not safe.
- Yes we can, just do it already.
c) We need the same supported operating system across the entire platform, it’s going to be X.
- Ooops. X won’t run on current hardware. Let’s upgrade it!
- Ooops. No budget.
- Hang on, there’s a huge hardware maintenance budget. We can slash it if we buy new hardware…
- There’s this procedure for buying expensive things, it will take 3 more months...
The Project Manager will ask for detailed work logs by requirement.
Your Team will spend time refactoring, experimenting, prototyping and generally building software, not orderly checking off items on a requirements document.
So, what now?
Time Keeping
Lie. In good faith, but lie. Provide bulk work logs and remind your project manager that they bought a finished product, not a bag of hours / resources (this will be tough).
Do keep a record of time spent on work items, whatever they may be. JIRA is more than enough for this. That will help in retrospectives and might, on occasion, be useful feedback for the Project Manager. Just make sure your development team isn’t hindered by it. Their time is precious. Yours, not so much.
Agile = GoodPlanning and Processes = Bad
Right?
No, not really...
During development the PM helped keep the customer in check, making sure he didn’t change is mind too often.
He did put some pressure on us, but it was mostly healthy dose.
Once he adapted (ha!) to an agile team, it was mostly smooth sailing.
A professional PM is proving essential for the final stages of this project, adequately managing risk before deployment, something the customer would not do by itself.
Summary
Phase 1 - The Fellowship of the Ring
The fellowship is a team of 5 full-time developers + me.The product owner role was played by one of the developers.
For 6 months we did 2-week sprints, daily standups, sprint reviewand planning meetings. We kept product and sprint backlogs.We even had a planning poker deck! (but never used it).
We released working software with every sprint, except for the first two.The customer never used those releases as the “dev environment” took > 6 months to
prepare...
During this time we layed out the foundation for the whole product and built working versions of allcore features.
Team communication was vital at this stage as everyone was touching each others code all the time.
The Gory Details
Phase 2 - The Two Towers
Or several towers to be more accurate. The team grew and we were building software at full speed.At a given time there were 9 people working on this full-time.
But the core product was stable, the architecture and data model were mostly done and not as much coordination was needed.
We still did sprints, but they grew longer (~1 month), and we stopped doing daily standups.(Don’t worry, everyone still talked to each other plenty)
At the end of each sprint we’d deploy to customer servers and demo the product live.This went on for about 4 months and then...
The Gory Details
The Gory Details
Phase 3 - The Return of the King
And then, one day, we were “mostly done”.The team shrank dramatically, 3 then 2 and currently just 1 personand not even full-time.
We’ve been through functional testing (done by “test experts”), load testing (by “load test experts”) and acceptance tests (by the customer - yay!).
Roll-out will begin (hopefully!) 1 week from now.Shouldn’t we be in “crunch mode” by now?!
No. We never were in “crunch mode”.No one ever pulled an all nighter.
(except for drinks…)
Waterkind-of-scrum
Fall
The chart to rule them all
ProductVision
Acceptance & Deployment
Coding & Testing
IntegrationInformal Specs & Design
