What Agile and Scrum are to teams, SAFe (Scaled Agile Framework) is for companies. CodeBeamer comes the first proven implementation of SAFe.
What Agile and Scrum are to teams, SAFe (Scaled Agile Framework) is for companies. CodeBeamer comes the first proven implementation of SAFe.
The Scaled Agile Framework is based on a number of trends in modern software engineering, including:
* Lean software development (LSD) is a translation of lean manufacturing practices to the software development domain, and emerging within the Agile community. Lean development can be summarized by the following principles:
Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation.
|Legacy PPM||Agile PPM is forced by SAFe concept|
|centralized control||decentralized decision making|
|project overload||continuous value flow|
|detailed project plan||lightweight business cases|
|centralized annual planning||decentralized rolling wave planning|
|work breakdown structure||agile estimating and planning|
|project based funding||ART - agile release trains|
|project control||self managing teams|
|waterfall milestones||objective fact based measures and milestones|
Agile Program Portfolio Managements has to be based on transparency.
Investment themes differ from epics and features in that they are not prioritized backlog items.
In codeBeamer the Kanban board can be used for Epics as well as for other items, like User Stories and Features. The Epics’ workflow (e.g. Funnel, Backlog, Analysis, Implementation) can be also visualized in codeBeamer on the Kanban board. Visualizing item’s in their current workflow status is very important to maintain process and value flow. Kanban board can be used to detect and eliminate bottlenecks, by setting up WIP (Work in progress limits).
The Portfolio Vision holds the value streams, investment themes and portfolio backlog epics that represent the comprehensive vision for a portfolio of programs for a single instance of SAFe. To assure that we focus on value delivery, the Lean|Agile enterprise organizes around these value streams, structures one or more ARTs to implement each, and then manages budget allocations via investment themes, one per ART. One special investment theme, the portfolio backlog investment theme, holds the budget reserve for cross cutting business and architectural epics. In so doing, we centralize portfolio-level decision making for strategy, value streams, budgeting, and cross cutting epics, but we decentralize implementation by empowering each ART (Agile Release Trains) with the budget and decision making authority needed to fulfill its mission.
The Portfolio Backlog is the highest-level backlog in the Framework, in CodeBeamer Business and Architectural Epics are stored there, and Demands are also managed and estimated there. Demands are coming from the business level; their prioritization is supported by the Planning board. In Portfolio Backlog there are prioritized items, demands that are under the different stages of voting, prioritization and approval.
Business epics are demands, that are generated from the business, and will be executed via projects through IT development and IT operations. CodeBeamer supports Demand Management, capturing ideas, demands’ prioritization, workflow definition, and evaluation and approval process. Demand Management is integrated into the whole application lifecycle; therefore it provides a full traceability on demand's execution status.
Business epics share crosscutting relations of
Architectural Epics are large technology initiatives, cutting across:
They arise from:
The Enterprise Architect works with business stakeholders and System Architects to drive holistic technology implementation across programs. Within the context of the Framework, the enterprise architect is focused primarily on the following responsibilities:
The Epic Owner is responsible for driving individual Epics from identification, through the analysis process and Kanban systems, to the go/no go decision making process of Program Portfolio Management, and when accepted for implementation, working with the Release Train development teams and Product Management to initiate the development activities necessary to realize the business benefits of the epic. Once successfully initiated, the epic owner may have some ongoing responsibilities for stewardship and follow-on. The Epic Owner role in SAFe, is just that— a responsibility assumed by an individual—not a job title.
The role may be assumed by:
or other any program stakeholder suited to the responsibility. Typically, an epic owner works with one or two epics at a time, which fall within their area of expertise and current business mission.
Epics are development initiatives that encapsulate the new development necessary to realize initiatives that cut across multiple programs in the portfolio. The definition, analysis, selection and implementation of epics are key economic and value drivers for the program portfolio.
There are two types of epics in SAFe:
Epics are indeed “epic” in nature, as they typically cut across three business dimensions:
Product Vision is to communicate the strategic intent of the program.
The Program Vision:
Common formats of product vision:
The Program Vision has to answer the following questions:
Roadmap is a development plan with new releases, features and product versions for an established timeline horizon.
The roadmap is used to align teams involved in the ART (Agile Release Train), in software development.
Product Management provides the "content" for the Agile Release Train. It means:
Release Management Team, in responsible for scheduling, managing and governing synchronized releases (PSIs) across one or more programs and product lines. The main responsibility of the team is to facilitate the software developed by the ATRs. The Release Management Team is usually consist of Release Train Engineer, along with senior representatives from product management, marketing, quality, program management and operations/deployment /distributions.
The program backlog contains all features, user stories that will be take into consideration for development.
The program backlog:
The program backlog is a short term holding stage for itemized features from the Program Vision.
Seminal, cadence-based event– Release Planning meetings has to be organized every 8-12 weeks, usually one or two days long.
The result of the meeting: A committed set of program objectives fort the next PSI.
Release Planning supports the alignment of development to business across Team and Program objectives.
The release planning board shows the sprints that belongs to certain releases. User stories, and requirements are attached to sprints, that will be developed by the development team. Sprint runs 2-3 weeks, and once all sprints are finished and all attached requirements are developed the next release of the product is ready for delivery.
UX provides guidance for a consistent user experience.
The RTE is the "Uber - Scrum Master" for the Train.
Agile Release Trains are self organizing teams of agile teams, reliably and frequently delivering enterprise value. Agile Teams typically consist of 50-100 individuals organized around Agile Release Trains. Teams are aligned to a common mission via a single Program Backlog. Teams having their dedicated resources are creating Potentially Shippable Increments/Releases every 8-12 weeks.
The main rules of the release train are:
Medium and large organizations divide Development and Operations into separate departments. While Development departments are driven by user needs for frequent delivery of new features, Operations departments focus more on availability, stability of IT services and IT cost efficiency. These two contradicting goals create a “gap” between Development and IT Operations, which slows down IT’s delivery of business value. Development and Operations collaboration “DevOps” was built to fix this situation.
Take a set of user stories from the backlog and refine, code, test, and accept. It has to be done usually within 1-4 weeks, sprints’ duration are very short.
The input into team backlog comes from Program Backlog, Team Context and Stakeholders. In theTeam Backlog all items are estimated.
Features are services that fulfill user needs. Features describe what the product will do for its users, and the benefits the user will derive from them.
The basis for prioritizing the Program Backlog is:
Potentially Shippable Increment
A PSI provides a strategic quantum of timebox and value to the enterprise.
PSI is often not a release cadence.
Scrum, a lightweight and effective software project management framework, is by far the most common Agile practice being adopted today, so the clearly defined roles in Scrum describe the structure and behaviour of a prototypical Agile team. Scrum has only three roles:
- Everybody tests. Everybody codes. –
Developers & testers make up the majority of an Agile Team usually 7+/- 2 members.
Developers write the code for the User Stories and conduct research, design, and prototyping. The developer’s responsibilities include collaborating with the Product Owner and testers to make sure the right code is being developed; writing the code, unit tests, and automated acceptance tests; and checking new code into the shared repository every day.
Testers work in parallel with developers to write acceptance test cases (also automated wherever possible) while the code is being written; interface with the product owner and developers to confirm that the code and acceptance tests reflect the desired functionality; execute acceptance tests; and maintain the test cases in a shared repository.
The Product Owner is the member of the team responsible for both defining and prioritizing the Team Backlog. In addition, the product owner has a significant role in quality, and is the only team member empowered to “accept” new stories into the system baseline. In the context of SAFe, however, the role takes on additional relationships and responsibilities, primarily via participation in the Product Management Team (often via dotted line report to a Product Manager). Moreover, some of the traditional team-level authorities of the Scrum Product Owner, such as authority for the full product definition, and return on investment (as is often determined by defining pricing and licensing policies, etc.) are either shared with (or more typically the responsibility of) the enterprise Product Manager.
The Scrum/Agile Master is the Agile Teams working servant leader who
The scrum/Agile master is responsible for four things.
codeBeamer Development Management module extends Git, Mercurial and Subversion with Configuration, Change and Defect Management capabilities. It helps software development teams using Git, SVN or Mercurial with additional integration workflows, security and collaboration extensions.
Take a set of user stories from the backlog and refine, code, test, and accept. It has to be done usually within 1-4 weeks, sprints' duration are very short.
codeBeamer supports the Waterfall and the “V” development processes, to comply with regulations and standards especially in the automotive (e.g. ISO 26262), in the medical (e.g. IEC62304) or in the government field. defined by government agencies and the production industry.
The classical waterfall development process is supported by codeBeamer across the five main modules of the tool.
The main differentiator between Agile and traditional requirements management is to keep definition of requirements as short as possible. It is due to short iterations (sprints), when PSIs are delivered frequently and feedback from the users can be collected quickly. Requirements defined by end users (product owner, stakeholder) are in a specific track er called „user stories” tracker. User stories are the smallest items on that developers can work.
At each user stories can be set the (1) release, in which this requirements will be delivered, (2) the priority- how important is the requirement, (3) assigned to - to define who is in charge to develop that item, (4) status according to the predefined workflow, and (5) story points.
Story points can be given to each user stories to determine the complexity of one user story item.
This model has been inspired by the SAFe (Scaled Agile Framework) by Dean Leffingwell 2008-2011 ©
Agile has been used widely by software developers and Scrum teams for more than a decade. Now Agile, which is in an alternative to Waterfall, seems to be the “new standard” for enterprises. Today more and more enterprises are realizing the benefits of Agile and the implementation of Agile is ramping up – especially in the industries in which it is important to shorten the delivery and release phases. The real challenge is to get teams to adopt practices in which every team member is responsible for implementing and executing certain tasks at the enterprise level.
If enterprises decide to “go Agile” they can choose according to their specific needs, from different methodologies and processes such as Scrum, XP (eXtreme Programming), Crystal, FDD (Feature Driven Development), DSDM (Dynamic Systems Development), Adaptive Software Development, RUP (Rational Unified Process) or the more recent Scaled Agile Framework as developed by Dean Leffingwell.
As Ken Schwaber explained, SAFe is built on different iterative and incremental predecessors, such as the Rational Unified Process (RUP), a popular iterative and incremental software development process framework. The key question is whether enterprises really benefit from Scaled Agile Framework (SAFe), which is all about using the Agile framework at the enterprise level. The rate of enterprise adoption of Agile with the Scaled Agile Framework has been accelerating, we have seen remarkable results being achieved by the adoption of SAFe.
codeBeamer 7.2 is the first implementation of SAFe in the Agile world. It sets itself apart from its competitors in that it enables Agile planning/scheduling while maintaining an established discipline of requirements, tests and development management tools. Another key differentiator is that codeBeamer provides versioning (baselines) and traceability for all artifacts, so vital for quality assurance (QA) and compliance (especially in the medical, automotive and aviation industries). Demand Management in codeBeamer is essential for trackng demands and prioritizing requirements across departments. It provides valuable functionality that helps forecast demand and meet consumers’ expectations.