A story from the trenches regarding a software project developed for a Telco company. The challenges faced while dealing with a mostly Agile customer that is part of a larger company with heavily defined processes. The "way out" and how to deliver working software with close to zero spec and still complying to project management requirements, customer timings and own company budget.

1. Doing Agile
with an ISO-20000 Telco
a story from the trenches
Manuel Padilha
CTO

2. «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 Thomas
http://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

3. 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].”

4. A film distribution and exhibition company
which 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

5. 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

6. small company sponsor large company project manager
has a hard deadline
is comfortable with flexible scope
trusts their “life-time” partner
doesn’t care about document signoffs
cares a lot about the product quality and
maintainability (he will be paying for it!)
will enforce hard deadline
needs a fully defined scope
distrusts partner by principle
document signoffs are part of the
process
maintenance is someone else’s job
cares a lot about the quality of the
documentation

7. *but you still have to play it

8. 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*

9. 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.

10. 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...

11. 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.

12. Agile = Good
Planning 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

13. 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 review
and 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 all
core features.
Team communication was vital at this stage as everyone was touching each others code all the time.
The Gory Details

14. 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

15. 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 person
and 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…)

16. Water
kind-of-scrum
Fall
The chart to rule them all
Product
Vision
Acceptance &
Deployment
Coding &
Testing
Integration
Informal
Specs &
Design

17. ?
Thank you!
manuel.padilha@grupoatwork.com