Github Branching / Feature Branching / FBD, FDD, Traditional Branching

Courtesy: Vincent Driessen
https://nvie.com/posts/a-successful-git-branching-model/

Impact Mapping and Story Mapping

Impact Maps and Story Maps: delivering what really matters from Christian Hassa

Impact Mapping

A methodology meets its limits when it meets people - Alistair Cockburn

Sanjay Kumar on Linkedin

Adopting #Scrum is NOT the primary goal, nor is adopting #Kanban or #SAFe. Not even #Agile.

The primary goal is to generate #better business outcomes in a predictable and sustainable manner, followed closely by creating a work environment that motivates people towards excellence and helps them grow professionally.

Agile (and the chosen process) is the enabler for these goals, not the goal in itself. In other words,#Process must subordinate to #Outcomes, not the other way around.

If it does not, feel free to switch, customize or evolve your current process. If you do not, your agility may be severely limited... DOES NOT matter what fancy name you call it.

Agile Transformation Woes

1. Inadequate or poorly defined reference.
2. Poorly designed training program.
3. Disconnect between old and new models.
4. Inability to choose the right candidate projects.
5. Forcing agile to initiatives that could go waterfall.
6. Ignoring the business, vendor and support teams as part of the transformation.
7. Not providing a career path for Project Managers, Business Analysts, Software Testers or leaving it to the judgement of individual teams.
8. Management using agile to drive their own agenda.
9. Management using agile metrics to compare and drive teams.
10. 
    

The impact of inadequate and dysfunctional training on Agile transformation process: A Grounded Theory study

Source: https://www.sciencedirect.com/science/article/abs/pii/S0950584914001281

This research discovered that inadequate and dysfunctional training was one of the critical issues that affected Agile transformation process. This study shows that comprehensive and functional training is not often provided to support Agile transformation. This paper shows the primary causes of inadequate and dysfunctional training, its adverse consequences on the transformation process, and the heuristic and ad-hoc treatments as the strategies used by Agile teams to cope with this challenge.

Conclusion

Comprehensive training is important in Agile transformation process. Inadequate and dysfunctional training causes several challenges and problems for software companies and development teams when moving to Agile. Several ad-hoc strategies identified by this study can be employed to help software teams and companies facing similar problems.

[Most recent experience proves this...]

Sprint Retrospective Anti patterns
================================

1. There is no Retro
2. Retro is cancelled or postponed
3. Rushed retrospective
4. What should remain within the room during discussions goes out
5. Team members whine instead of constructive discussion. These contribute to the bias that agile is not working
6. Team does not check for items from previous retro.
7. PO absent for retrospectives
8. Not all team members participate.
9. No minutes / notes during retro
10. Retros are endless cycles of blame, fingerpointing, failure
11. Bullying
12. Stakeholders participate in retros (they aren't supposed to).
13. No adequate space; rooms booked adhoc
14. Line managers participate
15. Someone outside team requests for peek into retros.

Sprint Retro

Org culture - and Change

Is your team really a team?

Source: http://www.viktorcessan.com/2018/10/the-first-question-to-ask-when-building-teams-is-this-really-a-team/

It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.

Team Agility Assessment

Epics, Capabilities, Features, Stories (Another View)

1.1.1.1       Epics

Epics are parcels of work large enough to require analysis and financial approval prior to implementation. Epics are analysed before implementation to identify capabilities and enablers (architectural support). Epics may be combined into a single release or delivered over many releases.

Epics are identified in the project road map and are equivalent to a scope statement. Epics shall provide functional blocks that are sufficiently self-contained so as to provide business improvement in their own right. Business Epics shall provide functionality that aligns with and fully delivers upon one or more Business Requirements. Enabler Epics support the technical considerations for the business epics. Epics have the following states: Funnel, Evaluation, Backlog, Implementation and Done.

1.1.1.2       Capabilities

A Capability is a system service which is equivalent to E2E system Requirement that delivers and traces back to high level stakeholder needs. Capabilities are expressed as the benefit that the system provides the stakeholder. A Capability shall be implemented in a single Project Increment Planning and Retrospective. Capabilities are refined and split into Features. Agile principles discourage large up front design and very detailed requirements. The Capabilities should have detail which can be added in the decomposition into Features and Stories.

1.1.1.3       Features

A Feature is a Subsystem service that contributes to a stakeholder need. It is equivalent to a Subsystem Requirement.

1.1.1.4       Stories

A Story is a short description of a small piece of required functionality. Stories are written by teams to further refine the requirements. They can be implemented by a single team in an increment. They are managed in the team backlogs. Tasks can be identified to implement stories.