Paul Adams

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