Do we need one more Kanban tool for building Software ?

1. I have been practicing couple of simple
principles 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.

2. This is the way software should be built.

3. iteratively & effectively
This is the way software should be built^.

4. Every software is built for Market Needs.
Market needs which are validated and on
which the Product Owner is betting the
success of Product.

5. Typically a Market Need would expand to
multiple User Stories.

6. It is well accepted practice for developers to
think User Story as an actionable task.

7. But it is fundamentally wrong to schedule a
User Story in a Sprint.
For that matter in any Sprint.

8. In fact measuring the scope of a User Story itself is
fundamentally wrong. It does not matter whether
we measure in Days, Hours or Story Points.
All methods are equally wrong.

9. Gauging the scope of a User Story is
root cause of many blunders in work
scheduling & shipping.

10. A User Story is invariably an expanding
phenomenon. Number of Acceptance Criteria
for a User Story keeps on growing over time.
And all are not equal in Business Value points.

11. It is not a must that all Acceptance Criteria of a
User Story should be done in one Sprint.
In fact it is far smarter way to tackle a
User Story thru multiple Sprints.

12. 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.

13. And these Acceptance Criteria keep growing
on & on & on.

14. islanBRIDGE works on the premise that a set of
Acceptance Criteria form a Sprint.
User Stories do not form a Sprint.

15. Which Acceptance Criteria (from the backlog)
should form your next Sprint ?
Sometimes this is a business priority decision;
Sometimes a decision driven by dependency.

16. islandBRIDGE encourages you to adopt
plan by RoI.
Each Acceptance Criteria has ‘effort required’ and the
‘Business Value’ it will generate; & hence the RoI.

17. Business Value is quite accurate and
dispassionate way of measuring the progress
of a software.
Required v/s Developed v/s Shipped

18. Dashboard can highlight the broken Value
Flow.
Like in this case lot of Business Value is built
but not yet shipped.

19. Kanban board is a dead simple way to bring in
visibility and ensure single version of truth.
The place where a Sticky Note can be just dragged to
next stage when work of that stage is done.

20. 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

21. LEAN philosophy strongly encourages you to
limit the “Work in Progress”.
Limiting the WIP is of paramount importance
to avoid chaotic mass of half baked code.

22. Kanban board provides indicators for
monitoring the amount of Work in Progress in
a specific stage.

23. It monitors whether the Work in a stage is
• Too less
• Too much
• at Healthy level

24. Kanban Board in islandBRIDGE offers 3 levels
of abstraction.
This is Kanban Board for work-items.
It is as simple as a physical board, but works fine for teams distributed
across the continents as well.

25. Kanban Board in islandBRIDGE offers 3 levels
of abstraction.
This is Kanban Board for Sprints.

26. Kanban Board in islandBRIDGE offers 3 levels
of abstraction.
This is Kanban Board for Sprints. Single click can provide
gist of the Sprint thru Burndown Chart & Test Cases executed.

27. Kanban Board in islandBRIDGE offers 3 levels
of abstraction.
This is Kanban Board for Releases.

28. In Software Engineering it is very common
practice to assign a work-item to a resource.
So much so that it has become the de facto practice;
Even considered as sacrosanct practice.

29. This work-item has no Resource Assigned Yet
This work-item has a Resource Assigned
islandBRIDGE 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, whether
someone has become responsible for a specific work-item.

30. Assigning a work-item to a resource is straight.
(Typically done by Dev Lead)
Pulling a work-item in ToDo list of self is also
equally simple.

31. Building a Software for complex business need
is like knitting wool to create floral designs.
The inter-dependency among components is very critical.
Lack of understanding can create crashing results.

32. islandBRIDGE encourages & allows easy way
to create Impact Analysis maps among
components & modules.

33. Set of Impact Analysis maps is visual Ready
Reckoner of a software system and it adds
immense clarity for developers.
An Impact Analysis map can be linked to any work-item.

34. 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.

35. 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.

36. Want to try out islandBRIDGE ? Get in touch …
bitbybetterbit@gmail.com