July 24, 2016
Subscribe on iTunes
Check out the podcast on Google Play Music
Software Process and Measurement Cast 404 features our interview with Ryan Ripley. We discussed The Business of Agile: Better, Faster, Cheaper at Agile. We discussed why having the answer for whether Agile is better, faster and cheaper is still important in the business world. Along the way we wrestled with the concept of value and why having value sooner is not the same as going fast.
Ryan Ripley has worked on agile teams for the past 10 years in development, scrum master, and management roles. He’s worked at various Fortune 500 companies in the medical device, wholesale, and financial services industries.
Ryan is great at taking tests and holds the PMI-ACP, PSM I, PSM II, PSE, PSPO I, PSD I, CSM and CSPO agile certifications.
Ryan lives in Indiana with his wife Kristin and their three children.
He blogs at ryanripley.com and hosts the Agile for Humans podcast.
You can also follow Ryan on twitter: @ryanripley
Re-Read Saturday News (more…)
July 23, 2016
This week we tackle teams in XP and why XP works based on the Theory of Constraints in Extreme Programing Explained, Second Edition (2005). The two chapters are linked by the idea that work is delivered most effectively when teams or organizations achieve a consistent flow. (more…)
July 21, 2016
On a scale of fist to five, I’m at a ten.
Quality is partly about the number defects delivered in a piece of software and partly about how the stakeholders and customers experience the software. Experience is typically measured as customer satisfaction. Customer satisfaction is a measure of how products and services supplied by a company meet or surpass customer expectations. Customer satisfaction is impacted by all three aspects of software quality: functional (what the software does), structural (whether the software meets standards) and process (how the code was built).
Surveys can be used to collect customer and team level data. Satisfaction is used to measure products, services, behaviors or work environment meet expectations.
- Asking: Asking the question, “are you happy (or some variant of the word happy) with the results of XYZ project?” is an assessment of satisfaction. The answer to that simple question will indicate whether the people you are asking are “happy”, or whether you need to ask more questions. Asking is a powerful tool and can be as simple as asking a single question to a team or group of customers or as complicated using multifactor surveys. Even though just asking whether someone is satisfied and then listening to the answer can provide powerful information, the size of projects or the complexity of software being delivered often dictate a more formal approach, which means that surveys are often used to collect satisfaction data. Product or customer satisfaction is typically measured after a release or on a periodic basis.
Fist to Five, a simple asking technique: Agile teams measure team level satisfaction using simple techniques such Fist-to-Five. Fist-to-five is a simple asking technique in which team members are asked to vote on how satisfied they are by flashing a number of fingers all at the same time. Showing five fingers means you are very satisfied and a fist (no fingers) is unsatisfied. This form of measurement can be used to assess team satisfaction on a daily basis. (A simple video explanation) I generally post an average score on the wall in the team room in order to track the team’s satisfaction trend.
- The Net Promoter metric is a more advanced form of a customer satisfaction measure than simple asking but less complicated than the multifactor indexes that are sometimes generated. Promoters are people who are so satisfied that they will actively spread knowledge to others. Generating the metric begins by asking “how likely you are to recommend the product or organization being measured to a friend or colleague?” I have seen many variants of the net promoter question but at the heart of it, the question is whether the respondent will recommend the service, product, team or organization. The response is scored using a scale from 1 – 10. Answers of 10 or 9 represent promoters, 7 or 8 are neutral and all other answers represent detractors. The score is calculated using the following formula: (# of Promoters — # of Detractors) / (Total Promoters + Neutral + Detractors) x 100. If ten people responded to a net promoter question and 5 where promoters, 3 neutral and 2 detractors the net promoter score is 30 (5 -2 /10 *100). Over time the goal is to improve the net promoter score which will increase the chance your work will be recommended.
Software quality is a nuanced concept that reflects many factors, some of which are functional, structural or process related. Satisfaction is a reflection of quality from a different perspective than measuring defects or code structure. The essence of customer satisfaction is the very simple question, are you happy with what we delivered? Knowing if the team, stakeholders, and customers are happy with what was delivered or the path that was taken to get to that delivery is often just as important as knowing the number of defects that were delivered.
July 19, 2016
Find the defects before delivery.
One of the strongest indications of the quality of a piece of software is the number of defects found when it is used. In software, defects are generated by a flaw that causes the code to fail to perform as required. Even in organizations that don’t spend the time and effort to collect information on defects before the software is delivered collect information on defects that crop up after delivery. Four classic defect measures are used “post” delivery. Each of the four measures is used to improve the functional, structural and process aspects the software delivery process. They are:
July 17, 2016
Subscribe on iTunes
Check out the podcast on Google Play Music
The Software Process and Measurement Cast 403 features our essay on Agile practices at Scale. Scaling Agile is a contentious topic. Frameworks and techniques for scaling are often lambasted as semi-Agile or perhaps even backdoor waterfall techniques. Occasionally you still hear that if a piece of work is too big for one team to complete in a reasonable period of time it should be broken down or just not done. Rather than throw the baby out with the bathwater, many organizations have taken a more pragmatic approach and adopted techniques to scale Agile. We discuss the issues and some of the steps that can be taken to address them!
We will also have a visit from the Software Sensei, Kim Pries. Kim discusses making real transformations using his experience learning Tai Chi. Kim points out that change like deep learning is not instantaneous.
Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. We discussed his article titled, NPM, Tay, and the Need for Design. Gene points out that being forewarned is forearmed. While it has always been true, in today’s dynamic environment, an architect needs to be forearmed.
Re-Read Saturday News
This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 8 and 9. Chapter 8 changes gears and provides advice on how to get started with XP. Beck suggests that there is no single place to start for everyone. Where you start depends on where you are beginning. Chapter 9 provides a list of corollary practices that build on the primary practices discussed in Chapter 7.
Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.
Next SPaMCAST (more…)
July 16, 2016
This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters seven and eight in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapter 8 changes gears and provides advice on how to get started with XP. Beck suggests that there is no single place to start for everyone. Where you start depends on where you are beginning. Chapter 9 provides a list of corollary practices that build on the primary practices discussed in Chapter 7. (more…)
July 14, 2016
It is all about the bugs!
Many common measures of software quality include defects. A collection of defects and information about defects can be a rich source of information to assess or improve the functional, structural and process aspects the software delivery process. Because of the apparent ease of defect collection and management (apparent because it really is never that easy) and the amount information that can glean from defect data, the number of defect related measures and metrics found in organizations is wide and varied. Unfortunately, many defect measures are often used incorrectly or are expected to be predictive.
Defect measures that are useful while work is process (or pretty close) include: (more…)