What phase or type of development?
What kind of work is being done? This can change weekly, monthly, yearly. Many Agile projects start with a “Sprint Zero”, but unless it is as short as other sprints, it’s actually a planning and base architecture phase, some research and proof-of-concept development needs to take place before work can be defined, prioritized, and planned into sprints. If you acknowledge one or more teams are in this phase, other teams can interface more effectively than if assumptions are made that the team will be completely done on a certain date.
All too often a Proof of Concept gets seen by a stakeholder and an assumption gets made that it can go-live with ease. By acknowledging that projects & products are working on a POC, expectations can be set that the team has to enter a product development phase after the POC is complete.
| Phase or Type | Research | Proof of concept | Product Dev | Lean Operations |
|---|---|---|---|---|
| Development targets: | Peel the onion and learn more | Emerging tech, new concepts, | New products, add features to existing products | Repeatable deliverables, such as customer roll-outs or adding reports |
| Why this approach? | Emerging tech, new concepts, not sure how things will end up | Get a small thing done and demoable, make it robust later | Grow customer base, grow profits, long term focus | Operational targets, tying together existing tech, IT integrations |
| Estimating takes place… | For some projects, each thing takes a week | Timebox, decompose and size in points to know big and small topics | Story points track velocity and value | Well before being assigned to a developer, repeatable known work |
| Planning takes place… | Discuss a vision, set constraints, work will fill space permitted | Define the MVP like and other story, plan and deliver alongside other work on the board | Plan top value with quickest delivery, weighted- shortest-job-first or similar | Well before the work, a pipeline of incoming tasks is known or projected |
| Changes? iterations? | Discuss next steps as you go | Often the POC was for a demo, so after a review, polish for demo, demo again, then convert to normal dev cycle when warranted | Backlog! Roadmap! | After a post-mortem, next time might go differently |
| Scope reductions? Narrow focus? | Pause the research and try something else | Timebox, pivot | Define MVPs (Viable) then MMPs (Marketable) | Always look for ways to minimize the work needed to deliver |
What kind of process will work best right now?
You can invent your own process, but starting points should be based on proven methodologies. Within each of the main process types a myriad of options exist for the inner workings of the team. When each team has a base methodology, other teams can interface with them as opportunities for new inputs are understood.
| Process Type & Considerations | Waterfall | Scrum | Kanban | Hybrid |
|---|---|---|---|---|
| Development targets: | Milestones | Potentially shippable working software every [2] weeks | Sequential work, Swimlanes for priority of list of tasks | Some of this, some of that |
| Why this approach? | Deadlines, contracts, timelines, proposals/bids | Planned development embracing demos and discussion. Size in points, which reflect value being delivered. | Operations, things come up, to-do lists. Size in points or hours or days | Contract with flexibility |
| Estimating takes place… | When contract is written to put a cost in the bid | Backlog grooming, discussion expands acceptance criteria | Tasks, maybe all about the same size, or known sizes | Some before, some during. Waterfall estimates to start, iterative estimates as you go. |
| Planning takes place… | Plan a phase, waterfall through SDLC | Sprint planning, release planning, big room planning, see scaled agile or LeSS agile, | Daily, weekly, whatever is needed. Lots of triage and changes | Annual/quarterly roadmap with milestones, just-in-time refinement per sprint. |
| Changes? iterations? | Iterate only if time permits, or budget is added | Pivot after sprint demos. Plans change, write new stories, groom, size, plan, execute | New priorities go in the board, other items can be pulled off the board | Some changes are easy via trade-offs. Some changes are major contract amendments. |
| Scope reductions? Narrow focus? | MVP? Depends on contract | Potentially shippable, so start small, then grow | One task at a time, constant growth and evolution, suited for ops | Some changes are easy via trade-offs. Some changes are major contract amendments. |