Session 3b The SF SaaS Framework


Published on

Paul Adams

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ‘Community’ Lean
  • Session 3b The SF SaaS Framework

    1. 1. SaaS and AzureA practical example of a real-world SaaS application done with LEANsoftware development.• Paul Adams, Sr. Consultant, Project Management Office Practice
    2. 2. LeanHow we built it
    3. 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. 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. 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 entitiesThen begin development cycle
    6. 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. 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. 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. 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. 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. 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