Doing agile with an ISO-20000 Telco (AgilePT 2015)
Download as PPTX, PDF0 likes540 views
The document discusses the challenges and strategies of implementing agile practices in a software development project for a telecommunications company involving two distinct organizational cultures. It emphasizes the importance of maintaining flexibility in scope while adhering to a structured project management framework, despite cultural clashes and differing priorities between the small development team and the large company's management. The project evolves through distinct phases, highlighting effective team communication, sprint management, and the eventual need for professional project management to mitigate risks before deployment.
![«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](https://image.slidesharecdn.com/agilept2015-doingagilewithaniso-20000telco-150626160846-lva1-app6892/85/Doing-agile-with-an-ISO-20000-Telco-AgilePT-2015-2-320.jpg)
![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].”](https://image.slidesharecdn.com/agilept2015-doingagilewithaniso-20000telco-150626160846-lva1-app6892/85/Doing-agile-with-an-ISO-20000-Telco-AgilePT-2015-3-320.jpg)
Doing agile with an ISO-20000 Telco (AgilePT 2015)
- 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
Editor's Notes
- #3: Falar um pouco sobre a ideia de que desenvolvimento Ágil tem que obedecer a um conjunto de regras e práticas bem definidas. Argumentar que desenvolvimento ágil é apenas e só aquele que é capaz de se adaptar rapida e eficazmente às mudanças.