I have been practicing couple of simpleprinciples in the way I develop software.• Do not bite more than what you can chew. (IOW: Keep your Sprints small)• The Value of what you are developing should be measurable and must be measured. (IOW: Business Value is most important UoM for any software)• Work under development should be visible; and that should be the only version of truth. (IOW: A simple Kanban Board can make wonders)What follows is based on my tinkering so far.
iteratively & effectivelyThis is the way software should be built^.
Every software is built for Market Needs.Market needs which are validated and onwhich the Product Owner is betting thesuccess of Product.
Typically a Market Need would expand tomultiple User Stories.
It is well accepted practice for developers tothink User Story as an actionable task.
But it is fundamentally wrong to schedule aUser Story in a Sprint.For that matter in any Sprint.
In fact measuring the scope of a User Story itself isfundamentally wrong. It does not matter whetherwe measure in Days, Hours or Story Points.All methods are equally wrong.
Gauging the scope of a User Story isroot cause of many blunders in workscheduling & shipping.
A User Story is invariably an expandingphenomenon. Number of Acceptance Criteriafor a User Story keeps on growing over time.And all are not equal in Business Value points.
It is not a must that all Acceptance Criteria of aUser Story should be done in one Sprint.In fact it is far smarter way to tackle aUser Story thru multiple Sprints.
That is what MMF principle is all about.Functionality that is absolutely basic requirement of a User Story.Something which adds more power & punch to the User Story.Something which makes the User Story very simple & elegant to use.
And these Acceptance Criteria keep growingon & on & on.
islanBRIDGE works on the premise that a set ofAcceptance Criteria form a Sprint.User Stories do not form a Sprint.
Which Acceptance Criteria (from the backlog)should form your next Sprint ?Sometimes this is a business priority decision;Sometimes a decision driven by dependency.
islandBRIDGE encourages you to adoptplan by RoI.Each Acceptance Criteria has ‘effort required’ and the‘Business Value’ it will generate; & hence the RoI.
Business Value is quite accurate anddispassionate way of measuring the progressof a software.Required v/s Developed v/s Shipped
Dashboard can highlight the broken ValueFlow.Like in this case lot of Business Value is builtbut not yet shipped.
Kanban board is a dead simple way to bring invisibility and ensure single version of truth.The place where a Sticky Note can be just dragged tonext stage when work of that stage is done.
Each Work Item is denoted by a Sticky Note.islandBRIDGE believes that any Work Item on this planet is• either an Acceptance Criteria• or a Bug Fix
LEAN philosophy strongly encourages you tolimit the “Work in Progress”.Limiting the WIP is of paramount importanceto avoid chaotic mass of half baked code.
Kanban board provides indicators formonitoring the amount of Work in Progress ina specific stage.
It monitors whether the Work in a stage is• Too less• Too much• at Healthy level
Kanban Board in islandBRIDGE offers 3 levelsof abstraction.This is Kanban Board for work-items.It is as simple as a physical board, but works fine for teams distributedacross the continents as well.
Kanban Board in islandBRIDGE offers 3 levelsof abstraction.This is Kanban Board for Sprints.
Kanban Board in islandBRIDGE offers 3 levelsof abstraction.This is Kanban Board for Sprints. Single click can providegist of the Sprint thru Burndown Chart & Test Cases executed.
Kanban Board in islandBRIDGE offers 3 levelsof abstraction.This is Kanban Board for Releases.
In Software Engineering it is very commonpractice to assign a work-item to a resource.So much so that it has become the de facto practice;Even considered as sacrosanct practice.
This work-item has no Resource Assigned Yet This work-item has a Resource AssignedislandBRIDGE believes that a work-item• Can be assigned to a resource (ideal when co-ordination is critical).• Can be picked by a resource (ideal when self initiative is welcome).What really matters is, it should be clear to all, whethersomeone has become responsible for a specific work-item.
Assigning a work-item to a resource is straight.(Typically done by Dev Lead)Pulling a work-item in ToDo list of self is alsoequally simple.
Building a Software for complex business needis like knitting wool to create floral designs.The inter-dependency among components is very critical.Lack of understanding can create crashing results.
Set of Impact Analysis maps is visual ReadyReckoner of a software system and it addsimmense clarity for developers.An Impact Analysis map can be linked to any work-item.
islandBRIDGE is built for Collaboration.A team member can add a comment for a context.If a team member requests your inputs on a comment,islandBRIDGE gives you intimation here.
LEAN methodology encourages you to firm up your hypotheses early,get them validated, and always keep them on radar to revisit them.islandBRIDGE facilitates you to do this in a structured manner.Here is the Elevator Pitch of islandBRIDGE.BTW islandBRIDGE is iteratively built using islandBRIDGE itself.
Want to try out islandBRIDGE ? Get in touch … firstname.lastname@example.org