CMSI 543 / SYEG 557: Welcome to Week 15

This Week's Class Agenda

• Announcements
• Software Engineering Institute on Agile
• Some interesting Videos
• Agile Metrics
• Discussion in Groups
• Back in Main Group Discussion
• Project Work Time

Software Engineering Institute on Agile

Here are some links from the SEI to their Agile documentation. Admittedly, these are quite old by today's standards, but when you think about that fact, also remember that the SEI is at the forefront of software engineering, so things that are old but still relevant will show up even today.

• Search Results for 'Agile'
• SEI Main Agile page [with video above]
• Links to publications
• Team Software Process – Brief Overview
• Case Study Paper: Distributed Multi-Company Software Project
• Deploying TSP on a National Scale paper

Video Links for Tonight's Discussion

1. Lean Software Development Process Overview[3:39]
2. Lean vs. Agile vs. Design Thinking[7:45]
3. Getting your Agile Project Started [from SEI][2:18]
4. Lean Principles in Graphic Format[2:52]
5. Toyota Invents Lean Manufacturing [Just-In-Time][4:51]
6. Lean-Six-Sigma in Eight Minutes[8:07]

NOTE: Total running time for all six videos is about 1/2 hour [29:32]

Agile Metrics

In chapter 4 of this whitepaper from the Software Engineering Institute [SEI] at Carnegie-Mellon, here is an interesting quote:

When the sponsor of a project gets a plan from the developer (whether they are an internal provider or an external contractor), they traditionally think of that as an exchange of risk. The plan is seen as a commitment to successfully build the product, and the developer – having planned the project – now assumes the risk. The sponsor mistakenly presumes that this commitment protects their interests. The reality is, if the project is late, or the product does not meet user expectations, the sponsor (not the developer) always owns the risk of market consequences (Interviewee #6).

The whitepaper posits that this explanation drives home the point [again!] that the most important part of measuring Agile product success is measuring the business value that the customer derives from the product. However, it is often very difficult to analyze and determine what is business value. As we've seen in other sessions, the term can have many different meanings depending on the viewpoint of who is defining it. However, one thing we haven't addressed yet is the idea that it may not be determinable until the software is actually deployed, and the customer starts making money with it [or not!]…

Here is another quote from the same article:

In general, Agile methods place a great deal of emphasis on delivering working software over other outcomes. For this reason, the proxies used as metrics in progress monitoring tend to relate more to the outputs of the work than the process used to complete the work. Metrics driven by story points, direct customer feedback, and products or defects as they flow through the development process (such as velocity, or customer satisfaction) are more common than metrics reflecting parameters of the process (such as schedule performance index, or estimate to complete).

Here are some thoughts from that same article [see above for link to article for citations]:

• Velocity: Simply stated, velocity is the volume of work accomplished in a specified period of time, by a given team [emphasis mine]. Typically, this is measured as story points accomplished per sprint. …Indeed most experts explain that velocity is team-unique and thinking of this measure as a parameter in an estimating model is a mistake.
• Velocity is a local measure, used by an individual development team to gauge the realism of commitments they make. The velocity metric is logically tied to the sprint burn-down chart.
  The point of monitoring velocity is not to promote on-going increases in productivity. Rather, the point is to assist the team in consistently operating with achievable commitments – and achieving those commitments. This mindset will aid the acquisition personnel in making beneficial use of this metric. The fundamental question to be answered by looking at velocity boils down to is the team meeting its commitments?
• Sprint Burn-Down Chart: Typically a line graph … showing a decline in the remaining backlog items to be completed, is used. … It is easy to relate this depiction to the completion of tasks remaining – or story points to be delivered – for the sprint. … Like metrics in traditional environments, Agile metrics provide a starting point for a discussion, rather than providing a final answer by themselves…
• Release Burn-Up Chart: A complementary graphical technique for the sprint burn-down, the release burn-up chart is also commonly used. Many cling to the convention that sprints burn down and releases burn up – though there is no mathematical principle that governs this choice.
• [show some of the graphs in other sections for information purposes]

Discussion For Tonight

Now that we've seen the videos, I'll put you into your breakout rooms so you can discuss what you feel is the most important, surprising, or noteworthy concept of the videos you saw. Here are some questions to get your discussion started. After 10 minutes or so, we'll return to the main zoom room to hear some of your answers.

• What is meant by Kaizen?
• What is meant by Just In Time?
• Do you agree that the truly Agile team will always stand by the principles? What if doing that makes your customer unhappy?
• What is meant by the term non-functional requirements?
• What is the answer to the quiz at the end of the Lean-Six-Sigma video?
  

     Which type of waste refers to the time and effort wasted due to
     unnecessary movement of people, equipment, or machinery?
  
        a. Inventory
        b. Waiting
        c. Overproduction
        d. Motion
                      

• Do you think in the planning session video which we saw a few weeks ago, that business people should have been allowed to vote during planning poker? Why or why not?
• Do you agree that the Agile philosophy should apply to the process as well as the product?