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.
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.
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.
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
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.
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.
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
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.
A Feature is a Subsystem service that contributes to a
stakeholder need. It is equivalent to a Subsystem Requirement.
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