Strategies for getting going quickly yet sanely
This describes how we apply our deep IT experience to the full lifecycle from engaging through design, development, and transition of a Salesforce system.
This high-level sequence of activities help us focus on specific achievements along the way, in a logical approach:
Who’s involved? When and How do we meet? Where do we store our notes?
What are our hopes and concerns?
What is the budget from the organization and each person?
What are the risks?
What are the priorities?
What are contingency actions?
How will we work together?
All this provides clarity so people know the boundaries of the work ahead.
2. Needs, Roles, Deliverables
Who will participate and when? What is the cadence of work and meetings?
What do we want as features of the system?
Which are needs vs. wants?
What are the deliverables toward putting features in the system?
The list of everything that can be done we call the Product Backlog.
Overlaps at points in time would require additional resources or a split in focus of work.
What is the strategy for tradeoffs between quality, cost, time?
What is the definition of “done” or “good enough” for each deliverable? (to minimize surprises later)
All this provides transparency so people know what they are in for.
3. Environment Processes
When everyone is comfortable getting changes into productive use, as a team, is when the team is really working together.
In “green field” situations where an organization is starting from scratch, we begin with a temporary sample/demo set of databases and code.
Code includes tests and utility tools (Wireframing, Salesforce features, Git, backups, etc.).
This is a key aspect of modern “DevOps” strategy, in order to move fast but also safely.
Every participant is granted a custom set of permissions applicable to his/her role, and provided with training on how to update the sample system. We build security first so the system is always ready for production use.
At the end of this phase, people know whether they can work together using the system.
4. Incremental build of value
It is our experience that small increments of useful change is more productive than “big bang” releases. That is because of the greater customer participation and quicker course adjustments possible.
User story documents about what will be created do not cover every detail (not a contract).
Individual tasks are defined to realize each deliverable or resolve an impediment.
To stay targeted on what’s most useful (to avoid waste), constant vigilence about tradeoffs and targets, and agreement about them, is necessary.
We have found it helpful to visualize all the tasks being handled on a Kanban board, where a card visibly represents each task. This example is of the JIRA system:
A card first appears in the “ToDo” column to realize a deliverable or resolve an impediment.
Cards within each stage are sorted by the highest priority. This enables workers to pull tasks rather than having tasks pushed onto them.
Bottlenecks are avoided when team members are multi-skilled. So skill-building (cross-training) tasks are included among the work (and project time allocation).
When coding begins on a card, it is moved to the “In Progress” (“Doing”) stage.
Cards move into the “Done” column meet all criteria for being shippable to production. Quality is assured by automated tests and checklist items evaluated as work is done. The objective is for code to be deployed into production automatically when all tests and checklist items are marked complete.
There ar additional stages to enable teamwork: When a task is associated with a person, it is moved to the “Ready” stage while clarifications are discussed. Cards in “Testing” stage indicate the need for team review. There is a “blocked” status so others know when to offer help. When a task enters “Ready for Review”, stakeholders can jump in.
Each day we hold short meeting when the Product Owner explains the logic of priorities to maximize business value, then resolve conflicts with technical dependencies and impediment tasks. Before each scrum, status and impediments are logged and each person reviews the KanBan board to see what each of us did the day before and what we aim to do that day.
PROTIP: During daily scrums, rather than hold what amounts to a “roll call”, each developer summarizes an analysis for how to segment work into discrete units flowing into production, including risk identification and mitigation. Many individuals use the “Pomerdero Technique”, which segments each day into 50-minute sessions of work followed by 10 minutes of relaxation.
How does each person pick SCRUM cards to work on?
Many teams designate a WIP (Work In Process) limit of how many cards the team can work on simultaneously. This is sometimes necessary to reduce cycle time - how long it takes for tasks to travel through the team’s workflow.
Kanban limits the capacity based on preventing multitasking with work-in-progess limits. Scrum limits capacity by focusing on limited time (2-3 week) section of their backlog.
While working on each increment, we consider all aspects holistically: the UX, Database Schema Design, Testing, Performance, Migration utilities, manual workarounds, etc. Our focus is delivering working code increments rather than comprehensive documentation.
When changes need to be organized into releases, we keep to a regular cadence of pre-scheduled system demos (every two weeks) to review a group of changes going into production.
If we discover during our work that something can’t fit within the “time box”, we reduce the scope of features. “Fit in” includes all aspects necessary for “productive use” (security, migrations, testing, training, etc.).
After each sprint, the team together reflects on what happened and brainstorms possible improvements in how the team works, to define some “actionable experiments”. Some call such meetings “retrospectives”.
Preparations, Cadence, Roles
This diagram summarizes how we roll:
Development Lifecycle Roles
In a smaller company, one person can wear many hats, but in a larger company, specialized roles define what each person is responsible for. Logical roles include the following:
- Release manager manages the release schedule and coordinates releases with the business. The release manager could be in charge of pulling changes from version control.
- Product manager provides the business requirements of apps and features, and works with the development team to implement those requirements. The product manager also performs user acceptance testing to ensure that requirements have been implemented.
- Software developer develops new functionality in sandbox, including both declarative point-and-click development and code.
- Quality engineer tests new functionality in sandbox.
- Administrator performs administrative tasks in the production org, and tracks all changes made in production.
- Trainer conducts training of company employees for new applications and features.
The Product Owner prioritizes work items to ensure the team delivers business value.
Scrum Master is a facilitator of Agile adoption and removes obstacles external to the team. In some Agile frameworks, the Scrum Master takes does “Project Manager”.
The above implements the “5 stages of innovation”:
- Define an innovation project and the key stakeholders you’ll involve.
- Discover the needs and opportunities of your customer.
- Dare to imagine a bold solution to fulfill your customers’ needs.
- Do the work to rapidly demonstrate the validity of your concept and how it will work.
- Drive momentum to ensure adoption and growth of your vision.
An example of checklist:
- User Stories
Agile within Salesforce
The above are explained in these courses covering development processses within Salesforce:
Trail: Learn Salesforce Agile Practices consists of:
Trail: Learn Atlassian Agile Practices consists of:
Trailhead Module: Atlassian Agile Basics
Trailhead Module: Atlassian Overview of Agile Frameworks (Scrum and KanBan) +200
- https://developer.salesforce.com/blogs/engineering/2014/08/meet-gus-keeping-salesforce-agile.html (unifying Bugforce, Scrumforce, and QAforce)
- Manage Your Agile Development from Salesforce Oct 26, 2016 Ray Pendyck (@raypendyck) demos Salesforce’s Agile Acelerator on AppExchange for licensed users.
- Agile Accelerator Community
- Getting Started PDF from Summer ‘16.
More about Salesforce
This is one of a series about Salesforce
- Salesforce Ohana (about the Salesforce organization and people)
- Salesforce Glossary (of acronyms)
- Salesforce Exhibitors (at Dreamforce)
- Salesforce Onboarding (Trailhead and IDEs)
- Salesforce Offerings (Clouds, Industries, Domains, GitHub, editions, pricing, features, versions)
- Salesforce Certifications (training and exams)
- Salesforce Project Plans
- Salesforce Apps (in AppExchange)
- Salesforce Alexa
- Salesforce Heroku (external apps)
- Salesforce Non-Profit Success Pack
- Salesforce Data Management
- Salesforce Einstein
- Salesforce Selenium (test automation)
Tutorials under construction (listed alphabetically):
- Salesforce Apex programming
- Salesforce Apex Testing
- Salesforce APIs
- Salesforce Automation
- Salesforce Bolt
- Salesforce Customization (objects, fields, page layouts)
- Salesforce Field Service
- Salesforce Inbox
- Salesforce IoT
- Salesforce Lightning UX
- Salesforce Mobile
- Salesforce NPSP (Non-Profit Success Pack)
- Salesforce Reporting & Analytics (Custom Reports)
- Salesforce Security
- Salesforce Selling Success Factors
- Salesforce Visualforce