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' 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.

The Case for Test Driven Development Refreshed: Pros

TDD is a life jacket for Quality.

TDD is a life jacket for quality.

Test Driven Development promises serious results for teams, organizations, and customers, including improved quality and faster delivery. The promises of TDD, or any of the other variants of test-first development techniques, are at least partially offset by costs and potentially tragic side effects when it is done poorly.

The positive impacts explored in earlier articles on TFD and TDD include:

  • Fewer Delivered Defects: Testing finds defects; more timely testing is apt to find defects before they get delivered, and better testing tends to find more defects.
  • Communication: The process of developing tests requires conversation, which is at the heart of Agile techniques. Better communication yields software better targeted to the organization’s needs.
  • Better Tests: TDD (or any of the test-first techniques) ensures that the tests are reviewed early and often, which helps to ensure only what is needed is tested.
  • Code Quality: By only writing as much code as is needed to pass the test, TDD will ensure that functionality remains as simple as possible. This will yield higher code quality because there will be fewer chances to embed defects.
  • Less Dead Code: Refactoring the code and design is a tool to remove dead code-making programs more readable and therefore easier to maintain.

In addition to the improving quality, reducing and removing defects more effectively, TDD delivers a number of additional positive psychological and quantitative benefits that include:

  • Improves Motivation: Teams that deliver higher quality functionality are often more motivated. Giovanni Asproni in his paper Motivation, Teamwork, and Agile Development (also published in Agile Times, Vol. 4, February 2004) shows a link between the standards of excellence Agile requires and supports using techniques such as TDD produce more highly motivated teams. Simply put, when teams feel they are delivering higher quality products they are more motivated and therefore deliver more high-quality product in a virtuous cycle.
  • Facilitates Being Agile: TDD is effective when teams break work into smaller chunks, define what done looks like, develop something tangible and then get feedback. The empirical cycle built into effective TDD is at the heart of learning to practice Agile. There has been a long-running argument in the Agile literature about the difference between doing Agile (just following the ceremonies and practices) and being Agile (getting and feeling the benefits from doing Agile). TDD provides those that are “doing” Agile with the feedback that provides a connection to tangible benefits from Agile pushing them up Maslow’s Hierarchy towards self-actualization.
  • More Effective than Classic Debugging. Back in the dark ages, developers would develop code for some period of time and then assume the code compiled or built (the act is a rudimentary form of debugging) would determine how to unit test the work and then test it. Right after the “test it” steps the fun of pouring through code that may have written weeks or months in the past would begin. Debugging was usually painful and fraught with its own errors (I have blotted most of the pain from my memory). TDD and other TFD techniques start with defining how the code will be tested and leverage Agile shorter cycle times to reduce the potential of both not testing everything AND not remembering what you actually did and where when you changed the code.
  • Functionality Can be Delivered Sooner. TDD ensures that functionality we are writing is tested and can be demonstrated and potentially delivered. The goal of most Agile techniques is to get the functional code in front of customers so they can provide feedback and potentially use the functionality. TDD makes sure that developers know what they are building and know how they will prove it works before they write the first line of code.

TDD is part requirements development, part testing technique and all the while a collaboration tool to ensure the team focuses on delivering high-quality functionality.

Next, we visit the other side of the TDD discussion.


Categories: Process Management

Test First and Test Driven Development: Is There a Difference?

Testing is about predicting the future!

Testing is about predicting the future!

Test-first development is an old concept that was rediscovered and documented by Kent Beck in Extreme Programming Explained (Chapter 13 in the Second Edition).  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. In a response to a question on Quora, Beck described reading about developers using a test-first approach well before XP and Agile. Test-driven development is test-first development combined with design and code refactoring.  Both test-first and test-driven development  are useful for improving quality, morale and trust and even though both are related they not the same.

A little more history.  Test-first programming / development was introduced (or re-introduced) as a primary practice of Extreme Programing in Chapter 7 of Extreme Programing Explained (page 50). Test-driven development as a method was described in Test Driven Development: By Example (2003, perhaps we will re-read this book in the future), and is an evolution of the test-first concept.

Test-first development has a few basic steps.

  1. The developer accepts a unit of work and writes a set of tests that will prove that the code actually functions correctly at a unit level.
  2. They then run the tests.  The tests should fail because the code to solve the business problem embedded in the unit of work has not been written.  If the tests pass, rewrite them so that they fail (assuming someone else has not fixed the problem).
  3. Write the code needed to solve the problem. Remember that simplicity is king and only write enough code to solve the problem.
  4. Run the test suite again. If the tests pass you are done; however, if ANY of the tests doesn’t pass return to step three and correct the code.  Repeat steps three and four until all tests pass.

Test-driven development, TDD (also known as test-driven design) adds one additional “step” to the process after the unit tests.

  1. Refactor the code and design to make both as simple as possible and remove any possible duplication.

As the code is written and refactored the design evolves based on the feedback gathered one story at a time. TDD integrates the practice of coding and unit testing with evolutionary design, breaking down the separation of roles that reduce collaboration and increase the cost of quality. A conceptual advance; however, there are organizations such as ATMs, automotive products and medical devices where the concept of evolutionary design is a bridge too far, leaving test first as their only option.

In TDD by Example, Beck identifies two “rules” for TDD that not directly identified in the introduction of TFD.  The first is to never write a line of code until you have written a failing automated test and the second is to avoid duplication. TFD recognized the need to combine manual and automated unit tests.  Both of these rules could be applied (and should be if possible) for both TDD and TFD, and in the long run are just good practice.

The only significant difference between test-first and test-driven development is a biggie – the inclusion of using the coding and unit testing feedback loop as a tool to propel incremental and emergent design techniques.   


Categories: Process Management

Scrum Day Europe 2016

Xebia Blog - Mon, 07/25/2016 - 10:50
During the 5th edition of Scrum Day Europe, Laurens and I facilitated a workshop on how to “Add Visual Flavor to Your Organization Transformation with Videoscribe.” The theme of the conference, “The Next Iteration,”  was all about the future of Scrum. We wanted to tie our workshop into the theme of the conference, so we had

SPaMCAST 404 – Ryan Ripley, The Business of Agile

SPaMCAST Logo

http://www.spamcast.net

Listen Now
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

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 9 and 10. It is great to see the concepts we explored when we re-read Goldratt’s The Goal come back to roost.  This week we focus on roles, the definition of team, flow and more flow.    

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 feature our essay productivity.  A lot of people would tell you productivity does not matter or that discussing productivity in today’s Agile world is irrational. They are wrong. Productivity is about jobs. We will also have columns from the QA Corner and for Jon Quigley.  I think 405 might be just a bit controversial.

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 404 - Ryan Ripley, The Business of Agile

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

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

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 9 and 10. It is great to see the concepts we explored when we re-read Goldratt’s The Goal come back to roost.  This week we focus on roles, the definition of team, flow and more flow.    

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 feature our essay productivity.  A lot of people would tell you productivity does not matter or that discussing productivity in today’s Agile world is irrational. They are wrong. Productivity is about jobs. We will also have columns from the QA Corner and for Jon Quigley.  I think 405 might be just a bit controversial.

 

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: Week 6

XP Explained

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.

Chapter 10 -The Whole XP Team

The principal flow, as described in our re-read of Goldratt’s The Goal, proves that more value is created when a system achieves a smooth and steady stream of output. In order to achieve a state of flow, everyone on the team needs to be linked to the work to reduce delay and friction between steps.  Implementing the steps necessary to address complex work within a team is often at odds with how waterfall projects break work down based on specialties. Unless the barriers between specialties are broken down it is hard to get people to agree that you can work incrementally in small chunks versus specialty-based phases such as planning, analysis, design and more.

Every “specialty” needs to understand their role in XP. 

Testers – XP assumes that programmers using XP take on the responsibility for catching unit-level mistakes. XP uses the concept of test-first programming.  In test-first programming, the team begins each cycle (sprint in Scrum) by writing tests that will fail until the code is written. Once the tests are written and executed to prove they will fail, the team writes the code and runs the tests until they pass. It is at least a partial definition of done. As the team uncovers new details, new tests will be specified and incorporated into the team’s test suite.  When testers are not directly involved writing and executing tests they can work on extending automated testing.

Interaction designers – Interaction designers work with customers to write and clarify stories. Interaction designers deliver analysis of actual usage of the system to decide what the system needs to do next. The interaction designer in XP would also encompass the UX and UI designer roles as they have evolved since XP Explained was written and updated.  The designer tends to be a bit in front of the developers to reduces potential delays.

Architects – Architects help the team to keep the big picture in mind as development progresses in small incremental steps.  Similar to the interaction designer, the architect evolves the big picture just enough ahead of the development team to provide direction (SAFe call this the architectural runway). Evolving the architecture in small steps and gathering feedback as development progress from incremental system testing reduces the risk that the project will wander off track.

Project managers – Project managers (PM) facilitate communication both inside the team and between customers, suppliers and the rest of the organization. Beck suggests that the PMO act as the team historians.  Project managers keep the team “plan” synchronized with the reality based on how they are performing and the world happening outside the team.

Product managers – Product managers write stories, pick themes and stories for the quarterly cycle, pick stories in the weekly cycle, answer questions as development progress and helps when new information is uncovered. The product manager helps the whole team prioritize work.  (Note: it is different from the concept of the product owner in Scrum).  The product manager should help the team focus on pieces of work that allow the system to be whole at the end of every cycle.

Executives – The executives’ role in XP is to provide an environment for a team so they have courage, confidence, and accountability. Beck suggests that executives trust the metrics.  The first metric is the number of defects found after development.  The fewer the better. The second metric that executives should leverage to build trust in XP is the time lag between idea inception and when the idea begins generating revenue.  This metric is also known as “concept to cash” (faster is better).

Technical writers – In XP, the technical writer role generates feedback by asking the question, “How can I explain that?” The tech writer can also help to create a closer relationship with users as they help them to learn about the product, listen to their feedback and then to address any confusion between the development team and the user community. Embedding the tech writer role into the XP team allows the team to get feedback on a more timely basis, rather than waiting until much later in the development cycle.

Users – Users help write user stories, provide business intelligence and make business domain decisions as development progress.  Users must be able to speak for the larger business community, they need to command a broad consensus for the decisions they make.  If users can’t command a broad consensus from the business community for the decisions they make, they should let the team work on something else first while they get thier ducks in a row.

Programmers – Programmers estimate stories and tasks, they break stories down into smaller pieces, write tests, write code, run tests, automate tedious development processes, and gradually improve the design of the system.  As with all roles in XP, the most valuable developers combine specialization with a broad set of capabilities.

Human resources – Human resources needs to find a way to hire the right individuals and then to evaluate teams.  Evaluating teams require changing the review process to focus on teams, rather than on individuals.

XP addressed roles that most discussions of Scrum have ignored, but that are needed to deliver a project. Roles should not be viewed as a rigid set of specialties that every project requires at every moment.  Teams and organizations need to add and subtract roles as needed. XP team members need to have the flexibility to shift roles as needed to maximize the flow of work.  

Chapter 11 – The Theory of Constraints

In order to find opportunities for improvement in the development process using XP, begin by determining which problems are development problems and which are caused outside of the development process. This first step is important because XP is only focused on the software development process (areas like marketing are out of scope). One approach for improving software development is to look at the throughput of the software development process.  The theory of constraints (ToC) is a system thinking approach for process improvement.  A simple explanation of ToC is that the output of any system or process is limited by a very small number of constraints within the process.  Using the ToC to measure the throughput of the development process (a system from the point of view of the ToC) provides the basis for identifying constraints, making a change and then finding the next constraint.  Using the ToC as an improvement approach maximizes the output of the overall development process rather focusing on the local maximization of steps.  

The theory of constraints is not a perfect fit for software development because software development is more influenced by people, therefore, is more variable than the mechanical transformation of raw materials. An over-reliance on the concepts like the ToC will tend to overemphasize process and engineering solutions over people solutions, such as a team approach. This is a caution rather than a warning to avoid process approaches. In addition, systems approaches can highlight issues outside of development’s span of control.  Getting others in the organization to recognize issues they are not ready to accept or address can cause conflict. Beck ends the chapter with the advice, “If you don’t have executive sponsorship, be prepared to do a better job yourself without recognition or protection.” Unsaid is that you will also have to be prepared to for the consequences of your behavior.   

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

 


Categories: Process Management

Customer Satisfaction Metrics and Quality

On a scale of fist to five, I'm at a ten.

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.

  1. 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.
  2. 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.


Categories: Process Management

The Ultimate Tester: Wrap-Up

Xebia Blog - Thu, 07/21/2016 - 16:14
To everyone who has read all or some of the past blog posts in this series: thank you so much for reading. I hope I have given you some food for thought on where you can improve as a tester (or developer who tests!).  In four blog posts, we explored what it takes to become

Our Answer To the Alert Storm: Introducing Team View Alerts

Xebia Blog - Thu, 07/21/2016 - 11:39
As a Dev or Ops it’s hard to focus on the things that really matter. Applications, systems, tools and other environments are generating notifications at a frequency and amount greater than you are able to cope with. It's a problem for every Dev and Ops professional. Alerts are used to identify trends, spikes or dips

Four Delivered Defect Metrics

Find the defects before delivery.

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: 

  1. Simple Backlog or List is the simplest defect measure. Relatively early in my career, I took over a testing group that supported a few hundred developers.  During the interview process, I determined that a lot of defects were being found in production; however, no one was quite sure how many were “a lot.” Enter the need to capture those defects and generate a simple backlog.
    Variants on the simple backlog include defect aging reports, counts by defect type, and quality of fix (how many times it takes to fix a defect) to name a few.
    Backlogs of delivered defects can be a reflection of all aspects of the development process.  Variants that include defect type or insertion point (where the defect come from) can be used to target a specific aspect of quality.
  2. Defect Arrival Rate (post implementation) is similar to the Defect Discovery and Cumulative Discovery Rates used to monitor defects during software development.  This metric is most often used to monitor the implementation of programs or other types of large-scale effort.  I used this tool to monitor bank mergers and conversions. Arrival rate metrics collected during the development process are most often a measure of structural quality; however, after functionality is in production it  is much more difficult to tie this metric to a specific aspect of quality.  More information is needed to determine whether the defect data is tied to functional, structural or process quality.
  3. 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). DRE is often used to evaluate the quality of the process used to develop the software (or other product). DRE includes information from all defect insertion tasks (such as analysis, design, and coding) and all defect removal tasks (reviews, testing and usage).
  4. Mean Time to Failure is the expected length of time a device or piece of software is expected to last in operation before it breaks. Failure is typically held to mean the device or software ceases to operate (defining the word failure is always a bit fraught).  This is most sophisticated of the classic quality metrics (really a measure of reliability) and is most often used to evaluate devices. Mean time to failure is almost always used to evaluate the functional aspect of quality.

The number and types of delivered defects are an obvious reflection of software quality.  The more defects a user of any sort finds, the lower the quality of the software. Simple counts of defects or backlogs, however, tend to provide less information value anytime we get past a few defects. 


Categories: Process Management

Is It Time to Stop Thinking about Projects?

Mike Cohn's Blog - Tue, 07/19/2016 - 15:00

For at least 15 years, I’ve heard people say that projects are dead. Projects and project-based thinking are relics of the 20th century.

I don’t buy it. Let me explain.

Let’s start with the definition of a project. The Project Management Institute (PMI) defines a project this way:

A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end.

The general argument against projects is that work is more continual now. There is no “definite beginning and end.” And many endeavors we might call project do not have a “temporary nature.”

As an example of why we might think projects are dead, think about a developer with a freshly earned university degree. The developer gets hired at Google and is assigned to the AdWords project. The developer then works on AdWords for the next 40 years.

Has this developer worked on a project? After all, a 40-year career spent on AdWords was not of a “temporary nature.” And there was no “definite beginning and end” other than the beginning and end of the developer’s career on the same product.

Yes, that’s true. But during our developer’s 40-year career on AdWords, there were undoubtedly initiatives or milestones that were focused on.

For example, Google occasionally overhauls or significantly enhances its ranking algorithms. Past algorithm updates have been given names like Penguin, Panda, Pigeon, Pirate and Hummingbird. Each of these updates was likely a “temporary endeavor undertaken to create a unique product, service, or result.” In other words, each was a project.

Did each have a definite beginning and end? Perhaps not. The ease with which software can be released today (especially for web-based products) often blurs start and stop dates of projects. An initial release is made and then, for example, is quickly updated over the next few weeks.

But, for all reasonable purposes, our developer’s 40-year AdWords career can be thought of as having been split into a series of shorter projects.

Why This Is Important

With any iterative and incremental process such as agile, there is a risk of delivering less value than possible because of focusing too much on the short term. When product owners are told to select the most important things each sprint, they can be tempted to select urgent items that customers are screaming for today rather than important items that will deliver more value over the longer term.

Projects mitigate this risk. Projects provide a planning horizon that is longer than a sprint--typically in the range of two to six months. This “definite beginning and end” that is focused on a “unique product, service or result” encourages product owners to select truly important things to work on rather than whatever some customer or salesperson screamed about yesterday.

I always encourage product owners and their teams to identify a milestone they are working toward that is longer than a single sprint. I like doing this quarterly, but other cycles can work equally well. The project, then, is the temporary pursuit of that milestone.

Projects remain a useful construct. They provide a motivation to accomplish something grander than could be done in a single iteration. Further, they serve as ways to group common work and provide a tangible target for teams working on them. Projects also facilitate communication about related sets of functionality.

Projects aren’t dead yet and I don’t see them going away.

What Do You Think?

Does your agile team organize work in projects (temporary endeavors in pursuit of an objective)? Have you experienced the sub-optimizing I’ve described when product owners look ahead only one iteration? Please share your thoughts in the comments below.

Software Development Conferences Forecast July 2016

From the Editor of Methods & Tools - Mon, 07/18/2016 - 14:12
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

SPaMCAST 403 – Agile At Scale, Real Transformations, Forewarned is Forearmed

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 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

The next Software Process and Measurement Cast will feature our interview with Ryan Ripley.  We discussed the presentation he is going to do at Agile 2016: 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!

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 403 - Agile At Scale, Real Transformations, Forewarned is Forearmed

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

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

The next Software Process and Measurement Cast will feature our interview with Ryan Ripley.  We discussed the presentation he is going to do at Agile 2016: 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!

 

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: Week 5

XP Explained

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.

Chapter 8: Getting Started

We implement XP to improve the development process and how the development process is experienced by those using the process. Given the motivation to improve, it might be tempting to try to implement all of the primary practices at once (or perhaps even to implement the practices alphabetically).  The right way to to implement XP will be different for every organization. Beck states that an organization can use any of the primary practices in any order.  The place to start is a function of problems an organization is experiencing and capabilities of the organization.  The best place to start is by picking a practice (one that solves a real problem), write stories, make the change, get feedback, and then continue to make changes. Use a series of small steps to make progress quickly. Demonstrating results will provide the organization with the motivation to pursue the next step and the next.   

Chapter 9: Corollary Practices

The corollary practices build on primary practices introduced Chapter 7.  From the perspective of the degree of difficulty, the corollary practices are more difficult and require a solid understanding of the values, principles, and primary practices to safely implement.  The corollary practices are:

  • Real customer involvement – Beck suggests making the business people affected by the system part of the team. While we today we would recognize this practice in the product owner role and in the Agile Manifesto, at the time this was a fairly radical concept.  As a further note, involving real customers is difficult in many organizations.  Beck states (and I wholeheartedly agree), that not involving a real customer at all or a proxy for the real customer will lead to waste.
  • Incremental deployment – Big bang deployment have a high risk of failure or lesser problems.  Big failure translates into the potential for high economic costs. Develop and deploy in smaller pieces in order to limit risk and get early feedback.  (Does this remind you of a principle in the Agile Manifesto?)
  • Team continuity – Simply put, keep effective teams together. Keeping effective teams together increase the reliance of teams when they encounter problems and increases both productivity and quality.
  • Shrinking teams – As a team becomes more capable keep the workload steady and reduce the size of the team.  This is one of the most radical of the corollary practices.  The reduction in team size acts as a constraint that puts steady pressure on the team to increase its capability.
  • Root cause analysis – When a team finds a defect after development they should fix the problem and then eliminate the cause. The goal of this practices is to make sure the same kind of mistake does not happen again. In XP terms, when a defect is encountered: write an automated test, fix the system so the automated unit test works, then figure out why the defect was created and wasn’t caught.
  • Shared code – The team owns the code. In scenarios where there is common ownership of the code, anyone on the team can improve any part of the system at any time. In order for this practice to work the team must develop a strong sense of collective responsibility.  Without a feeling of responsibility, quality will deteriorate.
  • Code and tests – Maintain the code and tests as the only permanent artifacts. Eliminating obsolete artifacts provides space for improvement.
  • Single Code Base – Allow only one code base.  If you need to create a separate branch make sure it is only temporary (temporary means that it lasts only a few hours).  Multiple code streams are a potent source of potential problems and time sinks.  Once upon a time, a team I managed maintained seven unique branches of a file maintenance system.  Every time we found a defect in one branch we had to update six other (or at least do the analysis). Three weekends, 12 pizzas and a lot of caffeine later we had one code base.
  • Daily Deployment – Deploy completed / tested code every night so that you get feedback on how the code operates in production. Shifting to Daily deployment is hard and requires planning so that functionality can be implemented if the customers are not ready.
  • Negotiated Scope Contract – Agree on work based on fixed times, cost and quality BUT renegotiate scope on a periodic basis.  This practice is reflected in the basic Agile thinking that fixes time (time boxes) and cost (stable team size) but assumes that scope will vary based on the businesses needs and problems encountered by the team.
  • Pay-Per-Use – Implement a pay-per-use or subscription approach to the software you developing or supporting as a mechanism to facilitate tangible feedback.  The marketplace (internal or external) provides more feedback than you can get from a customer satisfaction survey

I would suggest that when considering implementing XP begin with the primary practice that solves the highest priority problem.  Implement the practices of XP by using XP.  Write stories, make the change, measure and observe the results and then tweak the process.  Rinse and repeat until you can not longer improve (there is always room for improvement!)  

 

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  

 


Categories: Process Management

Four Types of Defect Measures Useful During Development

Bug Case

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:

  1. Defect Density is a measure of how many defects are in (typically found) in a piece of software during a defined period of development divided by the size of the module. This metric can be used before delivery. The metric is presented as a ratio. Defect density is typically used to the reflection of structural quality.
  2. Defect Discovery Rate is a count of the number of defects being discovered over time. Discovery rates tend to follow common patterns, for example in most cases more defects are found the first time a piece of code is tested than later in the development process.  Discover rates can be used to assess all aspects of software quality depending on the type of testing. Discovery rates for user acceptance testing or formal delivery tests are a reflection of functional quality while discovery rates for unit and integration tests can be used to provide information on structural quality.
  3. Cumulative Discovered Defects is the number of defects discovered for a specific piece of software, release or project is summed up and presented over a period of time. The time increments used are typically a reflection of the type of work being done. I have seen large real-time systems using automated testing show cumulative discovered defect charts minute by minute.  A classic pattern seen in cumulative discovered defect charts is the S-curve.  In an S-Curve, the number of defects discovered accumulates quickly in the middle of the testing or reviews and then tapers off when testing is complete or nearly complete.  If the rate of discovery does not taper off a problem exists.  Cumulative Discovered Defect metrics are related to discovery rate metrics. This category of defect measures are often used real time during the development process and are generally used to assess structural quality.
  4. Defect Counts by Type are counts of defects by type. This type of defect measure can be used to monitor process, structure or functional aspects of quality depending on when data on defects is collected AND the taxonomy used to categorize defects.  This simple measure is almost always the starting point for other defect measures.  The simplicity of this measure makes it easy to start and stop.  For example, I have seen a team diagnosis a process problem in a retrospective and then collect data for a few sprints to validate the problem and then the fix.

In all cases, some work needs to be completed before defect data can be collected however data collection does not have to wait until the software is implemented in production.  These measures are most valuable during the development process.


Categories: Process Management

Cracking the Code Interview

From the Editor of Methods & Tools - Wed, 07/13/2016 - 14:03
Software development interviews are a different breed from other interviews and, as such, require specialized skills and techniques. This talk will teach you how to prepare for coding interviews, what top companies like Google, Amazon, and Microsoft really look for, and how to tackle the toughest programming and algorithm problems. This is not a fluffy […]

Five Reasons Quality Is Important

27805520612_494643575a_k

Software quality is a nuanced concept that requires a framework that addresses functional, structural and the process of the software delivery process to understand.  Each of these three aspects contribute to the quality of the software being delivered therefore have to be observed and analyzed. Measurement of each aspect is a key tool for understanding whether we are delivering a quality product and whether our efforts to improve quality are having the intended impact. Balancing the effort required to measure quality requires understanding the reasons for measuring quality.  Five of reasons quality is important to measure include:

  1. Safety – Poor quality in software can be hazardous to human life and safety. Quality problems can impact the functionality of the software products we are building. Jon Quigley discussed the impact of configuration defects that effected safety in SPaMCAST 346. 
  2. Cost – Simply put, quality issues cost money to fix.  Whether you believe that a defect is 100x more costly to fix late in the development cycle or not, doing work over because it is defective does not deliver more value than doing it right once.
  3. Customer Satisfaction (internal) – Poor quality leads stakeholders to look for someone else to do your job or perhaps shipping your job and all your friend’s jobs somewhere else.  Recognize that the stakeholders experience as the software is being developed, tested and implemented is just as critical as the raw number of defects.     
  4. Customer Satisfaction (external) – Software products that don’t work, are hard to use (when they don’t need to be), or are buggy don’t tend not to last long in the marketplace.  Remember that in today’s social media driven world every complaint that gets online has a ripple effect.  Our goal should be to avoid problems that can be avoided.
  5. Future Value – Avoiding quality problems increases the amount of time available for the next project or the next set of features.  Increasing quality also improves team morale, improved team morale is directly correlated with increased productivity (which will increase customer satisfaction and reduce cost).  

In October 2015 Forbes predicted the Top Ten CIO Concerns for 2016, the list is littered with words and phrases like ‘alignment with the business’, ‘time-to-market’, ‘productivity’, and ‘efficiency’. While I am cherry picking a bit, the broad definition of quality that includes functional, structural and process aspects is ABSOLUTELY at the core of the value quality delivers.  Because quality is so important measuring quality has become a passionate topic in many organizations.  There are lots of reasons to measure quality but one major reason is to find a lever to improve quality.  The problem with the passion for measuring quality is that there are a huge number of measures and metrics that people have tried, learned from, and possibly abandoned because they have not learned from them.  Almost every measure and metric used to understand quality meets a specific need making the decision of which set of measures to use requires matching business needs with your stomach for measurement.  We will begin that discussion next. 

May I ask a favor?   I am pitching a presentation and exercise for Agile DC 2016.  Can you click the link, read the abstract and if you would like me to do the session “like” (click the heart).  The link is:

https://confengine.com/agiledc-2016/cagley

Note:  We will circle back to complete the discussion of how Agile fares in a world full of moral hazards in two weeks.


Categories: Process Management

SPaMCAST 402 – Ulises Torres, Benefits of CMMI and Agile Together

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 402 features our interview with Ulises Torres.  Ulises and I talked about how his firm, Intellego, has leveraged Agile and the CMMI to improve quality, increase customer satisfaction and business. Ulises makes a strong argument that for his company, Agile and the CMMI are better together.

Ulises Torres has over 24 years of experience in IT, either as a Developer, Team Leader, Project Manager or as an Architect, analyzing, designing, building and implementing a large number of applications, mainly with regard to retail, manufacturing, logistics/distribution and financials.  He has worked in software factories, running different projects at the same time and has formal training and proficiency in QA, Scrum, Lean Kanban, Six sigma, OOP, UML, RUP,  CMMI and PMI frameworks.

Ulises work at Intellego, a development of solutions and information management services company with offices in MĂ©xico, Chile, Colombia, Brazil, PerĂş, and USA.

Contact Information:

Email: utorres@intellego.com.mx

Web: http://www.grupointellego.com/en/the-company/
http://www.grupointellego.com/la-compania/

Re-Read Saturday News

This week we continue the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 6 and 7.  Practices, Beck notes represent endpoints that need to be pursued using “baby steps” but they are at the core of how we practice XP. 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 our essay on Agile practices at scale. We will also have a visit from the Software Sensei Kim Pries and Gene Hughson will bring his Form Follows Function Blog to the Software Process and Measurement Cast.  

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 402 - Ulises Torres, Benefits of CMMI and Agile Together

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

The Software Process and Measurement Cast 402 features our interview with Ulises Torres.  Ulises and I talked about how his firm, Intellego, has leveraged Agile and the CMMI to improve quality, increase customer satisfaction and business. Ulises makes a strong argument that for his company, Agile and the CMMI are better together.

Ulises Torres has over 24 years of experience in IT, either as a Developer, Team Leader, Project Manager or as an Architect, analyzing, designing, building and implementing a large number of applications, mainly with regard to retail, manufacturing, logistics/distribution and financials.  He has worked in software factories, running different projects at the same time and has formal training and proficiency in QA, Scrum, Lean Kanban, Six sigma, OOP, UML, RUP,  CMMI and PMI frameworks.

Ulises work at Intellego, a development of solutions and information management services company with offices in México,Chile, Colombia, Brazil, Perú, and USA.

Contact Information:

Email: utorres@intellego.com.mx

Web: http://www.grupointellego.com/en/the-company/ o http://www.grupointellego.com/la-compania/

 

Re-Read Saturday News

This week we continue the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 6 and 7.  Practices, Beck notes represent endpoints that need to be pursued using “baby steps” but they are at the core of how we practice XP. 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 our essay on Agile practices at scale (Meg 2/23, 2/25 3/1 and 3/2 … others?). We will also have a visit from the Software Sensei Kim Pries and Gene Hughson will bring his Form Follows Function Blog to the Software Process and Measurement Cast.  

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