Ib slidedeck
- 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