Agile software development compfest 13

Tech Consultant
Aug. 7, 2021

More Related Content


Agile software development compfest 13

  2. ABOUT ME Panji Gautama SVP Engineering at Mekari 🧑🧑💻 ex-CTO@Kudo, HoE@Grab & VPEng@OVO 👾 ex-Game Programmer for Mobile & Playstation 🎮 avid console gamer PSN @ pgautama 🇯🇵 proud wibu 🔖 scrum master certified 2012
  3. Cloud-based Business Platform that Serves The Best HR, Accounting, and Online Tax Software
  4. AGENDA SDLC Refreshment Agile Frameworks On Being Agile 👨 🧑 💼 🏃 🧑 ♂️ 🧑
  5. SOFTWARE DEVELOPMENT LIFE CYCLE a structured approach to the development workflow with continuous product improvement in mind
  7. Software Development Life Cycle 1 2 4 3
  8. Software Development Life Cycle 5
  10. 1st Attempt ● (SAIC) won the bid and created a classic waterfall project ○ $400 Million + $78 Million Additional Funding ○ 300 person team for Requirements + 6 months = 600 pages of listed requirements ○ 700,000 lines of program code ● 4 Years with no Result 2nd Attempt ● Lockheed Martin wins the new ‘Sentinel’ system a.k.a project 3 years 2006 to 2009. The total project budget was $425M. a) $305M was budgeted for Lockheed Martin. b) $120M was allocated for the FBI to run a massive program office to carry out detailed and prescriptive oversight of the work ● Abandoned after 3 years 3rd Attempt ● FBI CIO took over, hire Scrum Expert (Jeff Johnson) ● 220 person team reduced to 40 ● $20M ● 18 months completed FBI VCF (Virtual Case File)
  11. FBI VCF (Virtual Case File) - LESSON LEARNED Agile SDLC gets things done. incremental approach would be faster because functionality would be developed, and adjustments made, in two-week "sprints." he FBI learned that lesson the hard way in October when the system, during a four-hour test involving 743 users, suffered two outages. The agency made the mistake of running the test on legacy hardware. Don't deploy new software on old hardware Sentinel came in under its $451 million budget. The caveat is that the FBI's original cost estimate for Sentinel was $425 million, it stayed under budget when changed to Scrum. Agile SDLC is relatively cheaper Initially start with custom coding and systems integration involved. Couple of services changed to EMC's Documentum document management software, Oracle databases, IBM's WebSphere middleware, Microsoft's SharePoint, and Entrust's PKI technology. Commercial software plays an important role
  12. TRADITIONAL vs AGILE SDLC Incremental vs Iterative Incremental development is a development approach that slices the product into fully working slices that are called increments. Iterative development is when teams gradually build up the features and functions but don’t wait until each of these is complete before releasing. Traditional phase requires different amounts of time and the involvement of different people. The time needed will depend on the project, but you will never see a balanced amount of time spent on each phase. The agile interpretation of SDLC uses a different unit of work: Sprints. A sprint is a time-box for completing a body of work. It has a consistent duration regardless of the work. Sprints vs Phases A traditional view of SDLC isn’t flexible. During the development process, new findings don’t get incorporated into previous steps. The more agile view of SDLC, however, is flexible. With frequent change anticipated, you can introduce a brand new body of work in the next sprint that bears no relation to the previous sprint’s work. Change is less expensive. Flexibility Tracking a project managed with waterfall is relatively straightforward. Any given project will be in one of seven phases at any given time. Agile doesn’t use the term project in the same way. With this approach, a single team is generally working on a specific product or a service, but might have several projects on their plate at the same time. Project Tracking
  13. AGENDA SDLC Refreshment On Being Agile 👨 🧑 💼 🏃 🧑 ♂️ Agile Frameworks 🧑
  15. AGILE MANIFESTO / VALUES That is, while there is value in the items on the right, we value the items on the left more.
  16. AGILE PRINCIPLES 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4 Business people and developers must work together daily throughout the project. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity -- the art of maximizing the amount of work not done--is essential. 11 The best architectures, requirements, and designs emerge from self-organizing teams. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  17. Agile generally promote a disciplined project management process that encourages frequent inspection and adaptation. scrum is only one of ragile framework.
  18. Assign the role of Product Owner Schedule frequent meetings Hold regular reviews Small Is Best - Time, Scope and Team The project was deliberately kept small, both in terms of scope and the number of people involved. Scope was fixed and relatively small and was kept this way higher chance of success. a person in team who will look after the particular requirements of product users but also the business needs. Apply the necessary changes in the workflow or even the product. Short frequent meetings to discuss goals & update the team about all the important things they need to keep in mind while completing other tasks. It’s smart to meet up at the end of every week to show what each team member has done and review all the the things delivered. BEING AGILE WITHOUT SCRUM
  19. AGENDA SDLC Refreshment On Being Agile 👨 🧑 💼 🏃 🧑 ♂️ Agile Frameworks 🧑
  20. POPULAR AGILE FRAMEWORKS SCRUM fairly structured process that involves self-organized teams who commit to specific deliverables, meet daily and break their work into iterations. Extreme Programming goal-oriented; you set a goal for the team, they work until that goal is completed, and you iterate on the results. Kanban adaptation of lean manufacturing principles, and primarily focuses on limiting the amount of work-in- progress to facilitate high-quality work.
  21. SCRUM 101 2 recognised Scrum training organisations & Scrum Alliance
  22. SCRUM ROLES Development Team development team can be comprised of all kinds of people including designers, writers, programmers, etc. responsibilities: ● Delivering the work through the sprint. ● To ensure transparency during the sprint they meet daily at the daily scrum Product Owner The business is represented by the product owner who tells the development what is important to deliver. responsibilities: ● Managing the scrum backlog ● Release management ● Stakeholder management gluing everything together and ensuring that scrum is being done well. responsibilities: ● Transparency ● Empiricism ● Self Organization ● Values Scrum Master
  23. SCRUM ARTIFACTS Product Backlog The product backlog is a list of new features, enhancements, bug fixes, tasks, or work requirements needed to build a product. It’s compiled from input sources like customer support, competitor analysis, market demands, and general business analysis. Sprint Backlog The sprint backlog is a set of product backlog tasks that have been promoted to be developed during the next product increment. Sprint backlogs are created by the development teams to plan deliverables for future increments and detail the work required to create the increment. Product Increment A product increment is the customer deliverables that were produced by completing product backlog tasks during a sprint. It also includes the increments of all previous sprints.
  24. SPRINT PLANNING ● Attendees: Development team, scrum master, product owner ● When: At the beginning of a sprint. ● Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour planning meeting. ● Purpose: Sprint planning sets up the entire team for success throughout the sprint. ○ Coming into the meeting, the product owner will have a prioritized product backlog. Use the sprint planning meeting to flesh out intimate details of the work that needs to get done. ○ Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint. SCRUM CEREMONIES DAILY SCRUM ● Attendees: Development team, scrum master, product owner ● When: Once per day, typically in the morning. ● Duration: No more than 15 minutes. ○ Don't book a conference room and conduct the stand up sitting down. ○ Standing up helps keep the meeting short! ● Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. ○ What did I complete yesterday? ○ What will I work on today? ○ Am I blocked by anything?
  25. SPRINT REVIEW ● Attendees: Development team, scrum master, product owner, Product Stakeholders (optional) ● When: At the end of a sprint or milestone. ● Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint. ● Purpose: Sprint review is a time to showcase the work of the team. ○ time for the team to celebrate their accomplishments ○ demonstrate work finished within the iteration ○ get immediate feedback from project stakeholders SCRUM CEREMONIES SPRINT RETRO ● Attendees: Development team, scrum master, product owner ● When: At the end of an iteration. ● Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint. ● Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn't.
  26. Epic & User Story Story Points Burn Down Velocity & Capacity DOR & DOD It is a short and clear description of feature, that will give user (minimal) real value. Story point is a tool for relative estimation. It estimates the effort to make a task done from 3 points: time, complexity and uncertainty. DOR or Definition of ready and DOD or Definition of Done are the checklists useful for understanding the work direction. a line chart drawn between remaining work and time. average & future team performance in story points SCRUM IMPORTANT CONCEPTS 🧑 🧑 📋 📈 🧑 🧑
  27. USER STORY EPIC have a lifespan of multiple sprints and cannot be considered complete until all stories based on them are also complete. As a: content-contributor I want to: categorize the content I create So I can: ensure that readers can easily locate it It is a short and clear description of feature, that will give user (minimal) real value. USER STORY most granular description of functionality. Stories describe deliverables that can be completed in a single sprint. As a: experienced-end-user I want to: Save my work using a command-key sequence So I can: Quickly save my work without multiple clicks SAGA
  28. STORY POINTS Measurement Typical be done in Fibonacci sequence 1, 2, 3, 5, 8 or in T- Shirt sizes S, M, L, XL Story point is a tool for relative estimation. It estimates the effort to make a task done from 3 points: time, complexity and uncertainty. Story points vs Mandays ● Relative Story Point estimates are quicker and easier to do. Estimating directly in man-days often leads us to get into too much detailed thinking. ● The team often cannot agree on them because they depend upon the speed with which people will do the work ● If the team changes the way that they are working (for example, perhaps they are going to start automating their testing) then if they have estimated in man-days, they will have to re-estimate every item
  29. Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. SCRUM POKER
  31. Backlog Refinement In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. Estimation is a common thing to happen here because the act of trying to estimate the story often brings out details about the story. Release Planning This is a planning that takes a high-level look at the next few months and I've worked with many teams that take a first-guess estimate at all stories in the release planning. It is understood in these teams that these estimates are rough guesses used for general planning purposes and they usually revisit the estimates in a Backlog Refinement closer to actually working the item. Sprint Planning It isn't common practice anymore to estimate right at sprint planning, but it still happens sometimes. Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit before deciding to bring it into the sprint. WHEN TO ASSIGN STORY POINT ?
  32. DoR Sample ● The conditions of satisfaction have been fully identified for the story. ● The story has been estimated and is under a certain size. For example, if the team is using story points, a team might pick a number of points and only allow stories of that size or smaller into the iteration. Often this maximum size is around half of the team’s velocity. ● The team’s user interface designer has mocked up, or even fully designed, any screens affected by the story. ● All external dependencies have been resolved, whether the dependency was on another team or on an outside vendor. Definition of ready a set of agreements that lets everyone know when something is ready to pick up, e.g., when a user story is ready to be taken into a sprint
  33. DoD Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. Sample ● Code is peer-reviewed ● Code is deployed to test environment ● Code/feature passes regression testing ● Code/feature passes smoke testing ● Code is documented ● Help documentation is updated ● Feature is OK’d by stakeholders
  34. Burndown BENEFIT ● provides an updated status report on the progress of the project ● visual representation of this most important data keeps everyone on the same page ● encourages the team to deal with issues before they become problems. ● relies on good estimates & discipline a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. TIPS ● If you notice that the team consistently finishes work early, this might be a sign that they aren't committing to enough work during sprint planning. ● If they consistently miss their forecast, this might be a sign that they've committed to too much work. ● If the burndown chart shows a sharp drop during the sprint, this might be a sign that work has not been estimated accurately, or broken down properly.
  36. 1. Epic menu: Select which epic to view data for. 2. Work added: The dark blue segment shows the amount of work added to the epic in each sprint. In this example, work is measured in story points. 3. Work remaining: The light blue segment shows the amount of work remaining in the epic. 4. Work completed: The green segment represents how much work is completed for the epic in each sprint. 5. Projected completion: The report projects how many sprints it will take to complete the epic, based on the team's velocity. EPIC BURNDOWN
  37. Velocity & Capacity Velocity is an average team performance in story points based on previous sprints statistics. Capacity is future team performance in story points based on the team’s availability — there may be an extra holiday next sprint or someone will go on vacation.
  39. KANBAN 101
  40. Visual Signals Columns Commitment Points Delivery Points WIP Limits visual cards (stickies, tickets, or otherwise). Kanban teams write all of their projects and work items onto cards, usually one per card. For agile teams, each card could encapsulate one user story. Each column represents a specific activity that together compose a “workflow”. Cards flow through the workflow until completion. Workflows can be as simple as “To Do,” “In Progress,” “Complete,” or much more complex. maximum number of cards that can be in one column at any given time. A column with a WIP limit of three cannot have more than three cards in it. The commitment point is the moment when an idea is picked up by the team and work starts on the project. Delivery point is when the product or service is in the hands of the customer. KANBAN 5 COMPONENTS
  41. KANBAN CARDS VIEW IMPORTANT DETAILS AT A GLANCE Each kanban card typically features a brief description of a work item, along with its owner, due date, and status. The card can include other information, like pointers to source documentation or a list of issues blocking the item's progress. kanban card represents a single work item as it moves through various stages of completion which are represented onkanban board. HAND OFF DELIVERABLES SMOOTHLY AND EFFICIENTLY Kanban cards encourage teams to establish clear and consistent expectations for each functional area. IMPROVE EFFICIENCY Kanban cards make it easy to keep track of lead time, which is the time it takes for a work item to go from start to finish. Kanban cards, together with a kanban board, can help teams identify bottlenecks in their workflow and streamline their process
  43. SCRUMBAN 101
  46. TOOLS
  47. THREE STAGES OF TEAM 🃏 Generalists 🧑 Platforms 🧑 Products
  49. THANK YOU Follow us on Instagram @lifeatmekari and LinkedIn “Mekari” for info on our next events and updated job vacancy (monthly) Visit our career page at to explore more opportunities with Mekari