Why Agile and Why SAFe and more insight on Scaled Agile Framework
SAFe and JIRA:
Why Agile and Why SAFe and more insight on Scaled Agile Framework?
When the customer/company wants to see early piece of working software functionality then agile methodology is one of the best ways. Ideally build some functionalities leading to the bigger roadmap of the program. AGILE works because of reduced risk, increased commitment, transparency, frequent feedback and reviews.
Agile methods are widely applied and adopted in software development by many companies or programs. We can hear more AGILE these days than to find a project being executed in Waterfall or any other SDLC.
SAFe is one which is booming in recent years being adopted by the customers to implement it across the Enterprise to see the best result.
Now what is an Enterprise and why this term is always coined with SAFe?
“An enterprise application or EA as it is called is a large software system platform designed to operate in a corporate environment such as business or government.”
Some Quick Insights on SAFe are Scaled Agile Framework (SAFe®) was created by Dean Leffingwell having the structure/framework divided into Portfolio, Program and Team. Release in the recent year’s SAFe methodology has been widely adopted at the Enterprise level. The structure is divided into Portfolio, Program and Team Level and there by instructs with the set of guidelines to be followed at every stage of these three levels. This framework needs to be adopted by the executing programs at the Enterprise levels.
Recommendations about Adopting SAFe:
- Develop small functionalities and then give a larger roadmap for the larger functionality
- Ensure that the teams understand the features à User Stories and be in line with the Acceptance Criteria
- Obtain the Agile Teams Feedback as and when appropriate
- Strive working towards TDD(Test Driven Development)
- More clarity on the information about the release
- Increased traceability on the build and deployment
- Elimination of manual metrics tracker and reports
Glance to see how a project works in SAFe:
- The Business team members are mostly a part of the Portfolio. They bring in the new Epics, monitor the budget, and manages the new Epics using Kanban.
- The Program Manager or the RTE predominantly manages the various releases in SAFe for the project. As SAFe stands for Enterprise there would be multiple RTE’s.
- The SAFe team has to be subdivided into multiple teams at the Enterprise level having a designated Scrum Master, Product Owner (Predominantly a person the Business Team) & the team (both Dev and Testing).
The teams in SAFe will have their own Iteration dates, mostly it will be the same for all the teams working in one program.
- Pre PI Planning:
PI (Potential Increment) Planning is the first step of the project’s execution. This is predominantly carried out in 2 or 3 days by the project teams located across the globe.
- RTE Facilitates this PI Planning allowing the Scrum teams of the program to participate
- This activity mainly helps teams break the Epics/Features(Both Architectural and Business) into small user stories and then build the Roadmap for the particular release
- Product Backlog is then prepared for each and every scrum team and the user stories are divided into Sprints to be worked upon
- Sprint Planning: Sprints or iterations as they are called as usually prolongs for 2 weeks, so for a release (If say for example a release is planned every 10 weeks) of 10 weeks there will be 5 sprints and each of 2 weeks duration.
- Scrum Master for each team will facilitate this meeting
- The user stories assigned and aligned for each sprint will be discussed and updated with the acceptance criteria on the sprint planning
- The Scrum team will have to raise their queries if any in par with the acceptance criteria and if anything is missed out with respect to the Acceptance criteria the team can suggest the PO(Product Owner) to add the same
- The Sprint team there by starts working on the sprint with the list of user stories, the development and testing team is advised to have a Story Kick off Meeting to again discuss the understanding of the user story. This is just to ensure that the team is not deviated from the goals to be achieved.
- The testing team is advised to prepare the test scenarios to get it reviewed by PO/Test Leads, update the comments if any and then start preparing the test cases.
The test cases can also be shared with the Dev team at the same time when it is shared with the Test Leads for review, this helps the testing team to get feedback from the dev team if any test case is missed.
- Mid Sprint Review- This is again facilitated by the scrum master and is scheduled at the middle of the sprint to review the status of the user stories, to get the confidence vote from the team members and thus decide how the sprint will proceed further. If the confidence vote is very less and there has been no good progress till then, the scrum master will move the stories to the backlog
- As and when the user stories are completed testing, the user stories are moved to the Queue of the PO for review and acceptance. There will be demos shown to the PO.
- At the end of the Sprint the scrum teams of a Program will give a System Demo to the RTE and the Portfolio Managers, this is again a check to ensure that the teams have built the right features meeting 100% goals of the project needs.
- The same is repeated for every Sprint and at the end of one PI all the above activities are again repeated until the program completely meets the goals.
Offshore Team Activities:
- Release planning input
- Planning Poker and estimation
- Build and unit test stories
- Application test stories
- Test planning, preparation and execution –Integration Test, SVT and ORT
- Application deployment
- Application support
Onshore Team Activities
- Backlog definition
- Release Planning
- Business value definition and measurement
- Planning Poker and estimation
- Story verification
- Integration (E2E) test planning and execution support
- Deployment support
- Support readiness
- Application support (client liaison)
- Agile coaching and training
JIRA - Atlassian Product that’s one of the best tool to be implement a SAFe Agile project.
Too much of any new process or new Tool will scare any one, there is always this question of How Do I get started? It is just simple to follow step by step procedure to implement SAFe hand in hand with JIRA.
SAFe is measured at 3 levels – Portfolio, Program and Team Level and JIRA helps planning and tracking various reports and activities at these levels. Few highlights of JIRA are mentioned below:
- Portfolio and Program planning inside and tracked in JIRA
- End to end visibility of epics, features, and stories. The statuses for each of these can be tracked and monitored inside JIRA
- One stop solution to manage work across the Project, Program, and Portfolio levels
- Single source for Agile data and metrics (KANBAN boards & Reports, Burn down charts for the teams)
Starting from the Portfolio traversing through till the team level, JIRA helps in creating the various tasks and Kanban boards. The Kanban boards gives a pictorial representation of the activities at various stages and this can be tracked for Portfolio/Program and Teams.
Epics or Features (High Level Requirements) implement a business need. Thus User stories are derived from the Epics. Tasks are created from the user stories for the teams both dev and testing teams. Traceability is maintained from the portfolio until the execution and back way.
JIRA helps create Epics or Features, User Stories, helps in creating sub tasks for the teams, estimating these in story points, it enables us to have customized status for the JIRA that’s created and assign it to the respective person and thus track. While estimating it also enables us to log the hrs and thus implicit the % of the estimated hrs used for any JIRA.
JIRA by itself has the feature of creating and displayed various reports or Burndowns or Kanban boards. This enables the top management as well to see the status of the program at any given point of time.
SAFe along with JIRA is what an agile project should begin with !!!
Outline/structure of the Session
Want to present a case study on how SAFe was implemented in a project which was being executed in Waterfall methodology, the target audience can be people who are working in Agile or the leads who are looking at moving to Agile model.
After the session the audiences will surely have a strong idea on SAFe and its benefits. The session will surely give a complete insight of the SAFe agile methodology and the change it has brought in the project
People Who want to Implement Agile