Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/5&page=2' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

What Are Story Points?

Mike Cohn's Blog - Tue, 08/23/2016 - 15:00

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

  • The amount of work to do
  • The complexity of the work
  • Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

The Amount of Work to Do

Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.

The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.

The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.

If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.

If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.

Complexity

Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.

Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.

This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.

Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.

This additional complexity should be reflected in the estimate provided.

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.

Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.

Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.

All three factors must be combined.

Consider Everything in the Definition of Done

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

SPaMCAST 408 ‚Äď Kupe Kupersmith, Business Analysis and Agile

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 408 features our interview with Kupe Kupersmith. Kupe and I discussed the role of the business analyst in today’s dynamic environment.  It is critical to defining and facilitating the delivery of value. Weighty topics, but we also had a bit of fun.

‚ÄúKupe‚ÄĚ Kupersmith, President, B2T Training, possesses over 18 years of experience in software systems development. He has served as the lead Business Analyst and Project Manager on projects in the energy, television and sports management and marketing industries. Additionally, he serves as a mentor for business analysis professionals. Kupe is the co-author of Business Analysis for Dummies, a Certified Business Analysis Professional (CBAP¬ģ) and a former IIBA¬ģ Board Member.

Kupe is a requested speaker and has presented at many conferences around the world. Being a trained improvisational comedian, Kupe is sure to make you laugh while you’re learning. For a feel for Kupe’s view on business analysis topics check out his blog on BA Times. Kupe is a connector and has a goal in life to meet everyone!

Contact Information

https://www.linkedin.com/in/kupetheba

https://www.b2ttraining.com/

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 18 and 19.   Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

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, we are going to read The Five Dysfunctions of a Team by Jossey-Bass.  This will be a new book for me, therefore, an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

Next SPaMCAST

In the next Software Process and Measurement Cast, we will feature essay on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

We will also have columns from Jeremy Berriault‚Äôs QA Corner and Jon M. Quigley‚Äô column, ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 408 - Kupe Kupersmith, Business Analysis and Agile

Software Process and Measurement Cast - Sun, 08/21/2016 - 22:00

The Software Process and Measurement Cast 408 features our interview with Kupe Kupersmith. Kupe and I discussed the role of the business analyst in today’s dynamic environment.  It is critical to defining and facilitating the delivery of value. Weighty topics, but we also had a bit of fun.

‚ÄúKupe‚ÄĚ Kupersmith, President, B2T Training, possesses over 18 years of experience in software systems development. He has served as the lead Business Analyst and Project Manager on projects in the energy, television and sports management and marketing industries. Additionally, he serves as a mentor for business analysis professionals. Kupe is the co-author of Business Analysis for Dummies, a Certified Business Analysis Professional (CBAP¬ģ) and a former IIBA¬ģ Board Member.

Kupe is a requested speaker and has presented at many conferences around the world. Being a trained improvisational comedian, Kupe is sure to make you laugh while you’re learning. For a feel for Kupe’s view on business analysis topics check out his blog on BA Times. Kupe is a connector and has a goal in life to meet everyone!

Contact Information

https://www.linkedin.com/in/kupetheba

https://www.b2ttraining.com/

 

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 18 and 19.   Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

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, we are going to read The Five Dysfunctions of a Team by Jossey-Bass.  This will be a new book for me, therefore, an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

 

Next SPaMCAST

In the next Software Process and Measurement Cast, we will feature essay on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

We will also have columns from Jeremy Berriault‚Äôs QA Corner and Jon M. Quigley‚Äô column, ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Extreme Programming Explained, Second Edition: Re-Read Week 9 (Chapters 18 ‚Äď 19)

XP Explained Cover

This week we continue with the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) with two more chapters in Section Two.  Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

Chapter 18: Taylorism and Software

Somewhere in the dark ages when I was a senior in high school, I worked for Firestone Tire and Rubber. During my stint as a tire sorter and mold cleaner the time and motion people terrorized me and almost everyone at the plant. ¬†They lurked behind the machines with clipboards and stopwatches to ensure all workers were following ‚Äėthe right way‚Äô to do work. Cut to approximately four years later when I was a senior at Louisiana State University, I took several courses in industrial engineering. ¬†Between both sets of experiences, I learned a lot about industrial engineering, scientific management, and Taylorism. Some of what I learned made sense for highly structured manufacturing plants, but very little makes sense for organizations writing and delivering software (although many people still try to apply these concepts).

Frederick Taylor led the efficiency movement of the 1890’s, culminating in his book The Principles of Scientific Management (1911). Scientific management suggests that there is ‚Äėone best way‚Äô that can be identified and measured to do any piece of work (hence the stopwatches). Scientific management continues to be used by many organizations from manufacturing to hospitals (at least according to my sister-in-law who is a nurse). It is hard to resist something named scientific management, even though scientific management tends to clash with the less regimented concepts found in the Agile and lean frameworks used in knowledge work.

Side Note: Beck points out the brilliance in naming “scientific management,” who would be in favor of the opposite, “unscientific management”? (The book notes that when picking descriptive names, it helps to pick a name whose opposite is unappealing, for example, the Patriot Act.)

Why the clash? ¬†Scientific management was born in a manufacturing environment not software development environment. Taylor was focused on getting the most out workers that he felt had to lead and controlled closely. ¬†In Taylor’s world, making steel or assembling cars were repeatable and predictable processes and the workers were cogs in the machine. Time and motion studies, which are a common tool in scientific management, run into problems based on several simplifying assumptions when applied to many types of work, including software development. ¬†Beck points out three critical assumptions made by Taylor.

  1.   Things usually go according to plan as work moves through a repeatable process.
  2.   Improving individual steps leads optimization of the overall process.
  3.   People are mostly interchangeable and need to be told what to do.

Take a few minutes while you consider the simplifying assumptions as they are applied to writing, testing and delivering functionality, and then stop laughing.

While very few enlightened CIOs would admit to being adherents of Taylor, many would describe their “shop” as a software factory and actively leverage at least some of the tenets of scientific management. ¬†The practice of social engineering developed by Taylor and his followers is built into the role specialization model of IT that is nearly ubiquitous. One form of social engineering practiced on the factory floor even today is the separation of workers from planners, which translates into software development as separating estimators and project managers from developers and testers in today’s IT organization. The planners and estimators decide how and how long the workers will take to deliver and a piece of work. Developers are considered the 21st-century cogs in the machine that work at the pace specified by the planners and estimators. ¬†Every software development framework decries this practice and yet it still exists. ¬†Similarly, Beck points out that creating a separate quality department is another form of social engineering. ¬†The separation of the quality function ensures the workers are working to the correct quality by checking at specific points in the process flow. ¬†In every case, separating activities generates bottlenecks and constraints, and potentially makes each group the enemy of each other. Once upon a time I heard a group of developers mention that they had completed development, but the testers caused the project to be late. ¬†This is a reflection of Taylorism and social engineering.

Chapter 19: Toyota

The Toyota Production System (TPS) is an alternative to Taylorism.  Much has been written about TPS, including several books by Tom and Mary Poppendiech that pioneered applying TPS to software development and maintenance. In TPS, each worker is responsible for the whole production line rather than a single function. One of the goals of each step in the process is to make the quality of the production line high enough that downstream quality assurance is not needed.

In the TPS there is less social stratification and less need to perform independent checking. Less independent checking is needed becasue workers feel accountable for their work because it will immediately used by the next step process. In software development, a developer writes code and tests code that forms the basis for the future stories. A developer in an organization using the TPS can’t hide if they deliver poor quality and will be subject to peer pressure clean up their act and deliver good quality.

Beck caps the chapter with a reminder of the time value of money.  Making anything and then not using it immediately so that you generate feedback causes the informational value to evaporate. Quick feedback is one of the reasons why short iterations and quick feedback generates more value than classic waterfall.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 ‚Äď 13

Week 8, Chapters 14 ‚Äď 15

Week 9, Chapters 16 ‚Äď 17

A few quick notes. We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

 

 


Categories: Process Management

Two Teams or Not: Courage and Flexibility

You got to have courage!

You got to have courage!

I listen to Malcolm Gladwell‚Äôs wonderful Revisionist History podcast. In the last podcast of season one, he discussed ‚Äúthe satire paradox.‚ÄĚ The punchline of the most recent installment of the podcast is that change is not possible without courage. Flexibility requires courage. ¬†Change, when embracing something like Agile, requires the flexibility to give something up. ¬†Perhaps we might be asked to move outside of our comfort zone and work differently, or to work with people we haven‚Äôt worked with before. ¬†Asking testers and developers to work on the same team or to work as pairs or asking backend and UI subteams to work together require¬†flexibility. ¬†We can define flexibility to embrace Agile or any other significant modification to work based on four basic attributes:

  1. Ability to accept changing priorities РAgile projects are based on a backlog that encompasses the prioritized list of work for team(s).  This backlog will evolve based on knowledge and feedback. The evolution of the backlog includes changes to the items on the list and the priority of the items on the list. All team members, whether a developer, business analyst or tester, need to accept that what we planned on doing in the next sprint might not be what we originally thought.  
  2. Ability to accept changing roles and workload РSelf-directed and self-managed teams make decisions that affect who does what and when.  Each team member needs to accept that they might be asked (or need to volunteer) to do whatever is needed for the team to be successful.  Adopting concepts such as specializing generalists or T-shaped people are a direct reflection of the need for flexibility.
  3. Ability to adapt to changing environments – Business and technical architectures change over time. Architectures are a reflection of how someone (a team or an architect) perceives the environment at a specific moment in time. Implementing the adage that developers should ‚Äúrun towards feedback‚ÄĚ requires courage and flexibility.
  4. Ability to persist РAny process change requires doing something different, which is often scary or uncomfortable even if it is only briefly. If we give up immediately at the first sign of unease nothing would ever change, even if the data says that staying the course will be good.  For example, the first day at all six universities that I attended was full of stress (I remember once even having the dream that I could not find my classes). I was able to find the courage to persist and push through that unease in order to make the change and find a seat in the back of room in each class.

When I was asked whether two teams were really one team or whether they should find a way to work together, the answers have been premised on the assumption that they had the courage or the flexibility to change. The discussion of courage and flexibility is really less about Agile techniques, but rather a change management issue. A test of whether courage and flexibility are basic issues can be as simple as listening to team members comments. ¬†If you hear comments such as ‚Äúwe have always done it that way‚ÄĚ or ‚Äúwhy can’t we do it the way we used to?‚ÄĚ, then leaders and influencers need to assess whether a team or individual has the courage and flexibility to change. ¬†If they do not have the flexibility and courage needed, leaders and coaches need to help develop the environment where courage and flexibility can develop before any specific process framework or technique can be successful.

Changing how people work is difficult because most people only choose to change if they see a greater benefit/ pain avoidance than the pain of not making the change. Flexibility is a set of abilities help individuals and teams to make a choice and then establishing a commitment to that choice so that change happens.


Categories: Process Management

Software Development Linkopedia August 2016

From the Editor of Methods & Tools - Wed, 08/17/2016 - 15:25
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about team management, the (new) software crisis, saying no, software testing, user experience, data modeling, Scrum retrospectives, java microservices, Selenium tests and product backlog refinement. Blog: The Principles of Quantum Team […]

Two Teams or Not: First Do No Harm (Part 2)

A pile of empty pizza boxes!

WIP limits are needed to stop waiting in queues.

Recently a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together. In a previous entry we began describing how kanban or Scrumban could be leveraged to help teams identify issues with how they work and then to fix them.  We conclude with the last two steps in a simple approach to leveraging kanban or Scrumban:

  1. ¬†¬†Establish beginning WIP limits for each task. Work in Process (WIP) limits indicate how many items any specific task should control at a time (being worked on or waiting in queue). An easy approach to determining an initial WIP limit for a task is to count the number of people whose primary responsibility is to perform that task (Joe is a primarily a coder ‚Äď count 1 coder) under the assumption that a person can only do one thing at time (good assumption), and then use the count of people as the WIP limit. Roles that are spread across multiple people are a tad messier, but start by summing the fraction of time each person that does the role typically spends in that function (round to the nearest whole person for the WIP limit). ¬†The initial WIP limit is merely a starting point and should be tuned as constraints and bottlenecks are observed (see the next step).

As the team is determining the WIP limits, think about whether there are tasks that only one person can perform that are necessary for a story to get to production. These steps are potential bottlenecks or constraints.  When developing the WIP limits identify alternates that can perform tasks (remember T-shaped people!).  If members of a silo can participate only in their own silo it will be difficult for them to help fellow team members outside their silo, which can be harmful to team morale.  This type of issue suggests a need for cross training (or pair-programming or mob programming) to begin knowledge transfer.  

  1. ¬†¬†Pull stories from the backlog and get to work! Pull highest priority stories into the first task or tasks (if you have multiple independent workflows you will have multiple entry points into the flow). ¬†When a story is complete it should be pulled into the next task, if that task has not reached its WIP limit. ¬†¬†If a task can’t be pulled into the next step, it will have to wait. ¬†When stories have to wait, there is a bottleneck and a learning opportunity for the team.

As soon as stories begin to queue up waiting to get to the next step in the flow, hold an ad-hoc retrospective.  Ask the team to determine why there is a bottleneck. One problem might be that the WIP limit of the previous task is too high.  Ask them how to solve the problem.  If they need help getting started ask if the queue of stories is due to a temporary problem (for example, Joe is out due to the flu) and then ask if there is more capacity to tide things over.  If the reason is not temporary (for example, only a single person can do a specific task, or stories are too large and tend to get stuck) ask the team to identify a solution that can be implemented and tested.  The goal is to have the team identify the solution rather than have the solution imposed on them from someone else (think buy-in).

Using kanban or Scrumban to identify and generate solutions to how teams work facilitates the development of good teams. Good Agile teams exhibit three attributes:

  • Bounded – Team members belong to the team and the relationships that they develop will be ‚Äústicky.‚ÄĚ
  • Cross-functional – Cross-functional teams spend less time negotiating hand-offs and tracking down who can or should do any piece of work, thereby reducing the potential for bottlenecks.
  • Self-organized and self-managed – Self-organized and self-managed teams don‚Äôt need to wait for permission to make the decisions needed to remove bottlenecks or process constraints.

Overlaying kanban or Scrumban on top of the team’s current process does not change anything. . . .to start with. But it does position the team to take action when they SEE a problem. ¬†Visualization of how work is flowing will show the team where bottlenecks occur. The scrum master or coach then needs to challenge the team to eliminate those bottlenecks, promoting the health of the team in the process.

 


Categories: Process Management

The Legend of the 5 Monkeys, the Doctor and the Rose

Xebia Blog - Mon, 08/15/2016 - 17:16
As Product Managers people look up to us to carry the vision, to make sure all the noses are aligned, the troops are rallied and that sort of stuff. But what is it that influences behavior? And what makes your team do what they do? The answer has more to do with you than with

SPaMCAST 407 ‚Äď Magazine with Cagley, Hughson, Pries, and Tendon

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 407 includes four separate columns.  We begin with a short essay refreshing the pros and cons of Test Driven Development. Test Driven Development promises a lot of benefits but all is not light, kittens and puppies. Still, TDD is well worth doing if you go into it with your eyes open.

Our second column features Kim Pries, the Software Sensei. ¬†Kim discusses what makes software ‚Äúgood.‚ÄĚ The Software Sensei puts the ‚Äúgood‚ÄĚ in quotes because it is actually a difficult word to define but Kim is willing to give the discussion a go!

In our third column, we return to Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 10 which is titled The Thinking Processes. Thinking processes are key to effectively using  Agile, lean and kanban processes.  

Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. ¬†In this installment, we discuss the blog entry titled ‚ÄúLearning to Deal with the Inevitable.‚ÄĚ ¬†Gene and I discussed change which is inevitable and innovation which is not quite as inevitable.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 16 and 17.   Chapter 16 ends Section One with an interview with Brad Jensen.  Section Two addresses the philosophies of XP.  Chapter 17 tells the creation story of XP from Beck’s point of view.

We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

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

In the next Software Process and Measurement Cast, we will feature our interview with Kupe Kupersmith. Kupe brings his refreshing take on the role of the business analyst in today’s dynamic environment.  This interview was informative, provocative and entertaining.     

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 407 - Magazine with Cagley, Hughson, Pries, and Tendon

Software Process and Measurement Cast - Sun, 08/14/2016 - 22:00

The Software Process and Measurement Cast 407 includes four separate columns.  We begin with a short essay refreshing the pros and cons of Test Driven Development. Test Driven Development promises a lot of benefits but all is not light, kittens and puppies. Still, TDD is well worth doing if you go into it with your eyes open.

Our second column features Kim Pries, the Software Sensei. ¬†Kim discusses what makes software ‚Äúgood.‚ÄĚ The Software Sensei puts the ‚Äúgood‚ÄĚ in quotes because it is actually a difficult word to define but Kim is willing to give the discussion a go!

In our third column, we return to Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 10 which is titled The Thinking Processes. Thinking processes are key to effectively using  Agile, lean and kanban processes.  

Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. ¬†In this installment, we discuss the blog entry titled ‚ÄúLearning to Deal with the Inevitable.‚ÄĚ ¬†Gene and I discussed change which is inevitable and innovation which is not quite as inevitable.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 16 and 17.   Chapter 16 ends Section One with an interview with Brad Jensen.  Section Two addresses the philosophies of XP.  Chapter 17 tells the creation story of XP from Beck’s point of view.

We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

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

In the next Software Process and Measurement Cast, we will feature our interview with Kupe Kupersmith. Kupe brings his refreshing take on the role of the business analyst in today’s dynamic environment.  This interview was informative, provocative and entertaining.     

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Extreme Programming Explained, Second Edition: Re-Read Week 9 (Chapters 16 ‚Äď 17)

XP Explained Cover

This week we reach a bit of transition in Kent Beck and Cynthia Andres‚Äôs Extreme Programing Explained, Second Edition (2005). A short but contextually important entry. Chapter 16 ends Section One with an interview with Brad Jensen. ¬†Section Two addresses the philosophies of XP. ¬†Chapter 17 tell the creation story of XP from Beck’s point of view.

Chapter 16: Interview
The chapter is an interview with Brad Jensen of Saber Airline Solutions that details his organization’s story of implementing and using XP. ¬†The story provides guidance, cautions and a presentation of the benefits gained from using XP.

Jensen reported that Saber experienced a substantial reduction in defects.  The reduction in defects was substantial enough to outperform the CMMI Maturity Level 5 organizations that participated in the Bengaluru (Bangalore) SPIN.

Implementing XP was not easy. ¬†Implementing XP was a slow process of establishing buy-in eventually reaching 80 – 90% penetration. He indicated that at the end of the day they had the courage to fire people who wouldn’t pair program. In essence, those that eventually couldn’t or wouldn’t make the transition were jettisoned so the organization could reap the benefits of quality and productivity.

The interview ends with Jensen’s recommendation to use XP.

Section 2: Philosophy of XP

The section of the book discusses the philosophy of XP. ¬†Over the nine chapters in this section, Beck and Andres explored applying lessons from other to accelerate the application of XP and applying XP in the varied development environments found in the today’s world.

Chapter 17: Creation Story
If you reflect, often the difference between the ideas that catch on and those that don’t is less about effectiveness and more a function of their legends or stories. The story serves to anchor the ideas and to place them in context so they can more easily be consumed. ¬†Daniel Pink, in his book Made to Stick, described how ideas can become sticky. A story that connects with the person consuming the story’s perception of the world is a ¬†major step towards making the idea stick in their mind. ¬†The XP creation story described by Beck reflects a project reality that almost everyone in software development and maintenance has experienced. ¬†The fact that we can relate predisposes developers to listen and accept the ideas that are at the core of XP.

XP was “born” on the Chrysler payroll project. Beck was called in to evaluate and later to rescue a large project that had turned into a “train wreck.” The assessment was that if the project left to continue on the current path that delivery was a pipe dream. ¬†Beck was asked to rescue the project which provided a lavatory for using XP. ¬†In the book, Beck stated, “My goal laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10″ this was the outline of extreme programming.” Leveraging XP helps turns the project that had begun as a train wreck into a business success. ¬†The XP creation story presents us with a version of the hero’s journey beginning where the journey started, the trials along the way, the goal that was attained and the steps to move forward after the goal has been met.

The recitation of the creation story serves multiple purposes.  First, the story makes the point that XP can scale to be used on large projects successfully.  Additionally, the creation story and the interview in Chapter 16 explicitly identifies benefits are attainable using XP which is important in order to explain the value of XP.

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 ‚Äď 13

Week 8, Chapters 14 – 15

A few quick notes. We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.

 


Categories: Process Management

Two Teams or Not: First Do No Harm (Part 1)

 

Restroom Closed Sign

Sometimes a process change is required!

Coaching is a function of listening, asking questions and then listening some more.  All of this listening and talking has a goal: to help those being coached down a path of self-discovery and to help them to recognize the right choice for action or inaction.  Sometimes the right question is not a question at all, but rather an exercise of visualization.

Recently when a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together, I saw several paths to suggest.  The first set of paths focused on how people behave during classic Scrum meetings and how the team could structure stories.  However, another path presented itself as I continued to consider options based on the question.  

As a reminder, the team is composed of 8 – 10 people using Scrum, but the team operates in two basic silos. ¬†One subset works on UI related stories while a second focuses on the backend related stories. Let’s pretend that¬†after a long discussion with the team on whether there were really two teams in one or whether splitting the stories differently would address the issue, the team was still unsure how they wanted to address the problem.

Another path to self-discovery is to start at “nothing” and determine if the siloization is causing substantial problems. ¬†I have found that many times teams feel powerless to address process and organizational structure issues unless they can visualize the problem. ¬†Visualization takes the problem out of the theoretical (something feels wrong but I don‚Äôt know what it is) and makes it tangible. ¬†This is where kanban – or in this case, Scrumban – is valuable as a tool to help the team to identify their own problem. ¬†A simple approach to consider would include the following steps:

  1. Visualize the workflow. Identify the major steps in the process of delivering functionality that is performed by the team.  Begin with the backlog and end when your team has completed working on the story (hopefully, this results with the functionality in the hands of users).  On a whiteboard (butcher paper and sticky notes also work) write the steps across the top with the backlog on the far left and done/production on the far right.  Arrange the steps in the order they happen.

Consider how the tasks related to the two silos interact. If you have two standalone workflows that are independent of each other (independence defined as each sub-team can draw a story, complete their steps, and put the functionality in production) we have two separate teams living under a single roof. Then the question is: is this a bad thing?  It might not be a problem. Until that issue is tackled, relax and move forward as two teams using Scrumban or revert to the current method (there is no harm from visualization).  For all other scenarios go to the next step.   Note: visualization can expose all sorts of process problems that do not relate to the two team issue.  I suggest not making any process changes until you take the next two steps, which position the team to collect data and structured experience.

In the next installment we will progress from visualization to assigning working in process (WIP) , doing work and then using data to recognize problems and make changes which lead to a healthy team.


Categories: Process Management

Quote of the Month August 2016

From the Editor of Methods & Tools - Wed, 08/10/2016 - 09:29
Are there unbreakable laws ruling the process of software development? I asked myself this question while reflecting on a recent project, and the answer leads to many conclusions, some already known and some more revealing. Scientific laws reflect reality and cannot be broken. They have strong implications onto how we build things. For instance, there […]

Avoid Two Teams in One if Possible!

How can this team really work together?

How can this team really work together?

I recently got a question from a long-time reader and listener.  I have removed the name to ensure confidentiality.

Context:

  • The person who asked the question is an experienced Agile leader.
  • The team is not all technically-equal full-stack developers, some developers work on UI stories and others work on backend stories.
  • The team has 8-10 people.

The Problem:

  • During story grooming/sizing, the entire team does not participate equally to¬†offer up their points. UI developers participate on UI stories and are reluctant to chime in on backend work, and vice-versa.

The Question:

  • Scrum seeks to involve the entire team. ¬†How can I get everyone involved (or should I)?¬†

Both questions are interesting questions.  I answered with some advice and some follow-up questions.

Further Thoughts Part 1:

  1. Do you really have two teams that you have grouped together into one for organizational purposes?  Are the stories on your backlog related to each other or could you have two separate backlogs with the resultant code implemented separately?

It is possible that although the organization has decided that this group of people are a single team, they really represent two separate teams serving different masters and pursuing separate goals.  If that is true there is no reason for them to act as a single team.  That said, I suspect the segregation driven by specialization is the real issue.  The leader (who may or may not be the organizational manager) needs to work on breaking down silos.  Historically organizations have adopted the manufacturing model as a tool to increase task efficiency. The manufacturing model does not fit software development and maintenance perfectly and often causes local optimizations, which rarely produce the most output (flow) from the system.  Therefore . . .

Further Thoughts Part 2:

  1. Could you reshape your stories so that they would include both UI and backend programmers?  This would create a scenario where they have to collaborate and it makes co-estimating more than an academic exercise.

Reshape the user stories to represent thin slices of the functionality so that someone from each silo needs to be involved in order to deliver. Functionally slicing the stories creates a reason for UI and backend personnel to coordinate and collaborate.  Creating scenarios that both facilitate and require collaboration will give each silo a reason work together in deciding how much work to commit to in a sprint as a team.  The thin functional slicing drives home the point that unless the story works in production and meets the business need, it isn’t done.  Note: sometimes a story will only impact the back or front end (although I suspect there would need to be testing), but these should be relatively rare IF this is a single team.

Further Thoughts Part 3:

  1. Perhaps this is a scenario where pairing might be an interesting approach to getting team members to have a single vision.

The XP practice of¬†pair programming¬†is when two people and one keyboard collaborate on programming. ¬†In this scenario, put a UI and backend person together with a single story, a single keyboard and then lock the door (ok, that’s a little hyperbole). ¬†This practice will help break down barriers. ¬†Another possible solution is to try mob programming on the first day of the sprint (one keyboard and the WHOLE team collaborating together). ¬†Mob programming on the first day of a sprint is a fantastic tool to get the team moving in the same direction and to focus on common issues.

There are other possibilities, such using a test-first approach (perhaps start with acceptance testing driven development), to help involve business community.  I have occasionally used ATDD to help get lots of eyes on a problem.  All of these topics should be addressed in a retrospective. Until the team recognizes that they have a problem, it will be tough for them to commit to a change.

 

 


Categories: Process Management

The Dangers of a Definition of Ready

Mike Cohn's Blog - Tue, 08/09/2016 - 15:00

Although not as popular as a Definition of Done, some Scrum teams use a Definition of Ready to control what product backlog items can enter an iteration.

You can think of a Definition of Ready as a big, burly bouncer standing at the door of the iteration. Just as a bouncer at a nightclub only lets certain people in—the young, the hip, the stylishly dressed—our Definition-of-Ready bouncer only allows certain user stories to enter the iteration.

And, as each nightclub is free to define who the bouncers should let into the club, each team or organization is free to define its own definition of ready. There is no universal definition of ready that is suggested for all teams.

A Sample Definition of Ready

So what types of stories might our bouncer allow into an iteration? Our bouncer might let stories in that meet rules such as these:

  • 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.
A Definition of Ready Defines Pre-Conditions

A Definition of Ready enables a team to specify certain pre-conditions that must be fulfilled before a story is allowed into an iteration. The goal is to prevent problems before they have a chance to start.

For example, by saying that only stories below a certain number of story points can come into an iteration, the team avoids the problem of having brought in a story that is too big to be completed in an iteration.

Similarly, not allowing a story into the iteration that has external dependencies can prevent those dependencies from derailing a story or an entire iteration if the other team fails to deliver as promised.

For example, suppose your team is occasionally dependent on some other team to provide part of the work. Your user stories can only be finished if that other team also finishes their work—and does so early enough in the iteration for your team to integrate the two pieces.

If that team has consistently burned you by not finishing what they said they’d do by the time they said they’d do it, your team might quite reasonably decide to not bring in any story that has a still-open dependency on that particular team.

A Definition of Ready that requires external dependencies to be resolved before a story could be brought into an iteration might be wise for such a team.

A Definition of Ready Is Not Always a Good Idea

So some of the rules our bouncer establishes seem like good ideas. For example, I have no objection against a team deciding not to bring into an iteration stories that are over a certain size.

But some other rules I commonly see on a Definition of Ready can cause trouble—big trouble—for a team. I’ll explain.

A Definition of Ready can be thought of like a gate into the iteration. A set of rules is established and our bouncer ensures that only stories that meet those rules are allowed in.

If these rules include saying that something must be 100 percent finished before a story can be brought into an iteration, the Definition of Ready becomes a huge step towards a sequential, stage-gate approach. This will prevent the team from being agile.

A Definition of Ready Can Lead to Stages and Gates

Let me explain. A stage-gate approach is characterized by a set of defined stages for development. A stage-gate approach also defines gates, or checkpoints. Work can only progress from one stage to the next by passing through the gate.

When I was a young kid, my mom employed a stage-gate approach for dinner. I only got dessert if I ate all my dinner. I was not allowed to eat dinner and dessert concurrently.

As a product development example, imagine a process with separate design and coding stages. To move from design to coding, work must pass through a design-review gate. That gate is put in place to ensure the completeness and thoroughness of the work done in the preceding stage.

When a Definition of Ready includes a rule that something must be done before the next thing can start, it moves the team dangerously close to stage-gate process. And that will hamper the team’s ability to be agile. A stage-gate approach is, after all, another way of describing a waterfall process.

Agile Teams Should Practice Concurrent Engineering

When one thing cannot start until another thing is done, the team is no longer overlapping their work. Overlapping work is one of the most obvious indicators that a team is agile. An agile team should always be doing a little analysis, a little design, a little coding, and a little testing. Putting gates in the development process prevents that from happening.

Agile teams should practice concurrent engineering, in which the various activities to deliver working software overlap. Activities like analysis, design, coding, and testing will never overlap 100%—and that’s not even the goal. The goal is overlap activities as much as possible.

A stage-gate approach prevents that by requiring certain activities to be 100% complete before other activities can start. And a definition of ready can lead directly to a stage-gate approach if such mandates are included in the Definition of Ready.

That’s why, for most teams, I do not recommend using a Definition of Ready. It’s often unnecessary process overhead. And worse, it can be a large and perilous step backwards toward a waterfall approach.

In some cases, though, I do acknowledge that a Definition of Ready can solve problems and may be worth using.

Using a Definition of Ready Correctly

To use a Definition of Ready successfully, you should avoid including rules that require something be 100 percent done before a story is allowed into the iteration—with the possible exception of dependencies on certain teams or vendors. Further, favor guidelines rather than rules on your Definition of Ready.

So, let me give you an example of a Definition of Ready rule I’d recommend that a team rewrite: “Each story must be accompanied by a detailed mock up of all new screens.”

A rule like this is a gate. It prevents work from overlapping. A team with this rule cannot practice concurrent engineering. No work can occur beyond the gate until a detailed design is completed for each story.

A better variation of this would be something more like: “If the story involves significant new screens, rough mock ups of the new screens have been started and are just far enough along that the team can resolve remaining open issues during the iteration.”

Two things occur with a change like that.

  1. The rule has become a guideline.
  2. We’re allowing work to overlap by saying the screen mockups are are sufficiently far along rather than done.

These two changes introduce some subjectivity into the use of a definition of ready. We’re basically telling the bouncer that we still want young, hip and stylishly dressed people in the nightclub. But we’re giving the bouncer more leeway in deciding what exactly “stylishly dressed” means.

Mapping Biases to Testing: Confirmation Bias

Xebia Blog - Mon, 08/08/2016 - 20:24
I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect. Let me state the ‚Äėbad news‚Äô up front: you cannot fully avoid the confirmation bias. That‚Äôs actually a good thing, because

SPaMCAST 406 ‚Äď Erik van Veenendaal, Quality, Agile and the TMMi

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 406 features our interview with Erik van Veenendaal.  We discussed Agile testing, risk and testing, the Test Maturity Model Integrated (TMMi), and why in an Agile world quality and testing still matter.

Erik van Veenendaal (www.erikvanveenendaal.nl) is a leading international consultant and trainer, and a recognized expert in the area of software testing and requirement engineering. He is the author of a number of books and papers within the profession, one of the core developers of the TMap testing methodology, a participant in working parties of the International Requirements Engineering Board (IREB). He is one of the founding members of the TMMi Foundation, the lead developer of the TMMi model and currently a member of the TMMi executive committee. Erik is a frequent keynote and tutorial speaker at international testing and quality conferences. For his major contribution to the field of testing, Erik received the European Testing Excellence Award (2007) and the ISTQB International Testing Excellence Award (2015). You can follow Erik on twitter via @ErikvVeenendaal.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 14 and 15.  This week we dive into design and scaling. These chapters  address two critical and controversial topics that XP profoundly rethought.

I am still collecting thoughts on what to read next. Is it time to start thinking about what is next: a re-read or a new read?  Thoughts?

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

The next Software Process and Measurement Cast will focus on our recent revisit of Test Driven Development (TDD).  TDD is an important feature of XP that can be (and should be) used if quality and efficiency are important to your organization.

We will also have a new column from Steve Tendon (welcome back Steve!)  and Gene Hughson AND maybe one more but we will see!   

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 406 - Erik van Veenendaal, Quality, Agile and the TMMi

Software Process and Measurement Cast - Sun, 08/07/2016 - 22:00

The Software Process and Measurement Cast 406 features our interview with Erik van Veenendaal.  We discussed Agile testing, risk and testing, the Test Maturity Model Integrated (TMMi), and why in an Agile world quality and testing still matter.

Erik van Veenendaal (www.erikvanveenendaal.nl) is a leading international consultant and trainer, and a recognized expert in the area of software testing and requirement engineering. He is the author of a number of books and papers within the profession, one of the core developers of the TMap testing methodology, a participant in working parties of the International Requirements Engineering Board (IREB). He is one of the founding members of the TMMi Foundation, the lead developer of the TMMi model and currently a member of the TMMi executive committee. Erik is a frequent keynote and tutorial speaker at international testing and quality conferences. For his major contribution to the field of testing, Erik received the European Testing Excellence Award (2007) and the ISTQB International Testing Excellence Award (2015). You can follow Erik on twitter via @ErikvVeenendaal.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 14 and 15.  This week we dive into design and scaling. These chapters  address two critical and controversial topics that XP profoundly rethought.

I am still collecting thoughts on what to read next. Is it time to start thinking about what is next: a re-read or a new read?  Thoughts?

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

The next Software Process and Measurement Cast will focus on our recent revisit of Test Driven Development (TDD).  TDD is an important feature of XP that can be (and should be) used if quality and efficiency are important to your organization.

We will also have a new column from Steve Tendon (welcome back Steve!)  and Gene Hughson AND maybe one more but we will see!   

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.



Categories: Process Management

Extreme Programming Explained, Second Edition: Re-Read Week 8

XP Explained Cover

This week we tackle Chapter 14 and 15 in Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005).  Chapter 14 deals with design.  Software design is a transition point in the life cycle that begins with business requirements and ends in functional software. The design translates the need into a cohesive solution. Chapter 15 covers topics related to scaling.  Scaling concepts focus on using XP to solve larger, more complex problems in more complex organizations.   

Next week we have more what will follow Extreme Programing Explained, Second Edition (2005) ; a re-read or a new read?  Thoughts?  In this week’s we tackle two concepts central to XP; planning and testing, both done the XP way.

Chapter 14: Designing: The Value of Time

One of the most important features of XP is the delivery of functionality every week or two weeks (depending on iteration length). In order to facilitate that process, XP embraces the concept of incremental design.

The design is important to software.  The design allows software developers to share  and inherit elements and components or to copy and use pieces of a design in other instantiations or even other applications. While metaphors of physical design are often used in software, those metaphors don’t work for software design and often constrain the options that we consider in the long run.  For example, the design for a physical product such as a bridge is created and set in stone (ok, maybe you can add flag holders and flags, but that is not a significant design extension). Software designs are far more flexible and changeable, and most importantly software designs can be incrementally built.  Once built a suspension bridge can’t be easily modified into a cantilever bridge, on the other hand, an application running in three tier client server can be incrementally shifted to the cloud.

The incremental approach of delivering value (rather than a big bang approach) provides the basis for gathering feedback faster.  The faster users can interact with the functionality and then provide feedback, the faster the XP can adapt.  Beck suggests that the art of designing is to get feedback and then to use the feedback to do only as much design as needed to get the next feedback.  Beck is defining a continuous improvement loop that begins with just enough design upfront.

Recently I visited Italy and was fortunate enough to be able to spend time looking at Michelangelo’s David.  His design was inspiring but unlike the design of David, the team is continuously learning and the technical environment is evolving which means there are alway new and better ways to design the software. If learning, experience, and technical evolution can positively improve the design then delaying the completion of the design provides the greatest chance of increasing the value and quality of the product.  Timing when during a project, a design is needed requires considering the value learning and experience.

The chapter concludes with a set of criteria for evaluating whether a design is simple and useful enough:

  1. The design is appropriate for the intended audience. If those who are going to work on design and code don’t understand the design, then it isn’t appropriate.¬†
  2. Create a design that facilitates communication to the team and stakeholders.
  3. The design should not include duplication of logical structures which can make the design hard to understand.
  4. The design should have the fewest elements possible.  Designing fewer elements requires building and documenting few components.

 

Chapter 15: Scaling XP

Chapter 15 is a reminder that scaling has been a topic of conversation for a long time! Beck describes scaling XP along seven dimensions.

A number of people: One of the classic scaling mechanisms is to add people. Earlier in my career the organization I worked for told clients that it would ‚Äúdarken the skies with SEs‚ÄĚ (software engineers) to deal with their projects. ¬†Beck, influenced by the Mythical Man-Month, suggests a different path.

  1. Break the problem down into smaller parts. Breaking work into smaller parts allows better prioritization, supports getting started and getting feedback faster.  Prioritization also helps to highlight items in the backlog that might be gold plating.
  2. Use simple solutions whenever possible. Keeping things simple allows work to be done faster, gets feedback faster and in the longer run is easier to maintain.
  3. Apply a complex solution to any problem that’s left.

Investment: This not a scaling issue rather it is a reflection of how organizations account for work.  XP does not change the accounting rules for what can be expensed or capitalized in projects. Make sure you discuss how XP works with your financial group before you start to reduce the potential for surprising accounting!

Size of organization: An XP team can be an island in a larger organization by being transparent and maintaining communication. Maintaining communication in a larger organization will require understanding the information needs of those outside of the XP bubble and then finding a mutually agreed upon way to address those needs.  Beck suggests that the project manager role can provide the interface.

Time: XP supports long running projects (scaling using duration) by building a test base from TDD which prevents many of the common maintenance mistakes. TDD tests also act as a history of project or product development.

Problem complexity: Specialization is a common scaling approach used to great effect in manufacturing and by extension software development.  The assembly line is an example of using specialization to address problem complexity. XP uses pair programming as a tool to leverage the history of specialization in IT to generate closer close cooperation which improves a team’s ability to scale.  Pairing helps team members learn a bit about each other’s specialty which deepens cooperation and the ability to share work across the team.

Solution complexity: The XP dictum to break work down and then to build incrementally allows the team (or team-of-teams) to chip away at the solution, deliver and then get feedback.

Consequence of failure: XP practices are built to provide focus on work in a very transparent environment.  Stories or requirements with a high potential consequence of failure may closer verification and validation. For example, the software that controls x-ray machines.  XP practices that help address the consequence of failure include building in tests using TDD to prove that the work meets needs.  Other tools include pair programming, breaking working to smaller parts and continuous builds. That said, nowhere in XP does it say that you can’t add steps to the flow of work to address mission, safety or security critical requirements. 

XP asks us to simplify problems, apply the basic principles and values, leverage the core practices and then to interact and collaborate with teams outside in order to scale to meet the problem, technical and organizational complexity.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 – 13

 


Categories: Process Management

Measuring Test-Driven Development

Measuring TDD is a lot like measuring a cyclone!

Measuring TDD is a lot like measuring a cyclone!

Teams and organizations adopt test-driven development for many reasons, including improving software design, functional quality, time to market or because everyone is doing it (well maybe not that last reason‚Ķyet). ¬†In order to justify the investment in time, effort and even the cash for consultants and coaches, most organizations want some form of proof that there is some return on investment (ROI) from leveraging TDD. The measurement issue is less that something needs to be measured (I am ignoring the ‚Äúyou can‚Äôt measure software development crowd‚ÄĚ), but rather what constitutes an impact and therefore what really should be measured. Erik van Veenendaal, an internationally recognized testing expert stated in an interview that will be published on SPaMCAST 406, ‚Äúunless you spend the time to link your measurement or change program to business needs, they will be short-lived.‚ÄĚ ¬†Just adopting someone else‚Äôs best practices in measurement tends to be counterproductive because every organization has different goals and needs. ¬†This means they will adopt TDD for different reasons and will need different evidence to assure themselves that they are getting a benefit. ¬†There is NO single measure or metric that proves you are getting the benefit you need from TDD. ¬†That is not to say that TDD can‚Äôt or should not be measured. ¬†A pallet of measures that are commonly used based on the generic goal they address are:

Goal:  Improve Customer Satisfaction

  • ¬†¬†¬†¬†¬†¬†Customer Satisfaction Index ‚Äď Measure the satisfaction of customers of the product or project by asking a series of question and then measure how their response changes over time.
  • ¬†¬†¬†¬†¬†¬†¬†¬†Net Promoter ‚Äď Ask customers¬†‚Äúhow likely you are to recommend the product or organization being measured to a friend or colleague?‚ÄĚ The change difference between the percentage that will recommend the product or project and those that will not recommend shows how customer satisfaction is changing.
  • ¬†¬†¬†¬†¬†¬†¬†¬†Delivered Defects: ¬†A count (or a scaled count, such as defects per unit of work) of delivered defects are often used as a proxy for customer satisfaction.

Goal:  Decrease the Cost of Development

  • ¬†¬†¬†¬†¬†¬†¬†¬†Development and Delivered Defects (combined): The change in the counted (or a scaled count, such as defects per unit of work) defects discovered and those delivered across the development process is a direct measure of quality and has been shown to be directly correlated to quality. ¬†As the number of defects created falls cost goes down.
  • ¬†¬†¬†¬†¬†¬†¬†Labor Productivity: The ratio of output per person. Labor productivity measures the efficiency of the labor in the transformation of something into a product of higher value. ¬†Improving efficiency is typically linked to decrease the cost of creating a product or delivering a project.

Goal: Improve Product or Project Time-to-Market

  • ¬†¬†¬†¬†¬†¬†¬†Time to Market: ¬†A measure of the measures the speed an item moves through the development process from backlog to production. This measure is always denominated by calendar time, but the numerator can either be value or size depending on the specific question the organization needs to answer. ¬†
  • ¬†¬†¬†¬†¬†¬†¬†¬†Concept to Cash: A measure of the calendar time that it takes for an idea to go from being accepted into the portfolio backlog until it is first sold (or delivered) in the market place.

Goal: Improve Product or Project Quality

  • ¬†¬†¬†¬†¬†¬†¬†Delivered Defects: ¬†A count (or a scaled count such as defects per unit of work) of delivered defects. ¬†All things being equal, defects that customers (or users) experience negatively affect the perception of product quality. ¬†The higher the number of delivered defects the low the perception of quality.
  • ¬†¬†¬†¬†¬†¬†¬†¬†Defect Removal Efficiency: Defect Removal Efficiency (DRE) is the ratio of the defects found before implementation and removed to the total defects found through some period after delivery (typically thirty to ninety days).
  • ¬†¬†¬†¬†¬†¬†¬†¬†Test Code Coverage: A measure of the number of branches or statements that are covered by a group of tests. For example in TDD, when a developer pulls a story from the backlog, he or she would write a series of tests that would prove they have completed the story, run the tests (they should all fail) then they would write the code and re-run the tests which would all pass. There should be tests written that exercise each line of code written or changed (100% coverage). ¬†In TDD, generally, as the code coverage goes up fewer defects fail to be discovered and get delivered to someone else.

Goal: Improve Software Design

  • ¬†¬†¬†¬†¬†¬†¬†¬†Improved Design: ¬†Measuring design is a can of worms. ¬†Attributes that can be measured include reliability, efficiency, maintainability, and usability. ¬†Which design attribute should be measured is dependent on the needs of the business. ¬†For example, for consumer products increased usability (how easy is the product to use) might be a critical measure.

Goal: Improve Compliance to Development Techniques (note: compliance is an internal goal and only tangentially relates to business goals; therefore, it should be adopted only if the indirect measures can be traced to delivering stated business goals.) 

  • ¬† ¬† ¬† ¬†¬†Ask and Count: A simple approach to measure TDD is when the code for stories is checked in either ask if TDD test cases were created and run or validate that test cases were committed (before and after) along with the code.¬†
  • ¬†¬†¬†¬†¬†¬†¬†¬†Change in the Automated Test Suite: ¬†Count the number of tests that have been added, changed or deleted on a daily basis. This is a simple accounting approach that can be easily tracked. ¬†As stories are accepted to be worked, changes to the automated test base will be apparent.

TDD is an important mechanism that puts the onus for unit testing directly on the members of the development team.  If you code, you test.  When adopting TDD compliance measures, it may be important to show progress HOWEVER they are not as important as measuring business value.Measures and metrics for TDD need to be focused on changing something that is important to the business, such as cost, quality, time-to-market or perhaps usability. Because in the end, that is really what counts!

Are there other options assuming you are going to measure your TDD implementation?


Categories: Process Management