Process and Best Practices

Agile Landscape V10.jpg

There are multitudes of frameworks, philosophies and best practices used in software development. There are also plenty of programming paradigmssoftware development processes, principles and laws.

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.

Undervaluing Documentation

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
·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

Paying down Debt

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?

Kanban or Scrum

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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)




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



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.