DOMAIN 2 VALUE-DRIVEN DELIVERY

DOMAIN 2 VALUE-DRIVEN DELIVERY

Frequently Asked Questions (FAQ)

Carilah jawaban sesuai pertanyaan dari sumber-sumber yang telah diinformasikan

Kumpulkan tugas yang sudah selesai selambat-lambatnya 1 jam sebelum Sesi study group dimulai.

1. Sebutkan dan jelaskan kontrak dalam Agile

Agile Contracting

Vendors are stakeholders who are external to the organization but are involved in the project because they are providing some kind of product or service. Agile teams should be careful in selecting vendors and make sure they are prepared for working in an agile environment. If a vendor needs to use an agile approach to participate in the project, then this requirement should be outlined in the request for proposal (RFP).

Depending on their role in the project, however, some vendors may not need to use or understand agile practices. Before setting a requirement that all the vendors be familiar with agile, or developing an educational event for vendors, ask if it’s worth it. For vendors who will play a minor role in the project, perhaps it isn’t. But for vendors who will play a major or critical role, it will be important to educate them about agile. Like all decisions, in educating our vendors we need to consider the cost-benefit trade-off.

Since agile teams know that the requirements may change and the scope is negotiable, traditional vendor contracts based on formal specifications are problematic. Instead, agile projects typically use contracting models designed for an agile environment, such as the fixed-price work packages and graduated fixed price contracts described below.

ACP MCG Page 124

2. Jelaskan mengenai prinsip-prinsip akunting pada proyek Agile

Agile "accounting" refers to how the economic models of agile projects work. We will be covering the differences between agile and traditional life cycles from various perspectives, in relation to planning, estimating, delivering value, and so on—and these differences also have implications for project accounting. 

Prioritizingworkbybusiness value and delivering the highest-value components first can radically change the payback period and return on investment for a project. As we’ll see, agile teams aim to deliver a minimal viable product (MVP) as quickly as possible. So there may be opportunities to get early benefits by making use of some of the product functionality while the remainder of the project is still being executed.

Page 97

3. Jelaskan mengenai konsep manajemen risiko pada Agile

To maximize value, agile teams need to consider risks and technical dependencies. A choice that could lead to future problems or rework probably won’t deliver the most value to the customer, even if it gives the illusion of early progress. Therefore, we need to consider risks and nonfunctional requirements and let the customer know how those elements will impact the project.

In fact, the concept of risk is closely related to value, so much so that we can think of negative project risks (threats) as anti-value—factors that have the potential to erode, remove, or reduce value if they occur. If the value is the “heads” side of the coin, then the risk is the “tails” side. To maximize value, we must also minimize risk, since risks can reduce value. This is why the value-driven delivery domain also encompasses the concept of risk reduction.

Page 98.

4. Jelaskan mengenai Agile tooling

Just as the agile manifesto values “Individuals andinteractions overprocesses and tools,” agile teams prefer low-tech,high-touch tools over sophisticated computerized models. It might seem ironic that the agile approach, so closely associated with software development, wouldn't take full advantage of the latest digital gizmos. However, high-tech tools actually present some disadvantages for agile teams. Although scheduling software can illustrate deep hierarchies of tasks, support task dependency integrity checks, and calculate interesting metrics such as slack, subassembly costs, and resource utilization, this technical

Sophistication isn’t ideal for agile methods. The highly polished graphs, statistics, and quantitative reports that these tools can produce tend to disguise the volatile nature of what's being analyzed—project tasks and estimates. Sophisticated scheduling tools can also exclude team members from interacting with the tools and discourage whole-team collaboration.

• Data accuracy perception increases

• Barriers to stakeholder interaction are created

 Contoh implementasi nya: Low-Tech, High-Touch Tools

Page 111.

5. Bagaimana konsep Compliance / regulatory compliance

Regulations are typically designed to ensure safety; so while the mandated documentation and quality procedures may seem to burdensome to the project team, they serve an important purpose. Personally, I have worked on military projects, food and drug projects, and energy transmission projects that have had regulatory compliance requirements. Usually, these requirements are non-negotiable—choosing to ignore, skip, or skimp on compliance isn’t an option since it would simply prevent the organization from being paid and the product being accepted and used.

There are two simple approaches for incorporating regulatory compliance work into agile projects. The first is to weave it into the regular development work as the team progresses. The second is to allow time after creating the product to undertake the regulatory work and produce the required evidence and documentation. There are pros and cons to each approach:

» Doing the compliance work “as you go” keeps it linked and relevant to the current work. We can see if our work practices are making it easier or harder to pass the compliance tests and adapt accordingly. However, the downside of this approach is that any subsequent changes to a product or its design may invalidate the work we have done before. In other words, the testing that has been done to date might need to be repeated.

» Doing the compliance work after product development doesn’t allow us to tweak our practices on the go, but it does avoid the issue of rework. And assuming that the product passes, it can be sent for final approval, complete with its newly minted compliance documentation.

Most organizations adopt a hybrid approach; they will select a few architecturally significant components to test compliance on as they develop and refine their process until they are comfortable that technology will satisfy the regulatory requirements. Then, once all the work is done, they will submit the entire product to final compliance testing and documentation again. This creates a duplication of effort in testing the components they did before,but it is the best way to balance and manage the risks of sub-optimal processes and overall rework.

Most organizations adopt a hybrid approach; they will select a few architecturally significant components to test compliance on as they develop and refine their process until they are comfortable that technology will satisfy the regulatory requirements. Then, once all the work is done, they will submit the entire product to final compliance testing and documentation again. This creates a duplication of effort in testing the components they did before, but it is the best way to balance and manage the risks of sub-optimal processes and overall rework.

page 100

6. Jelaskan mengenai konsep Cumulative flow diagram (CFD)

Cumulative flow diagrams (CFDs) are valuable tools for tracking and forecasting the delivery of value. They can help us gain insight into project issues, cycle times, and likely completion dates. Basically, CFDs are stacked area graphs that depict the features that are in progress, remaining, and completed over time. Here’s an example of a CFD:

Page 118

7. Jelaskan mengenai konsep Customer-valued prioritization

Customer-valued prioritization refers to the agile practice of working on the items that yield the highest value to the customer first The customer or product owner is responsible for keeping the items in the backlog (the list of work that needs to be done)prioritized by business value. As new work items are added, such as change requests and defect fixes, the customer prioritizes them so that their value can be compared to the existing items on the list.When the team is ready to plan a new iteration, they start working on the items at the top of the backlog, to make sure they are working on the highest-value items.

Page 101

8. Jelaskan mengenai konsep Earned value management (EVM) for agile projects

EVM tetap bisa digunakan untuk agile project.

Earned value compares actual project performance to planned performance at a particular point in time. So the quality of the baseline plan is a critical success factor in using this approach.

On agile projects, we know that our initial plan will need to change, so the basis for effective EVMis quickly eroded as our plans evolve.

Page 93

9. Jelaskan mengenai konsep Frequent verification and validation

Agile techniques are designed to resolve problems as soon as possible before they can grow bigger and move up the cost of the change curve. Like the old saying, “A stitch in time saves nine,” agile uses regular testing, checkpoints, and reviews to address problems before they get bigger. This practice is referred to as frequent verification and validation.

Frequent verification and validation are practiced at many levels on agile projects.It is an effective antidote To both the fact that making mistakes is part of being human and the mismatch of expectations that arise when the team interprets the customer’s end goal differently than intended. With frequent verification and validation, we are checking to make sure things are working and progressing as they should, as well as looking for any mismatches in expectations. In doing so, we enable the project to rapidly converge on The real solution, even while that solution evolves from the originally stated requirements.

Page 129.

10. Apa yang dimaksud dengan Incremental delivery

Nearly all Agile teams favor an incremental delivery strategy. In an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality.

Page 324

11. Bagaimana konsep Managing with agile KPIs

Managing KPI di agile hampir sama dengan di traditional project, untuk mengetahui sejauh mana project diselesaikan dan berapa banyak cost / budget yang dikeluarkannya.

Beberapa metrics yang menjadi tolak ukur KPI di agile diantaranya:

• Rate of progress

• Remaining work

• Likely completion date

• Likely costs remaining

12. Jelaskan mengenai konsep Minimal viable product (MVP), Minimal Marketable Feature (MMF)

MVP:

“The Minimal Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

In other words, the MVP is about validated learning using the least amount of time and money. It is about answering the question: Are we building the right thing? It is targeted at early adopters or a subset of customers with the main goal of obtaining feedback on the potential viability of the product hypothesis. The MVP might not be a product at all. It can be a simple prototype as long as it helps acquire the relevant knowledge or raises key risks.

An example of an MVP is ad campaigns to products that do not exist yet. The campaigns simply directs potential customers to landing pages with info about the product. Metrics track interest of potential customers in the product and which features are receiving the most attention. These metrics help validate the hypothesis around certain features.

So the MVP helps a team discover the potential MMF to build.

MMF:

“The Minimum Marketable Feature is the smallest unit of functionality with intrinsic market value.”

In other words, the MMF is a real feature that provides tangible value to customers. It addresses a specific need, solves a certain problem, and is of high quality and usability. It is a feature that can be marketed, sold and shipped.

An example of MMF is releasing an initial product with core features and then incrementally releasing additional features along the way as opposed to building a massive product with tons of features all at once only to later discover that over 60% of features built are never or rarely used. So the MMF is all about focusing on high-value features, reducing time to market and launching products faster to increase ROI.

In a future post, we will see how we use Lean Discovery techniques to validate the MVP and how we use Agile Delivery practices to build out MMF.

Page 108.

13. Jelaskan mengenai skema prioritas : Analisis Kano, MoSCoW

Diagram kano adalah sebuah diagram yang membagi spesifikasi dari pelanggan menjadi tiga jenis, harus ada (must be), Kemampuan (Performance) dan pemuas (delighter), dan membandingkan dengan tingkat keberadaan suatu spesifikasi.

Moscow: Adalah teknik memprioritaskan pekerjaan. Diantaranya : 

• Must Have, 

• Should have, 

• Could have, dan 

• Wont have.

14. Jelaskan terkait prioritas/peringkat relatif

Regardless of the prioritization scheme that the team uses, their focus should be on the end goal of understanding the priority of features. Sometimes the effort involved in refereeing the schemes can detract from meaningful discussions about prioritization. For this reason, I am personally a fan of simply asking the customer to list features in order of relative priority—no category 1, 2, or 3; no high, medium, or low; No must-haves, etc. A simple list removes the categories that people tend to fixate on from the debate and allows the focus of the discussion to be on priorities.

15. Jelaskan mengenai ROI/NPV/IRR

​​Return on invesment (ROI) adalah rasio yang menunjukkan hasil dari jumlah aktiva yang digunakan dalam perusahaan atau suatu ukuran tentang efisiensi manajemen. Rasio ini menunjukkan hasil dari seluruh aktiva yang dikendalikan dengan mengabaikan sumber pendanaan, rasio ini biasanya diukur dengan persentase.

Net Present Value atau NPV adalah selisih antara nilai arus kas yang masuk dengan nilai arus kas keluar pada sebuah periode waktu. Menurut ilmu ekonomi, Net Present Value adalah perkiraan arus kas masa mendatang yang dikurangi diskon saat ini menggunakan social opportunity cost of capital.

Rate of return (IRR) adalah penghitungan yang dilakukan guna mengestimasi nilai potensial investasi. IRR juga disebut sebagai tingkat return tahunan yang diharapkan dari investasi.

16. Jelaskan mengenai praktik pengembangan perangkat lunak berikut ini: Continuous integration, Exploratory and usability testing, Red Green Refactor, TDD/TFD/ATDD

CI

Continuous Integration atau integrasi berkelanjutan adalah salah satu praktik dari DevOps di mana kita sebagai developer bisa mengintegrasikan kode ke dalam repositori kode seperti GitHub dan menjalankan pengujian secara cepat dan otomatis.

Exploratory and usability testing

Exploratory Testing: Testing a product without any formal requirement documentation or understanding of the product. There will be some scenarios where the tester will not receive any requirement document or any supporting document to understand the product in that scenario tester will explore the application keeping the testing objective in mind and will try to find the bugs.

Usability Testing: In this testing, the tester will check that how ease is the use of applications like navigation, proper placement of GUI elements, text color, and background color combinations are readable and other things like this.

Red Green Refactor

The red, green, refactor approach helps developers compartmentalize their focus into three phases:

Red — think about what you want to develop

Green — think about how to make your tests pass

Refactor — think about how to improve your existing implementation

TDD/TFD/ATDD

Test-driven development (TDD) adalah proses pengembangan perangkat lunak yang bergantung pada pengulangan siklus pengembangan yang sangat singkat.

Test-first development (TFD) is an approach to development in which developers do not write a single line of code until they have created the test cases needed to prove that unit of work solves the business problem and is technically correct at a unit-test level

Acceptance Test-Driven Development atau Tes ATDD adalah sebuah test ditulis dari perspektif pengguna. Sifatnya mirip dengan BDD, namun ATDD berfokus pada kode yang memenuhi persyaratan perangkat lunak. Seperti BDD, tes ditulis dalam bahasa Inggris standar tetapi fokus pada penerimaan penulisan - yaitu ATDD mengubah BDD menjadi spesifikasi yang dapat dieksekusi (ini adalah tes), dan spesifikasi itu bahkan dapat diotomatiskan.

Karena sifat ATDD, formulasinya membutuhkan kolaborasi antara pengembang, pengguna, pemilik produk, dan penguji.

• Komunikasi di seluruh tim adalah hal yang baik

• Tes penerimaan berfungsi sebagai pengingat titik akhir yang perlu dicapai perangkat lunak

• Otomatisasi ATDD dapat mengurangi waktu umpan balik

17. Jelaskan mengenai Task/Kanban Boards

.“Task board” is the generic agile term for “Kanban board,” 

These boards originatedintheKanban methodology, where they are the primary tool for planning and Monitoring the progress of the work. While there may be variations, a task or Kanban board is generally a whiteboard with columns that show the various stages of work. The tasks that are being worked on are Represented by sticky notes that team members move through the columns to show their progress.

page.113

18. Jelaskan mengenai konsep dari Value Driven Delivery

What is value?

We need to define what a value is before dwelling into how to go about value driven delivery in the agile software development. The value could be defined in terms of monetary benefit, compliance adherence, an answer to the competition in the market etc. The term value can differ for each client based on what the client is expecting the product/software to accomplish. The end product of a project is a value to the customer.

In the agile way of project management, always the requirements are prioritized based on what adds more value to customer delivery. For projects with monetary benefits, value is commonly calculated using methods such as return on investment (ROI), internal rate of return (IRR), and net present value (NPV).

How do you deliver value to the customer?

The value-driven delivery is a combination of value adding and risk reducing activities. The value-driven delivery can be achieved by following some best practices as below:

• Identity value, a monetary value, competitive value etc.

• Prioritize the requirements so that high value is delivered to the customer fast.

• Deliver the value to the customer iteratively so that the return on investment (ROI) is rapid.

• Receive the feedback and work on things which need improvement, which can provide more value to the customer

• Collaboration with all the stake holders is the key in identifying what adds more value to the overall project, to the client and to the whole process.

• Review of what is being delivered in each iteration. The project requirements, the environment around it keep changing. We need to have an eye on what is changing, re-look at priorities, and re-order them.

• Identify risks and have a plan to reduce them in the course of the development. Risks are anti-value and they have the potential to reduce the value delivered to the customer.

• Whenever there is a new requirement, it has to be compared with the whole priority list so that we don’t divert in our objective of providing highest value to the customer. If the new requirement adds more value to the deliverable then that should move to priority list.

• We need to see what are the Minimum Marketable Features (MMFs) that should be there in the early releases to potentially increase the value delivered to the customer.

• Experiment early so that we fail fast and rethink on our approach very early in the development stage.

• The feedback of each value prioritized can be tracked through prototyping, simulation, providing demonstration etc.

When not to have plan driven delivery?

The value-driven delivery beats the plan drive delivery in many ways:

• Plan driven delivery thrives on planning and estimation which cannot be done early when the nature of the project is complex. In agile world, as the releases are in iterations, elaborate planning is not required.

• Requirements keep changing and planning early would lead to lot of re-work. Value driven delivery decides what adds more value to customer with a given set of requirements and implements the same. If there is a change request that adds more value to client, then the change request can be easily accommodated in this agile way.

19. Apa yang dimaksud dengan Work In Progress (WIP, WIP limits)

The acronym WIP stands for Work In Progress. WIP is the number of task items that a team is currently working on. It frames the capacity of your team's workflow at any moment.

WIP limits as we called for Limiting work in progress is one of the core properties of Kanban. It allows you to manage your process in a way that creates a smooth workflow and prevents overloads.

Work in progress (WIP) limits restrict the maximum number of work items in the workflow's different stages (kanban board columns). They can be defined per person, per work stages/type, or for the entire work system. Implementing WIP limits allows you to complete single work items faster by ensuring your team focuses on finishing current tasks before starting new ones. 

Most importantly, by applying WIP limits, your team has the opportunity of locating bottlenecks in their working processes before they become blockers.

WIP limits are considered an important prerequisite for delivering value to customers as fast as possible. This makes them a valuable asset in the Kanban method.