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.

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

Extreme Programming Explained, Second Edition: Week 4

XP Explained

This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters six and seven in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapters six and seven explore the practices that operationalize the values and practices we have explored in previous installments.

Chapter 6: Practices

Practices are the mechanism for applying an idea or method.  While values and principles provide the why, practices deliver the how.  In Chapter 3 we described the relationship as a bridge between two cliffs; values on one side, principles as the bridge and practices on the other side. Linking practices through principles to values is a nice metaphor to illustrate that all three components are needed to ensure that practices don’t become rote and lose value.

Chapter six provides a transition from the high level to the pragmatic. ¬†In this chapter, Beck notes that the practices represent endpoints that need to be pursued using “baby steps‚ÄĚ (one of the principles we identified in chapter 5). XP, like most other methodologies, provides the most value if all of the practices are practiced together; however, teams and organizations implementing XP can get value by implementing the practices one at a time.

Chapter 7: Primary Practices

The primary practices are the foundation of XP.  The primary practices are not the whole of XP, Chapter 9 builds on this foundation introduced in Chapter 7 with corollary practices.  The primary practices are:

  1.      Sit together.  Sitting together helps people interact and work together. Death to cube farms that keep people apart.  Teams need both a collaborative space so they can talk and interact and private space so that individuals can focus when needed.  This simple practice is one of the most difficult for most organizations.  Distributed teams can’t sit together, and even when teams are collocated it is difficult to find the right balance between togetherness and alone time. Creeping up on getting people to sit together (Beck’s words) is a good idea so that teams can find the right balance.  Recognize that the balance can change based on team composition and the type of work being tackled.
  2.      Whole team. Use cross-functional teams that include all the skills and perspectives necessary for the project to succeed. Recognize that the definition of what constitutes the whole team is dynamic. Teams in XP include whole people; fractional people are a bad idea because of the huge productivity penalty caused by task switching.
  3.      Informative workspace. The workspace is not just a shell to hold people, but should also be part of telling the story of the work to the stakeholders and the team members. Story cards hung on the walls, lists of team norms and other big information radiators show the team’s goals and their progress.
  4. ¬†¬†¬†¬†¬†Energized work- Team members should work as many hours as they can be productive and only as many as can be consistently sustained. ¬†During one stretch of my career, I worked 80 or more hours a week to keep up with a colleague nicknamed DEFCON Don (he was an ex-missileer).While the competition was fun, I am not sure our productivity was as high as it could have been if we work a more reasonable schedule. Beck puts it succinctly, 

    “Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”

  5.      Pair programming. Pair programming is easily one of the most controversial practices in XP.  The practice of pair programming occurs when two people and one keyboard collaborate on programming.  Typically one person talks and watches while the other types, rotating roles frequently.  This practice can be useful for most any function including analysis, design, and testing. When pairing, rotate pairs frequently, respect culture, personal space, respect personal hygiene rules and don’t pair if you have the flu!
  6.      Stories. Plan work using user stories, which are units of customer-visible functionality. The concept of the user story shifts the discussion of needs away from the permanence and obligatory nature of the word requirement. Estimate user stories as soon as they are written to provide the business and technical perspectives a chance to interact while the story is still top of mind. User stories have migrated into almost every Agile implementation.
  7.      Weekly cycle. XP suggests planning work a week at a time. While Scrum has settled roughly on a two-week cycle, XP recommends re-planning every week.   The use of a single week ensures that teams break work into small chunks and generate feedback quickly.  XP’s work cycle begins by writing tests followed by coding and finally running the tests to prove the solution.  The cycle repeats until the tests are passed.  XP introduced the concept of the planning meeting now used in Scrum. The weekly heartbeat gives you a convenient, frequent and predictable platform.
  8.      Quarterly cycle. Plan work a quarter at a time. The quarterly cycle allows the team to reflect and consider the big picture so they stay aligned with larger organizational or program goals.  The quarterly cycle is very much akin to the planning increment in SAFe.
  9.      Slack. Teams require slack to deal with issues that will invariably pop up.  Overcommitment causes waste as teams are stressed to make up time by pushing too hard or cutting corners.  The innovation sprint in SAFe is an example of planning slack into the process.
  10.  10-minute build. Build the whole system and run all of the tests in 10 minutes. The concept of the 10-minute build is that builds that take substantially longer will be done less often, reducing the chance for feedback.
  11.  Continuous integration. Integrate all changes into the whole application after no more than a couple of hours. Continuous integration provides feedback to prove that the system works. Beck recommends using synchronous builds in which all team members commit their code to the build at specific times.  The build is then tested, and if it passes coding begins anew (if not, a fix is needed).  Teams often begin with asynchronous builds because they require less coordination and then evolve to synchronous builds.
  12.  Test-first programming. Test-first programming is a powerful practice that begins by writing the tests that the developer will use to prove they have solved the business problem.  Test-first programming reduces scope creep, increases technical cohesion, trust, and rhythm. I have found that test-first development also helps to ensure that testers, business analysts, and developers collaborate.
  13.  Incremental design. Invest in the design every day using the knowledge that was gained the previous day as a mechanism, so the design continually evolves based on need. Incremental design is a form of real options theory.  Making small decisions helps reduce the cost of change and allows decisions to be made closer to the point of need.

The 13 primary practices provide the foundation for the practice of XP.  Even if an organization is not practicing XP, many of the primary practices are used to augment less technical Agile frameworks, such as Scrum.

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 

 


Categories: Process Management

Some Moral Hazards In Software Development

25259400413_7f9d5063dc_k

Too big to fail?

Moral hazards occur when the potential outcome of taking a risk is disassociated from who will bear the cost of a risk. ¬†Moral hazard is often caused by information asymmetry; the risk taker has more information than the person or organization that will bear the cost of a risk. Even though we assume in many cases perfect information or harp on the need for communication, information asymmetry is a common occurrence. Too big to fail is a form of moral hazard in which the organization may take larger risks with the potential the larger returns because they know they will not be allowed to fail. Another example of a scenario that can lead to a moral hazard is the principal‚Äďagent relationship. In the principal-agent relationship, the agent generally has more information than the principal. In this scenario, the principal can not spend all of his or her time monitoring the agent so that they have complementary or the same amount of information. There has to be a relationship of trust. In some scenarios, the agent might have the incentive to act inappropriately by taking more risk than the principal might deem appropriate. For example, the project manager position can often be construed as an agent-principal relationship. There are times that I’ve seen where a project manager who is behind will curtail testing so that they can catch up and deliver on time. This is a moral hazard.

There are numerous moral hazards that can occur in the software development and maintenance environments. Some of the scenarios that generate the potential for significant moral hazards are:

Too Important to Fail Projects: Information technology is littered with projects that are too important to fail. Participants on projects that are too big or too important to fail could assume that someone will step in if the project gets into trouble. For example, I have personally been involved with bank mergers with announced cutover dates multiple times in my career. ¬†If those dates were not met everything from the organization’s stock to the management team would have been sunk. I saw evidence of the impact of a missed date when a merger cutover had to be postponed due to an external event; the stock of both organizations plunged 50% in two days and the CIO and his staff were gone in less than 30 days. On more than one occasion decisions were made to beg for more resources or cut corners to make the dates when times got tough.

Software Teams Insulated From Business Risk: In many organizations, requirements are developed and provided by the business.  The requirements or user stories are provided to a development team as a transaction.  Once the team obtains the requirements they begin the process of development.  Because requirements are viewed as a transaction the team falls into a principal-agent trap where there is asymmetry in information.  The team can’t easily link their development knowledge with business risk.

Specialization: Separating some types of related work can generate the potential for moral hazard. In many organizations, development and maintenance functions are staffed separately.  The software is developed and then tossed over the wall to the maintenance personnel. In scenarios in which developers are not responsible for fixing defects, they may take shortcuts which benefit development, but not maintenance.  A similar argument can be made for separating planning and estimating from development functions.

The financial crisis of the last decade can be traced at least partially to information asymmetry and moral hazard. Innovations or continuous changes can impact information asymmetry.  Concepts such as Scrum can level the information playing field by embedding the business in day-to-day project decision making.  However, when non-business proxy product owners are substituted we end up back in the same position of potential moral hazard.

Next: Impact of Agile on Moral Hazards


Categories: Process Management

Moral Licensing and Process Change

 Offering a feast of carrot sticks instead of chocolate chip cookies as a reward for committing to diet is probably not going to be well received.

Offering a feast of carrot sticks instead of chocolate chip cookies as a reward for committing to diet is probably not going to be well received.

Moral licensing is when¬†doing something that improves or strengthens our positive self-image makes us worry less about the implications of another ‚Äúimmoral‚ÄĚ behavior. This makes it more likely that we make ‚Äúimmoral‚ÄĚ choices. When discussing software development the word ‘immoral’ could be construed as over the top.¬† A better term might be overly convenient, ad-hoc or perhaps undisciplined.¬† An¬†understanding¬†of moral licensing is important. ¬†As change agents we are often have to understand¬†behavior so we can help teams and organizations deliver more value.¬†¬†For example¬†in some cases, it might be possible to confuse moral licensing with passive aggressive behavior. ¬†The remedies these different kinds of behavior are very different. Moral licensing is a real problem that that can disrupt progress in an agile transformation (or any other behavior change).

How many times have¬†you heard ‚ÄúI will reach out to the business and solicit a product owner for our next sprint; however for now . . .‚ÄĚ And then watched as a proxy product owner was assigned rather than someone from the business.¬†You can substitute, ‚Äúwe will start doing stand-up meetings tomorrow; however those meeting begin with¬†management assigning tasks‚ÄĚ or any number of long litany of good choices followed by a poor process choice. If we think of this a form of unconscious accounting, making the right choice provides positive capital, making it possible to spend some of that capital.¬† This is the same behavior you may have experienced the last time you made a New Year‚Äôs Resolution.¬† Have you ever committed to losing weight, to exercise or sleep more in the New Year but before starting went to one more big party or pulled one last all-nighter? ¬†Moral licensing is a bit of mental gymnastics that provides the mental cover for those choices.¬† Any act or promise to act¬†that is perceived to be ‚Äúgood,‚Ä̬† ‚Äúdisciplined,‚ÄĚ or ‚Äúmoral‚ÄĚ can license can illicit the feeling that a reward for being so righteous is deserved.

Wrestling with moral licensing in Agile or process changes begins with removing the good/ bad labels so that behavior/reward cycle is not triggered.  A second potential solution is to provide a set of choices that are all acceptable to help guide progress. This option can seem a bit manipulative if the pallet of choices are shallow or condescending.  Offering a feast of carrot sticks instead of chocolate chip cookies as a reward for committing to diet is probably not going to be well received.  A third choice for muting the possible impact of moral licensing is coaching. Coaches can help bring the choices that are being made out into the light so that practitioners consider their choices and the value of each.  In the end, we would like those we are helping to transform to not have to make choices between doing a stand-up or not doing a stand-up or between having a product owner from the business or a casual stand-in from the development team. 


Categories: Process Management

The 2 Things You Need to Do in Daily Scrums to End Complaints

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

You have undoubtedly had team members complain at some point about the length of your daily scrums. Join the club.

I want to share two extremely simple things you can do to put an end to most of those complaints. (I can’t promise getting rid of all complaints—some people will always complain.)

Because of the Scrum guideline that a daily scrum is not to be used for problem solving, many Scrum Masters will note the problem during the daily scrum and then discuss it immediately afterwards.

For example, if two hot issues are mentioned during the daily scrum, the Scrum Master might stop discussion of those topics. The Scrum Master will then bring the two topics back up after everyone has first had a chance to address the three questions of the daily scrum.

This leads to the team being there for longer than the standard timebox of 15 minutes for a daily scrum.

The first thing you should do is to end every daily scrum by announcing how long the meeting took. Do this right after everyone has addressed the three questions and before switching into problem-solving mode.

You might, for example, announce, “Thanks everyone. That took twelve minutes.”

But then, remind everyone of any problems or issues that were brought up. Suggest that those who are needed stay to discuss or resolve them. If possible, facilitate the team splitting into more than one subgroup if more than one issue needs to be discussed.

Then, do the second thing that helps end complaints about the length of the daily scrum: Announce that those who are not needed to resolve any of the issues being discussed can leave.

By taking these two actions:

1. Calling the daily scrum officially over and announcing how many minutes it took; and,

2. Telling team members who are not needed for further discussions that they can leave

You will help team members from feeling that the daily scrum is exceeding its 15-minute timebox.

What Do You Think?

What have you done to eliminate complaints about the daily scrum? How have you helped your team see the value of this meeting? Please share your thoughts in the comments below.

SPaMCAST 401 ‚Äď Listening, Quality, Testing and Contract Closure, Developers and Testing

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 401 features three columns!  We begin with our essay on listening.  Every time we answer the phone, interact with a co-worker or even turn on the television we need to hear and interpret the messages that are being sent. Our complicated business and life environments impact how we listen through the situations we face. Listening is important. Like reading, it is fundamental to almost every activity needed to build, enhance or maintain a product; therefore, learning and understanding how to listen, and as importantly how not to listen, are table stakes for getting anything done!

Jon M. Quigley’s second column discusses the topic of cost, quality, testing and contract closure. All of the parts of a product have to fit together for everyone to feel comfortable and pay the bill!

Jeremy Berriault and the QA Corner anchor the cast.  I asked Jeremy to talk about whether developers should test.  (Don’t tell anyone, but the answer is HECK YES.)

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 4 and 5.  We do a deep dive into values and principles.  Values and principles are the basis for all of the practices we will explore as we read.  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 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.  

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 401 - Listening, Quality, Testing and Contract Closure, Developers and Testing

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

The Software Process and Measurement Cast 401 features three columns!  We begin with our essay on listening.  Every time we answer the phone, interact with a co-worker or even turn on the television we need to hear and interpret the messages that are being sent. Our complicated business and life environments impact how we listen through the situations we face. Listening is important. Like reading, it is fundamental to almost every activity needed to build, enhance or maintain a product; therefore, learning and understanding how to listen, and as importantly how not to listen, are table stakes for getting anything done!

Jon M. Quigley’s second column discusses the topic of cost, quality, testing and contract closure. All of the parts of a product have to fit together for everyone to feel comfortable and pay the bill!

Jeremy Berriault and the QA Corner anchor the cast.  I asked Jeremy to talk about whether developers should test.  (Don’t tell anyone, but the answer is HECK YES.)

 

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 4 and 5.  We do a deep dive into values and principles.  Values and principles are the basis for all of the practices we will explore as we read.  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 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.  

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

Verbal Aikido for Product Managers

Xebia Blog - Sun, 07/03/2016 - 13:41
"Well eh ok, I guess so" mumbled the student in the training exercise where he was practicing how to say no to feature gluttony. I decided to give the class an additional exercise to awaken their inner diplomat. “Diplomacy is the art of telling people to go to hell in such a way that they