“It looks like our developers drive the business, not the other way around…”
I heard that one day from the UX guy at an early-stage startup I was mentoring.
Their founder/CEO was busy with fundraising, creating a leadership vacuum.
The UX designer decided to put on the cap of a product manager with a goal to accelerate product delivery.
What happened next was predictable to anyone familiar with Agile methodologies:
UX: “We know what we need to build! So I will simply assign stories to the developers, one by one.”
UX: “Joe, how much time do you think you need to build the registration component?”
Joe (Engineer): “2-3 hours, I think.”
UX: “Ok, I assign this user story to you.”
Needless to say, team motivation dropped, work continued to pile up, and delays increased dramatically.
Why This Approach Failed
There are many reasons:
- The product manager role was misunderstood: Instead of focusing on user needs, market research, success metrics, and backlog management, the UX person became a micromanager of tasks
- The delivery process, roles, and accountabilities became unclear
- Team cohesion dissolved: A group of individual contributors is not a team – they often compete rather than help each other
Besides, the fundamental Agile concepts were misapplied:
- User stories were treated as individual work items when they’re actually team efforts (usually involving frontend, backend, integration, and QA)
- Work items should be individual contributor efforts, while user stories require teamwork
- Single-person story estimation is inherently inaccurate
- In Agile, teams should focus on completing one story at a time rather than starting many simultaneously
- In Scrum, the product manager/owner is responsible for the Product Backlog, whereas the team is responsible for the Sprint Backlog and how work gets done
If you work in Agile way, forget about assigning tasks. This kills self-organization and accountability.
The core Agile values emphasize self-organizing teams taking accountability for outcomes rather than just completing assigned tasks.
Agile values:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Scrum values:
- Commitment: Team members committing to achieving their goals and supporting each other
- Courage: Having the courage to do the right thing and work on tough problems
- Focus: Focusing on the work of the Sprint and the goals of the team
- Openness: Being transparent about work and challenges
- Respect: Respecting each other as capable, independent people
The most effective approach usually involves the team collectively owning the work and determining the best way to accomplish it.
Scrum vs. Kanban for Early Stage Startups
The approach to choose depends on your startup’s stage and resources:
Pre-Seed, Early Seed Stage:
Resources are typically too limited for proper Agile training, so you have three main options:
1. Simplified Kanban Implementation:
– Easier to adopt with minimal training
– Provides visual workflow and identifies bottlenecks
– Flexibility to adapt processes without rigid ceremonies
– Start with basic columns: To Do, In Progress, Test, Review, Done
– Add WIP limits once the team understands flow
2. Hire Team Members with Agile Experience:
– At least one team member should have practical Agile experience
– Can guide implementation without external consultants
– Look for this skill when building your early tech team
3. Outsource to Agile-Experienced Vendors:
– Tech service providers often have established Agile practices
– Can deliver value quickly while you focus on business development
– Consider this if building an in-house team isn’t feasible initially
Remember, delivery is the most expensive process.
Late Seed/Series A:
1. Consider bringing in an Agile Coach or Kanban Coach (part-time may be sufficient) and/or Scrum Master
2. Invest in proper team training on Agile methodologies
3. Implement Scrum, Kanban, or Scrumban based on your product development needs:
- Choose Scrum if: You need structured planning cycles, have a complex product with interdependencies, or want clear timeboxing for investor updates
- Choose Kanban if: You need continuous flow, have rapidly changing priorities, or prefer minimal overhead and ceremonies
- Choose Scrumban if: You want a hybrid approach that combines elements of both methodologies
When to Choose Scrumban
Scrumban combines the structure of Scrum with the flow-based approach of Kanban. Consider this hybrid approach when:
1. Transitioning from Scrum: Your team understands Scrum but finds some aspects too rigid or ceremonial for your current needs
2. Handling varied work types: You have both planned feature development and unpredictable support or maintenance work
3. Building team maturity: Your team needs some structure but also flexibility to evolve their process
4. Reducing planning overhead: You want time-boxed iterations without extensive sprint planning sessions
5. Maintaining flow while time-boxing: You need steady output with some predictable delivery windows
In practice, Scrumban often means:
- Using a Kanban board with WIP limits
- Keeping some time-boxed iterations (often 1-2 weeks)
- Holding regular stand-ups and retrospectives
- Planning on demand rather than full sprint planning
- Pulling work when capacity allows rather than committing to sprint backlog
- Focusing on cycle time and flow metrics over velocity
Understanding Kanban Boards
Regardless of your full methodology choice, a Kanban board serves multiple important purposes:
1. Transparency: Everyone sees progress (if work items are moved promptly)
2. Communication: Team members can signal when they’re stuck and need help
3. Measurement: When properly maintained or integrated with tools like GitHub, they enable accurate performance tracking and predictions
4. Flow Optimization: WIP limits can be set to improve workflow efficiency
Implementing a Better Process
Whether you choose Scrum, Kanban, or a hybrid approach, follow these steps:
1. Agree on a clear delivery process that everyone understands
2. Clarify roles and responsibilities (especially Product Owner vs. Development Team)
3. Align on a workflow that helps deliver value quickly and makes sense for your team
4. Define policies like Definition of Ready (DoR) and Definition of Done (DoD)
5. Establish key team meetings that improve transparency and collaboration
6. Start measuring cycle time and identifying bottlenecks
7. Retrospect regularly to improve your process and take action you agreed upon each retrospective
Remember that both Scrum and Kanban require some training or experience to implement effectively. Attempting to adopt these methodologies without proper understanding often leads to superficial implementations that miss the core principles.
The most important thing for an early-stage startup isn’t which Agile methodology you choose, but ensuring you have a structured approach to product development that enables rapid delivery of customer value while maintaining quality and team cohesion.
Wish to start making meaningful progress?
