Session 3b The SF SaaS Framework
Download as PPTX, PDF0 likes282 views
This document discusses using a Lean software development methodology for a SaaS application built on Azure. Key reasons for using Lean included having a distributed team with non-dedicated resources. The methodology focused on short 2-hour tasks, limited ceremony, and continuous delivery through "Show and Tell" environments. Initial tasks involved planning releases, stories, and base architecture. Development involved decomposing stories into small tasks in TFS and continuous integration testing. Benefits included opportunities for learning and delivering in small increments with a distributed team.
Session 3b The SF SaaS Framework
- 1. SaaS and Azure A practical example of a real-world SaaS application done with LEAN software development. • Paul Adams, Sr. Consultant, Project Management Office Practice
- 2. Lean How we built it
- 3. Why did we go Lean? • Align Methodology to Project, not the other way around • We have a project team disconnected in both geography and time • Resources not dedicated to the project full time (catch as catch can) • Resources volunteering time (difficult to plan for resources) • Sprints would not work out but Releases do • Lean is simple, and has few odd artifacts • Rapid start for new volunteers • Rapid contribution – provide value in single sitting 3
- 4. ‘Community’ Lean • Release has clear set of functionality that must be working on a date • Releases not sprints • Allows for Distributed team – time and location – • Allows for Volunteered time • 2 hour time slices/tasks • Limited ceremony • Leverage TFS as much as possible to enable collaboration and tracking • Continuous delivery, continuous UAT via “Show and Tell” environment • Lean is simple, and has few odd artifacts
- 5. Initial tasks • Project Management – Identify and document initial stories – Define releases – Prioritize the most important features for each release • Technical – Lay down project organization in source control – Define base architecture – Define initial schemas and entities Then begin development cycle
- 6. Lean work items in TFS Has Fails Requirement Test Case Persona Leads to Bug User Story Task Assigned Has When it Risk happens
- 7. Personal Experiences with the new methodology • Lack of ‘safety blanket’ – Detailed estimates & plan – Detailed specs – Dedicated resources • Changed perspective – Having the team define their own tasks is more appropriate – Seeing the process as a learning opportunity, rather than expecting perfection at the start 7
- 8. Lean opportunities and benefits • Eliminate waste • Amplify learning • Decide as late as possible • Deliver as fast as possible • Empower the team • Build integrity in • See the whole • Latent skills 8
- 9. Why it works / What it works for • Why – Allows team to contribute in own time – Small delivery increments • What – Great opportunity to learn new technology and flush out issues (refine as you go) – Skunkworks projects – Part-time resources
- 10. Next Phase of our project • Layer on more developers who will follow this process – Pick off a simple task to learn architecture (lower priority) – Decompose the story with the SME – store in TFS as tasks – Validation test cases for requirements – Tasks (2 hours or less) must be done all in one sitting – Do it – Check in • Validations – Continuous Integration with Automated Testing – SME review on preview site – Peer code review
- 11. Takeaways • Lean is not for every project – smaller teams • Would have benefitted from more envisioning and more architectural work up front, especially if we could have dedicated two solid full time 100% resource weeks to it before going into “community mode” • Align experienced, skilled, motivated people with tasks that they know well • Keep task durations SHORT and enforce the no-long-checkouts rule • Freely create tasks often to keep work granular 11
Editor's Notes
- #5: ‘Community’ Lean