When was the last time you asked your team to determine what’s working and what’s not? Don’t be afraid to ask the hard questions, because the root of the problem may not be your process, it may be how you categorize work, how it flows across your organization, or your fluidity.
Suppose you have single points of failure in your organization that hold critical knowledge or are concerned about the time spent on rework and reverse engineering. Maybe you are just concerned about the cost associated with onboarding new employees and the time it takes getting them up to speed. In all of these cases, you may want to rethink what you are and are not documenting.
Documentation Examples ·Brand Strategy / Brand Style Guide ·BRD/MRD/PRD ·Product Briefs ·How Might We Diagrams ·Opportunity Maps ·Value Stream Mapping ·Service Blueprinting ·Reference Architectures ·High Level Software Designs ·Architecture Decision Records ·C4 Models for Software Architectures ·Solution Architecture Documents (ARC42) ·Software Requirement Specifications (IEEE 830) ·Software Bill of Materials ·User Personas, Buyer Personas, Market Segmentation Profiles ·Creative Briefs ·User Stories, Use Cases, Jobs to Be Done ·Wireframes, Mockups, Prototypes ·Customer Journey Map, Storyboards ·BPMN or EPC Workflows ·Call Flows/System Flows/UML sequence diagrams ·Data Dictionaries and Transaction Models ·SDK’s and Application Programming Interface specifications ·Component Specifications, Product Spec Sheets ·Release Notes, Method of Procedures, Runbooks ·FAQ, How To, What’s New, Quick Start guides
Have you ever felt like no matter how hard your team is working, you can never get ahead of the fire drills? Does it feel like your retrospectives are not really working? There may be a good reason for this, and it’s called debt. Some debt can be burned off, but debt can also compound and impact your quality, responsiveness, productivity and cycle time. It’s hard not to focus resources just on quick wins or your backlog, but it can pay to take a longer view beyond your burn down chart.
Is it time for a serious talk, or an organizational physiologist?
There are over 55 formalized frameworks, processes and methodologies for managing software development projects. The choice of what philosophies will guide your teams is probably one of the most important decisions you may face.
Each strategy is designed to address specific issues relevant to type of work, organizational structure, business goals, experience level, cost, quality, project size, context switching, release frequency, risk avoidance, coordination, collaboration, transparency and productivity.
Some developers prefer to only work with prescriptive processes while others are open to adaptive methodologies. Aligning ideologies early is as important as choosing your architecture, enterprise integration pattern, software stack or operational model.
From my experience Kanban seems particulary well suited for Platform development teams. Compare it to Scrum and you will see why.
Kanban primarily follows four core principles:
Visualize work Create a visual model of work and work flow, so as to observe the flow of work moving through the Kanban system. Making the work visible, along with blockers, bottlenecks, and queues, instantly leads to increased communication and collaboration.
Limit work in process Limit how much unfinished work is in process and reduce the time it takes an item to travel through the Kanban system. Problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP.
Focus on flow By using work in process (WIP) limits and developing team-driven policies, the Kanban system can be optimized to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.
Continuously improve Once the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can change the system to improve the team’s effectiveness.
Similarities to Scrum
use pull scheduling
use transparency to drive process improvement
focus on delivering releasable software early and often
based on self-organizing teams
require breaking the work into pieces
the release plan is continuously optimized based on empirical data (velocity / lead time)
Differances
Scrum
Kanban
Timeboxed iterations prescribed.
Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work per Sprint.
Commitment optional.
Uses Velocity as default metric for planning and process improvement.
Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed.
Cross-functional teams optional.
Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint.
No particular item size is prescribed.
Burndown chart prescribed
No particular type of diagram is prescribed
WIP limited indirectly (per sprint)
WIP limited directly (per workflow state)
Estimation prescribed
Estimation optional
Cannot add items to ongoing iteration
Can add new items whenever capacity is available
A sprint backlog is owned by one specific team
A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team)
Doesn’t prescribe any roles
A Scrum board is reset between each sprint
A kanban board is persistent
Prescribes a prioritized product backlog
Prioritization is optional
Advantages of Scrum
Advantages of Kanban
Transparency
Flexibility
Widely understoud
Focus on continuous delivery
Predictable quality
Increased productivity and quality
Product centric
Increased efficiency
Team members focused on good enough
Team members focused on incremental
Allows client to change priorities and requirements quickly
Reduction of wasted work/wasted time
Some teams blend the ideals of kanban and scrum into “scrumban.” They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from Kanban. For teams just starting out with agile, however, I strongly recommend choosing one methodology or the other and running with it for a while.
