şÝşÝߣshows by User: hdeiner / http://www.slideshare.net/images/logo.gif şÝşÝߣshows by User: hdeiner / Fri, 15 Mar 2019 20:23:18 GMT şÝşÝߣShare feed for şÝşÝߣshows by User: hdeiner Synchronous vs Asynchronous Digital Circuits as an Analogy to Organizational Dysfunction Applied to DevOps Practices /hdeiner/synchronous-vs-asynchronous-digital-circuits-as-an-analogy-to-organizational-dysfunction-applied-to-devops-practices howarddeiner-devopsproeurope2019-synchronousvsasynchronousdigitalcircuitsasananalogytoorganizational-190315202318
Digital circuits, including the ones that we use for modern day computers, rely on digital electronics. That just means that they work because of a particular voltage being present to mean a one and the lack of a voltage to mean a zero. It’s how we build circuits together to transform an input into an output, with all of the circuits and programs to run on those circuits (in a von Neumann computer) that makes computers useful. But when designing these circuits, one basic design question to answer is “should I use a clock or not (synchronous vs asynchronous)?” While synchronous circuits are easier to design, asynchronous circuits have many advantages, such as high performance. Let me mapping this concept onto organization dysfunction. As a coach, I can tell within 5 minutes of meeting a client how well the organization will do when attempting to become more Agile through reductions in Lean Wastes by adopting some Software Craftsmanship and DevOps practices and principles. How can I tell? Easy. I look at their calendaring tools. When I see a person’s email box full of calendar requests and a calendar that resembles a paved driveway, I know immediately that we will have a lot of problems. On the other hand, when the corporate culture embraces true one-on-one collaboration, with few meetings, I know that we’re going to get on together just fine. As an organization if we want to make progress on work to be done, we have a choice to make. We can either be asynchronous by collaborating together and getting stuff done, or we can take the route that has be drummed into everyone’s head over the last 159 years: we can hold meetings. Unhappily, the more we rely on meetings as the primary way of making progress, the less we get done because of waiting and coordination wastes. This talk will discuss the underlying analogy more in depth, apply it to organizations we are familiar with, and discuss the proper role for meetings in an organization. It will then turn its attention to how DevOps in general and virtualization/containerization in particular allows us to be more asynchronous as an organization, and therefore much quicker and less wasteful.]]>
Digital circuits, including the ones that we use for modern day computers, rely on digital electronics. That just means that they work because of a particular voltage being present to mean a one and the lack of a voltage to mean a zero. It’s how we build circuits together to transform an input into an output, with all of the circuits and programs to run on those circuits (in a von Neumann computer) that makes computers useful. But when designing these circuits, one basic design question to answer is “should I use a clock or not (synchronous vs asynchronous)?” While synchronous circuits are easier to design, asynchronous circuits have many advantages, such as high performance. Let me mapping this concept onto organization dysfunction. As a coach, I can tell within 5 minutes of meeting a client how well the organization will do when attempting to become more Agile through reductions in Lean Wastes by adopting some Software Craftsmanship and DevOps practices and principles. How can I tell? Easy. I look at their calendaring tools. When I see a person’s email box full of calendar requests and a calendar that resembles a paved driveway, I know immediately that we will have a lot of problems. On the other hand, when the corporate culture embraces true one-on-one collaboration, with few meetings, I know that we’re going to get on together just fine. As an organization if we want to make progress on work to be done, we have a choice to make. We can either be asynchronous by collaborating together and getting stuff done, or we can take the route that has be drummed into everyone’s head over the last 159 years: we can hold meetings. Unhappily, the more we rely on meetings as the primary way of making progress, the less we get done because of waiting and coordination wastes. This talk will discuss the underlying analogy more in depth, apply it to organizations we are familiar with, and discuss the proper role for meetings in an organization. It will then turn its attention to how DevOps in general and virtualization/containerization in particular allows us to be more asynchronous as an organization, and therefore much quicker and less wasteful.]]> Fri, 15 Mar 2019 20:23:18 GMT /hdeiner/synchronous-vs-asynchronous-digital-circuits-as-an-analogy-to-organizational-dysfunction-applied-to-devops-practices hdeiner@slideshare.net(hdeiner) Synchronous vs Asynchronous Digital Circuits as an Analogy to Organizational Dysfunction Applied to DevOps Practices hdeiner Digital circuits, including the ones that we use for modern day computers, rely on digital electronics. That just means that they work because of a particular voltage being present to mean a one and the lack of a voltage to mean a zero. It’s how we build circuits together to transform an input into an output, with all of the circuits and programs to run on those circuits (in a von Neumann computer) that makes computers useful. But when designing these circuits, one basic design question to answer is “should I use a clock or not (synchronous vs asynchronous)?” While synchronous circuits are easier to design, asynchronous circuits have many advantages, such as high performance. Let me mapping this concept onto organization dysfunction. As a coach, I can tell within 5 minutes of meeting a client how well the organization will do when attempting to become more Agile through reductions in Lean Wastes by adopting some Software Craftsmanship and DevOps practices and principles. How can I tell? Easy. I look at their calendaring tools. When I see a person’s email box full of calendar requests and a calendar that resembles a paved driveway, I know immediately that we will have a lot of problems. On the other hand, when the corporate culture embraces true one-on-one collaboration, with few meetings, I know that we’re going to get on together just fine. As an organization if we want to make progress on work to be done, we have a choice to make. We can either be asynchronous by collaborating together and getting stuff done, or we can take the route that has be drummed into everyone’s head over the last 159 years: we can hold meetings. Unhappily, the more we rely on meetings as the primary way of making progress, the less we get done because of waiting and coordination wastes. This talk will discuss the underlying analogy more in depth, apply it to organizations we are familiar with, and discuss the proper role for meetings in an organization. It will then turn its attention to how DevOps in general and virtualization/containerization in particular allows us to be more asynchronous as an organization, and therefore much quicker and less wasteful. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-synchronousvsasynchronousdigitalcircuitsasananalogytoorganizational-190315202318-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Digital circuits, including the ones that we use for modern day computers, rely on digital electronics. That just means that they work because of a particular voltage being present to mean a one and the lack of a voltage to mean a zero. It’s how we build circuits together to transform an input into an output, with all of the circuits and programs to run on those circuits (in a von Neumann computer) that makes computers useful. But when designing these circuits, one basic design question to answer is “should I use a clock or not (synchronous vs asynchronous)?” While synchronous circuits are easier to design, asynchronous circuits have many advantages, such as high performance. Let me mapping this concept onto organization dysfunction. As a coach, I can tell within 5 minutes of meeting a client how well the organization will do when attempting to become more Agile through reductions in Lean Wastes by adopting some Software Craftsmanship and DevOps practices and principles. How can I tell? Easy. I look at their calendaring tools. When I see a person’s email box full of calendar requests and a calendar that resembles a paved driveway, I know immediately that we will have a lot of problems. On the other hand, when the corporate culture embraces true one-on-one collaboration, with few meetings, I know that we’re going to get on together just fine. As an organization if we want to make progress on work to be done, we have a choice to make. We can either be asynchronous by collaborating together and getting stuff done, or we can take the route that has be drummed into everyone’s head over the last 159 years: we can hold meetings. Unhappily, the more we rely on meetings as the primary way of making progress, the less we get done because of waiting and coordination wastes. This talk will discuss the underlying analogy more in depth, apply it to organizations we are familiar with, and discuss the proper role for meetings in an organization. It will then turn its attention to how DevOps in general and virtualization/containerization in particular allows us to be more asynchronous as an organization, and therefore much quicker and less wasteful.
Synchronous vs Asynchronous Digital Circuits as an Analogy to Organizational Dysfunction Applied to DevOps Practices from Howard Deiner
]]> 178 1 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-synchronousvsasynchronousdigitalcircuitsasananalogytoorganizational-190315202318-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Pivoting a Company Towards GitOps and Continuous Delivery - A Technical Practices Coach's Tale for the Misbegotten /slideshow/pivoting-a-company-towards-gitops-and-continuous-delivery-a-technical-practices-coachs-tale-for-the-misbegotten/136625242 howarddeiner-devopsproeurope2019-pivotingacompanytowardsgitopsandcontinuousdelivery-190315201936
This talk is an amalgam of observations, opinions, findings, and musings from a Agile Technical Practices Coach working for an organization that struggles as it fights to change from a more traditional 20th century IT organization that services contract promises into a 21st century product organization that excites and delights their segment and channels. Your narrator has had a long term relationship with this compony and has coached them on topics varying from adopting an Agile/Lean mindset, organizational staffing models, product strategy, coding and testing practices, architectural concerns, wedding and bar mitzvah advice, and now into the world of how to achieve Continuous Delivery of quality product. One central theme is that there is that a coach must act holistically, taking into account that both customs, culture, philosophy, and practices all compete in the wicked problem of pivoting the organization into a more modern and “Agilely Fluent” organization. Specific topics will come from the following (and without regard for “terminology correctness”as judged by the Agility Police): * Requirements gathering * Planning * Development environment * Development infrastructure * Coding practices * Testing practices * Developing a learning organization * Production infrastructure and workflow Each topic will illustrate the problems faced by the organization (and the coach’s experience of how their woes fit into patterns of problems that the coach has seen elsewhere), the coach’s vision of what would be a good outcome, steps along the way, and illustrative reactions from the organization to the change. The overarching message is that you must coach the organization at where they are, who they are, and what they do, regardless of your preconceived thoughts of what you’d like them to be and do. In other words, as a coach while you might know that X is a great way to accomplish Y, you must accept that not everyone is ready to do X, is capable of doing X, or even sees that Y is a good thing! If this talk alleviates another coach’s or organization’s pain and anxiety adopting better ways of approaching work, then I will consider it a good use of our time.]]>
This talk is an amalgam of observations, opinions, findings, and musings from a Agile Technical Practices Coach working for an organization that struggles as it fights to change from a more traditional 20th century IT organization that services contract promises into a 21st century product organization that excites and delights their segment and channels. Your narrator has had a long term relationship with this compony and has coached them on topics varying from adopting an Agile/Lean mindset, organizational staffing models, product strategy, coding and testing practices, architectural concerns, wedding and bar mitzvah advice, and now into the world of how to achieve Continuous Delivery of quality product. One central theme is that there is that a coach must act holistically, taking into account that both customs, culture, philosophy, and practices all compete in the wicked problem of pivoting the organization into a more modern and “Agilely Fluent” organization. Specific topics will come from the following (and without regard for “terminology correctness”as judged by the Agility Police): * Requirements gathering * Planning * Development environment * Development infrastructure * Coding practices * Testing practices * Developing a learning organization * Production infrastructure and workflow Each topic will illustrate the problems faced by the organization (and the coach’s experience of how their woes fit into patterns of problems that the coach has seen elsewhere), the coach’s vision of what would be a good outcome, steps along the way, and illustrative reactions from the organization to the change. The overarching message is that you must coach the organization at where they are, who they are, and what they do, regardless of your preconceived thoughts of what you’d like them to be and do. In other words, as a coach while you might know that X is a great way to accomplish Y, you must accept that not everyone is ready to do X, is capable of doing X, or even sees that Y is a good thing! If this talk alleviates another coach’s or organization’s pain and anxiety adopting better ways of approaching work, then I will consider it a good use of our time.]]> Fri, 15 Mar 2019 20:19:36 GMT /slideshow/pivoting-a-company-towards-gitops-and-continuous-delivery-a-technical-practices-coachs-tale-for-the-misbegotten/136625242 hdeiner@slideshare.net(hdeiner) Pivoting a Company Towards GitOps and Continuous Delivery - A Technical Practices Coach's Tale for the Misbegotten hdeiner This talk is an amalgam of observations, opinions, findings, and musings from a Agile Technical Practices Coach working for an organization that struggles as it fights to change from a more traditional 20th century IT organization that services contract promises into a 21st century product organization that excites and delights their segment and channels. Your narrator has had a long term relationship with this compony and has coached them on topics varying from adopting an Agile/Lean mindset, organizational staffing models, product strategy, coding and testing practices, architectural concerns, wedding and bar mitzvah advice, and now into the world of how to achieve Continuous Delivery of quality product. One central theme is that there is that a coach must act holistically, taking into account that both customs, culture, philosophy, and practices all compete in the wicked problem of pivoting the organization into a more modern and “Agilely Fluent” organization. Specific topics will come from the following (and without regard for “terminology correctness”as judged by the Agility Police): * Requirements gathering * Planning * Development environment * Development infrastructure * Coding practices * Testing practices * Developing a learning organization * Production infrastructure and workflow Each topic will illustrate the problems faced by the organization (and the coach’s experience of how their woes fit into patterns of problems that the coach has seen elsewhere), the coach’s vision of what would be a good outcome, steps along the way, and illustrative reactions from the organization to the change. The overarching message is that you must coach the organization at where they are, who they are, and what they do, regardless of your preconceived thoughts of what you’d like them to be and do. In other words, as a coach while you might know that X is a great way to accomplish Y, you must accept that not everyone is ready to do X, is capable of doing X, or even sees that Y is a good thing! If this talk alleviates another coach’s or organization’s pain and anxiety adopting better ways of approaching work, then I will consider it a good use of our time. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-pivotingacompanytowardsgitopsandcontinuousdelivery-190315201936-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> This talk is an amalgam of observations, opinions, findings, and musings from a Agile Technical Practices Coach working for an organization that struggles as it fights to change from a more traditional 20th century IT organization that services contract promises into a 21st century product organization that excites and delights their segment and channels. Your narrator has had a long term relationship with this compony and has coached them on topics varying from adopting an Agile/Lean mindset, organizational staffing models, product strategy, coding and testing practices, architectural concerns, wedding and bar mitzvah advice, and now into the world of how to achieve Continuous Delivery of quality product. One central theme is that there is that a coach must act holistically, taking into account that both customs, culture, philosophy, and practices all compete in the wicked problem of pivoting the organization into a more modern and “Agilely Fluent” organization. Specific topics will come from the following (and without regard for “terminology correctness”as judged by the Agility Police): * Requirements gathering * Planning * Development environment * Development infrastructure * Coding practices * Testing practices * Developing a learning organization * Production infrastructure and workflow Each topic will illustrate the problems faced by the organization (and the coach’s experience of how their woes fit into patterns of problems that the coach has seen elsewhere), the coach’s vision of what would be a good outcome, steps along the way, and illustrative reactions from the organization to the change. The overarching message is that you must coach the organization at where they are, who they are, and what they do, regardless of your preconceived thoughts of what you’d like them to be and do. In other words, as a coach while you might know that X is a great way to accomplish Y, you must accept that not everyone is ready to do X, is capable of doing X, or even sees that Y is a good thing! If this talk alleviates another coach’s or organization’s pain and anxiety adopting better ways of approaching work, then I will consider it a good use of our time.
Pivoting a Company Towards GitOps and Continuous Delivery - A Technical Practices Coach's Tale for the Misbegotten from Howard Deiner
]]> 130 1 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-pivotingacompanytowardsgitopsandcontinuousdelivery-190315201936-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Improving Your Organization's Technical Prowess With Legacy Code Retreats /slideshow/improving-your-organizations-technical-prowess-with-legacy-code-retreats/81946077 howarddeiner-xpdaysukraine2017-improvingyourorganizationstechnicalprowesswithlegacycoderetreats-171112214008
In his book “Understanding the Four Rules of Simple Design”, Corey Haines is talking about good design principles and teaching us how to practice them using Code Retreats. Unhappily, many of us have to do with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. JB Rainsberger has started a variation on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to be able to use this legacy code in Java often. For this master-class, we want to learn the classic Michael Feathers dance of: 1. Identify change points 2. Find an inflection point 3. Cover the inflection point (break external dependencies, break internal dependencies, write tests) 4. Make changes 5. Refactor the covered code. We also would lay out the practicalities of having a legacy code retreat: Who comes? How should they pair? When do the pairs switch?]]>
In his book “Understanding the Four Rules of Simple Design”, Corey Haines is talking about good design principles and teaching us how to practice them using Code Retreats. Unhappily, many of us have to do with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. JB Rainsberger has started a variation on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to be able to use this legacy code in Java often. For this master-class, we want to learn the classic Michael Feathers dance of: 1. Identify change points 2. Find an inflection point 3. Cover the inflection point (break external dependencies, break internal dependencies, write tests) 4. Make changes 5. Refactor the covered code. We also would lay out the practicalities of having a legacy code retreat: Who comes? How should they pair? When do the pairs switch?]]> Sun, 12 Nov 2017 21:40:08 GMT /slideshow/improving-your-organizations-technical-prowess-with-legacy-code-retreats/81946077 hdeiner@slideshare.net(hdeiner) Improving Your Organization's Technical Prowess With Legacy Code Retreats hdeiner In his book “Understanding the Four Rules of Simple Design”, Corey Haines is talking about good design principles and teaching us how to practice them using Code Retreats. Unhappily, many of us have to do with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. JB Rainsberger has started a variation on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to be able to use this legacy code in Java often. For this master-class, we want to learn the classic Michael Feathers dance of: 1. Identify change points 2. Find an inflection point 3. Cover the inflection point (break external dependencies, break internal dependencies, write tests) 4. Make changes 5. Refactor the covered code. We also would lay out the practicalities of having a legacy code retreat: Who comes? How should they pair? When do the pairs switch? <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-xpdaysukraine2017-improvingyourorganizationstechnicalprowesswithlegacycoderetreats-171112214008-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> In his book “Understanding the Four Rules of Simple Design”, Corey Haines is talking about good design principles and teaching us how to practice them using Code Retreats. Unhappily, many of us have to do with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. JB Rainsberger has started a variation on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to be able to use this legacy code in Java often. For this master-class, we want to learn the classic Michael Feathers dance of: 1. Identify change points 2. Find an inflection point 3. Cover the inflection point (break external dependencies, break internal dependencies, write tests) 4. Make changes 5. Refactor the covered code. We also would lay out the practicalities of having a legacy code retreat: Who comes? How should they pair? When do the pairs switch?
Improving Your Organization's Technical Prowess With Legacy Code Retreats from Howard Deiner
]]> 303 1 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-xpdaysukraine2017-improvingyourorganizationstechnicalprowesswithlegacycoderetreats-171112214008-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 How We Get Agile Transformations Wrong By Trying To Do It All So Right /hdeiner/how-we-get-agile-transformations-wrong-by-trying-to-do-it-all-so-right-75916809 howwegetagiletransformationswrongbytryingtodoitallsoright-170512104027
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.]]>
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.]]> Fri, 12 May 2017 10:40:27 GMT /hdeiner/how-we-get-agile-transformations-wrong-by-trying-to-do-it-all-so-right-75916809 hdeiner@slideshare.net(hdeiner) How We Get Agile Transformations Wrong By Trying To Do It All So Right hdeiner Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howwegetagiletransformationswrongbytryingtodoitallsoright-170512104027-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.
How We Get Agile Transformations Wrong By Trying To Do It All So Right from Howard Deiner
]]> 410 3 https://cdn.slidesharecdn.com/ss_thumbnails/howwegetagiletransformationswrongbytryingtodoitallsoright-170512104027-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 How We Get Agile Transformations Wrong By Trying To Do It All So Right /slideshow/how-we-get-agile-transformations-wrong-by-trying-to-do-it-all-so-right/73212834 howwegetagiletransformationswrongbytryingtodoitallsoright-170316135807
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.]]>
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.]]> Thu, 16 Mar 2017 13:58:07 GMT /slideshow/how-we-get-agile-transformations-wrong-by-trying-to-do-it-all-so-right/73212834 hdeiner@slideshare.net(hdeiner) How We Get Agile Transformations Wrong By Trying To Do It All So Right hdeiner Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howwegetagiletransformationswrongbytryingtodoitallsoright-170316135807-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.   Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.   But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?   I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can’t logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.   This session will speak to the specifics of the whats and whys.
How We Get Agile Transformations Wrong By Trying To Do It All So Right from Howard Deiner
]]> 469 3 https://cdn.slidesharecdn.com/ss_thumbnails/howwegetagiletransformationswrongbytryingtodoitallsoright-170316135807-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 The Manifesto for Software Craftsmanship – Because Post-Its and Legos Don’t Create Better Software! /slideshow/the-manifesto-for-software-craftsmanship-because-postits-and-legos-dont-create-better-software/61111021 themanifestoforsoftwarecraftsmanshipbecausepostitsandlegosdontcreatebettersoftware-160419193016
If one were to characterise the last 60 years of software development, it would probably look something like this: 1950s-1960s: People who can program are so rare that they blaze their own trails to make things happen. They create amazing things, given the state and cost of hardware in those times. 1970s-1990s: Software development matures and becomes commonplace. Many non-developers are absorbed into large development organisations as a way to help control costs. Because of so many controls, checkers, checkers of checkers, and so on, costs spiral out of control. A desire to make software more manageable leads to a call for software engineering. 2000s-present: The Agile movement responds to the dizzying controls that the quasi-command-and-control structure of development has become with a manifesto – a call to get back to basics. To look past the waste associated with bloated software development management, and work in collaborative concert between business and development. As more and more organisations attempted to “become Agile” through transformations, some funny things happened. People started to believe that all they had to do was fix the process and the software would magically improve itself. Late adopters “got passes” from later generation Agile coaches and found ways to keep doing old bad behaviours under new names, run a few fun-filled days of trainings, and declare that the problem was fixed. And so on. There has been scant peer reviewed data that shows that any of the process changes that Agile promised actually have had any lasting value on organisations whatsoever. However, led by these same Agile coaches, we continue to believe (at least, want to believe) that good is coming out of all the work put into the transformations. A new call to arms is upon us. We of the Agile Craftsmanship community say that the only verifiable improvements that came with the Agile revolution were in eXtreme Programming, and the passion surrounding an appreciation in making great things. In this session, Howard will open your eyes to a lifetime commitment – something akin to the pride that one experienced in the guild traditions of medieval Europe.]]>
If one were to characterise the last 60 years of software development, it would probably look something like this: 1950s-1960s: People who can program are so rare that they blaze their own trails to make things happen. They create amazing things, given the state and cost of hardware in those times. 1970s-1990s: Software development matures and becomes commonplace. Many non-developers are absorbed into large development organisations as a way to help control costs. Because of so many controls, checkers, checkers of checkers, and so on, costs spiral out of control. A desire to make software more manageable leads to a call for software engineering. 2000s-present: The Agile movement responds to the dizzying controls that the quasi-command-and-control structure of development has become with a manifesto – a call to get back to basics. To look past the waste associated with bloated software development management, and work in collaborative concert between business and development. As more and more organisations attempted to “become Agile” through transformations, some funny things happened. People started to believe that all they had to do was fix the process and the software would magically improve itself. Late adopters “got passes” from later generation Agile coaches and found ways to keep doing old bad behaviours under new names, run a few fun-filled days of trainings, and declare that the problem was fixed. And so on. There has been scant peer reviewed data that shows that any of the process changes that Agile promised actually have had any lasting value on organisations whatsoever. However, led by these same Agile coaches, we continue to believe (at least, want to believe) that good is coming out of all the work put into the transformations. A new call to arms is upon us. We of the Agile Craftsmanship community say that the only verifiable improvements that came with the Agile revolution were in eXtreme Programming, and the passion surrounding an appreciation in making great things. In this session, Howard will open your eyes to a lifetime commitment – something akin to the pride that one experienced in the guild traditions of medieval Europe.]]> Tue, 19 Apr 2016 19:30:16 GMT /slideshow/the-manifesto-for-software-craftsmanship-because-postits-and-legos-dont-create-better-software/61111021 hdeiner@slideshare.net(hdeiner) The Manifesto for Software Craftsmanship – Because Post-Its and Legos Don’t Create Better Software! hdeiner If one were to characterise the last 60 years of software development, it would probably look something like this: 1950s-1960s: People who can program are so rare that they blaze their own trails to make things happen. They create amazing things, given the state and cost of hardware in those times. 1970s-1990s: Software development matures and becomes commonplace. Many non-developers are absorbed into large development organisations as a way to help control costs. Because of so many controls, checkers, checkers of checkers, and so on, costs spiral out of control. A desire to make software more manageable leads to a call for software engineering. 2000s-present: The Agile movement responds to the dizzying controls that the quasi-command-and-control structure of development has become with a manifesto – a call to get back to basics. To look past the waste associated with bloated software development management, and work in collaborative concert between business and development. As more and more organisations attempted to “become Agile” through transformations, some funny things happened. People started to believe that all they had to do was fix the process and the software would magically improve itself. Late adopters “got passes” from later generation Agile coaches and found ways to keep doing old bad behaviours under new names, run a few fun-filled days of trainings, and declare that the problem was fixed. And so on. There has been scant peer reviewed data that shows that any of the process changes that Agile promised actually have had any lasting value on organisations whatsoever. However, led by these same Agile coaches, we continue to believe (at least, want to believe) that good is coming out of all the work put into the transformations. A new call to arms is upon us. We of the Agile Craftsmanship community say that the only verifiable improvements that came with the Agile revolution were in eXtreme Programming, and the passion surrounding an appreciation in making great things. In this session, Howard will open your eyes to a lifetime commitment – something akin to the pride that one experienced in the guild traditions of medieval Europe. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/themanifestoforsoftwarecraftsmanshipbecausepostitsandlegosdontcreatebettersoftware-160419193016-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> If one were to characterise the last 60 years of software development, it would probably look something like this: 1950s-1960s: People who can program are so rare that they blaze their own trails to make things happen. They create amazing things, given the state and cost of hardware in those times. 1970s-1990s: Software development matures and becomes commonplace. Many non-developers are absorbed into large development organisations as a way to help control costs. Because of so many controls, checkers, checkers of checkers, and so on, costs spiral out of control. A desire to make software more manageable leads to a call for software engineering. 2000s-present: The Agile movement responds to the dizzying controls that the quasi-command-and-control structure of development has become with a manifesto – a call to get back to basics. To look past the waste associated with bloated software development management, and work in collaborative concert between business and development. As more and more organisations attempted to “become Agile” through transformations, some funny things happened. People started to believe that all they had to do was fix the process and the software would magically improve itself. Late adopters “got passes” from later generation Agile coaches and found ways to keep doing old bad behaviours under new names, run a few fun-filled days of trainings, and declare that the problem was fixed. And so on. There has been scant peer reviewed data that shows that any of the process changes that Agile promised actually have had any lasting value on organisations whatsoever. However, led by these same Agile coaches, we continue to believe (at least, want to believe) that good is coming out of all the work put into the transformations. A new call to arms is upon us. We of the Agile Craftsmanship community say that the only verifiable improvements that came with the Agile revolution were in eXtreme Programming, and the passion surrounding an appreciation in making great things. In this session, Howard will open your eyes to a lifetime commitment – something akin to the pride that one experienced in the guild traditions of medieval Europe.
The Manifesto for Software Craftsmanship – Because Post-Its and Legos Don’t Create Better Software! from Howard Deiner
]]> 251 4 https://cdn.slidesharecdn.com/ss_thumbnails/themanifestoforsoftwarecraftsmanshipbecausepostitsandlegosdontcreatebettersoftware-160419193016-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 TDD for the Newb Who Wants to Become an Apprentice /slideshow/tdd-for-the-newb-who-wants-to-become-an-apprentice/61110245 tddforthenewb-whowantstobecomeanapprentice-160419190945
Just about everyone understands that test-driven development (TDD) is one of the best ways to make sure that the code you produce has quality baked in and has a leg up when it comes to maintainability, readability and so on. But, perhaps you’re a little new to the scene, and are a bit shy in saying so and asking for help. No matter. In this workshop, Howard will guide you through a set of increasingly complex coding examples, giving you the knowledge and confidence to use TDD, so your code can start benefitting from the discipline’s practice. We will start with no prior knowledge of TDD, and go on to gain insight into not just how and what to do, but also to understand the whys of the TDD practice. Don’t expect to become an expert in a day, but do expect to be ready to start using your new-found knowledge immediately to start effectively and efficiently keeping bugs from ever showing up on your code’s doorstep, and how to eradicate them from ever appearing again should one find it’s way into your code!]]>
Just about everyone understands that test-driven development (TDD) is one of the best ways to make sure that the code you produce has quality baked in and has a leg up when it comes to maintainability, readability and so on. But, perhaps you’re a little new to the scene, and are a bit shy in saying so and asking for help. No matter. In this workshop, Howard will guide you through a set of increasingly complex coding examples, giving you the knowledge and confidence to use TDD, so your code can start benefitting from the discipline’s practice. We will start with no prior knowledge of TDD, and go on to gain insight into not just how and what to do, but also to understand the whys of the TDD practice. Don’t expect to become an expert in a day, but do expect to be ready to start using your new-found knowledge immediately to start effectively and efficiently keeping bugs from ever showing up on your code’s doorstep, and how to eradicate them from ever appearing again should one find it’s way into your code!]]> Tue, 19 Apr 2016 19:09:45 GMT /slideshow/tdd-for-the-newb-who-wants-to-become-an-apprentice/61110245 hdeiner@slideshare.net(hdeiner) TDD for the Newb Who Wants to Become an Apprentice hdeiner Just about everyone understands that test-driven development (TDD) is one of the best ways to make sure that the code you produce has quality baked in and has a leg up when it comes to maintainability, readability and so on. But, perhaps you’re a little new to the scene, and are a bit shy in saying so and asking for help. No matter. In this workshop, Howard will guide you through a set of increasingly complex coding examples, giving you the knowledge and confidence to use TDD, so your code can start benefitting from the discipline’s practice. We will start with no prior knowledge of TDD, and go on to gain insight into not just how and what to do, but also to understand the whys of the TDD practice. Don’t expect to become an expert in a day, but do expect to be ready to start using your new-found knowledge immediately to start effectively and efficiently keeping bugs from ever showing up on your code’s doorstep, and how to eradicate them from ever appearing again should one find it’s way into your code! <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/tddforthenewb-whowantstobecomeanapprentice-160419190945-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Just about everyone understands that test-driven development (TDD) is one of the best ways to make sure that the code you produce has quality baked in and has a leg up when it comes to maintainability, readability and so on. But, perhaps you’re a little new to the scene, and are a bit shy in saying so and asking for help. No matter. In this workshop, Howard will guide you through a set of increasingly complex coding examples, giving you the knowledge and confidence to use TDD, so your code can start benefitting from the discipline’s practice. We will start with no prior knowledge of TDD, and go on to gain insight into not just how and what to do, but also to understand the whys of the TDD practice. Don’t expect to become an expert in a day, but do expect to be ready to start using your new-found knowledge immediately to start effectively and efficiently keeping bugs from ever showing up on your code’s doorstep, and how to eradicate them from ever appearing again should one find it’s way into your code!
TDD for the Newb Who Wants to Become an Apprentice from Howard Deiner
]]> 293 5 https://cdn.slidesharecdn.com/ss_thumbnails/tddforthenewb-whowantstobecomeanapprentice-160419190945-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 The Pragmatic Management of Technical Debt /slideshow/the-pragmatic-management-of-technical-debt/61110111 thepragmaticmanagementoftechnicaldebt-160419190609
Software is a little like those expensive shiny new electronics that we all crave. We spend a bunch of money acquiring one. It’s great. Solves all of the problems that we had. Runs fast. Looks outstanding. Then the ravages of time overtake it. It starts getting grimy. Scratched. Dented. We spend more money keeping it shiny and cool looking. But eventually, it gets too slow to run the latest problem-solving stuff, and we start to think of the next expensive shiny new electronic thing to replace it. But now, we’re talking real money, and we hesitate. Should we just keep our old, slow (and getting grimier by the day) device, or spend money (that perhaps we don’t have, and will have to borrow) to acquire a new one? Such is modern life. And such is the life of software. This session is not about the newest shiny devices, but about the software that we write day to day. In the quest to keep software being developed on a schedule that is acceptable to the business, as we add new features and functionality, we sometimes cut corners, instead of doing the refactorings that the software should have day-to-day. Sometimes, we’re even forced to “hack” a solution together because “working software” is our highest priority. But no one said that working software is written in a way that we’d be proud to show our friends! And if we continue to work that way, one day the product owner will find that our estimate for completion, whether explicit or derived from metrics such as story points or cycle time, are simply too high for the benefit expected. Then what? In this session, Howard will look into such perennial questions as “should short-term technical debt estimates be included in story points”, “how should we deal with long-term technical debt?”, and “should technical debt have its own backlog?” We will talk tools and techniques related to finding where technical debt is hiding. And we will do all of this with a mindset that isn’t dogmatic with either “all technical debt is bad” nor “the future will take care of itself”.]]>
Software is a little like those expensive shiny new electronics that we all crave. We spend a bunch of money acquiring one. It’s great. Solves all of the problems that we had. Runs fast. Looks outstanding. Then the ravages of time overtake it. It starts getting grimy. Scratched. Dented. We spend more money keeping it shiny and cool looking. But eventually, it gets too slow to run the latest problem-solving stuff, and we start to think of the next expensive shiny new electronic thing to replace it. But now, we’re talking real money, and we hesitate. Should we just keep our old, slow (and getting grimier by the day) device, or spend money (that perhaps we don’t have, and will have to borrow) to acquire a new one? Such is modern life. And such is the life of software. This session is not about the newest shiny devices, but about the software that we write day to day. In the quest to keep software being developed on a schedule that is acceptable to the business, as we add new features and functionality, we sometimes cut corners, instead of doing the refactorings that the software should have day-to-day. Sometimes, we’re even forced to “hack” a solution together because “working software” is our highest priority. But no one said that working software is written in a way that we’d be proud to show our friends! And if we continue to work that way, one day the product owner will find that our estimate for completion, whether explicit or derived from metrics such as story points or cycle time, are simply too high for the benefit expected. Then what? In this session, Howard will look into such perennial questions as “should short-term technical debt estimates be included in story points”, “how should we deal with long-term technical debt?”, and “should technical debt have its own backlog?” We will talk tools and techniques related to finding where technical debt is hiding. And we will do all of this with a mindset that isn’t dogmatic with either “all technical debt is bad” nor “the future will take care of itself”.]]> Tue, 19 Apr 2016 19:06:09 GMT /slideshow/the-pragmatic-management-of-technical-debt/61110111 hdeiner@slideshare.net(hdeiner) The Pragmatic Management of Technical Debt hdeiner Software is a little like those expensive shiny new electronics that we all crave. We spend a bunch of money acquiring one. It’s great. Solves all of the problems that we had. Runs fast. Looks outstanding. Then the ravages of time overtake it. It starts getting grimy. Scratched. Dented. We spend more money keeping it shiny and cool looking. But eventually, it gets too slow to run the latest problem-solving stuff, and we start to think of the next expensive shiny new electronic thing to replace it. But now, we’re talking real money, and we hesitate. Should we just keep our old, slow (and getting grimier by the day) device, or spend money (that perhaps we don’t have, and will have to borrow) to acquire a new one? Such is modern life. And such is the life of software. This session is not about the newest shiny devices, but about the software that we write day to day. In the quest to keep software being developed on a schedule that is acceptable to the business, as we add new features and functionality, we sometimes cut corners, instead of doing the refactorings that the software should have day-to-day. Sometimes, we’re even forced to “hack” a solution together because “working software” is our highest priority. But no one said that working software is written in a way that we’d be proud to show our friends! And if we continue to work that way, one day the product owner will find that our estimate for completion, whether explicit or derived from metrics such as story points or cycle time, are simply too high for the benefit expected. Then what? In this session, Howard will look into such perennial questions as “should short-term technical debt estimates be included in story points”, “how should we deal with long-term technical debt?”, and “should technical debt have its own backlog?” We will talk tools and techniques related to finding where technical debt is hiding. And we will do all of this with a mindset that isn’t dogmatic with either “all technical debt is bad” nor “the future will take care of itself”. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/thepragmaticmanagementoftechnicaldebt-160419190609-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Software is a little like those expensive shiny new electronics that we all crave. We spend a bunch of money acquiring one. It’s great. Solves all of the problems that we had. Runs fast. Looks outstanding. Then the ravages of time overtake it. It starts getting grimy. Scratched. Dented. We spend more money keeping it shiny and cool looking. But eventually, it gets too slow to run the latest problem-solving stuff, and we start to think of the next expensive shiny new electronic thing to replace it. But now, we’re talking real money, and we hesitate. Should we just keep our old, slow (and getting grimier by the day) device, or spend money (that perhaps we don’t have, and will have to borrow) to acquire a new one? Such is modern life. And such is the life of software. This session is not about the newest shiny devices, but about the software that we write day to day. In the quest to keep software being developed on a schedule that is acceptable to the business, as we add new features and functionality, we sometimes cut corners, instead of doing the refactorings that the software should have day-to-day. Sometimes, we’re even forced to “hack” a solution together because “working software” is our highest priority. But no one said that working software is written in a way that we’d be proud to show our friends! And if we continue to work that way, one day the product owner will find that our estimate for completion, whether explicit or derived from metrics such as story points or cycle time, are simply too high for the benefit expected. Then what? In this session, Howard will look into such perennial questions as “should short-term technical debt estimates be included in story points”, “how should we deal with long-term technical debt?”, and “should technical debt have its own backlog?” We will talk tools and techniques related to finding where technical debt is hiding. And we will do all of this with a mindset that isn’t dogmatic with either “all technical debt is bad” nor “the future will take care of itself”.
The Pragmatic Management of Technical Debt from Howard Deiner
]]> 243 4 https://cdn.slidesharecdn.com/ss_thumbnails/thepragmaticmanagementoftechnicaldebt-160419190609-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Howard Deiner - Agile india 2016 - How Much Unit Testing is Enough - Ask a Mutant Army to Find Out! /slideshow/howard-deiner-agile-india-2016-how-much-unit-testing-is-enough-ask-a-mutant-army-to-find-out/59529564 howarddeiner-agileindia2016-howmuchunittestingisenough-askamutantarmytofindout-160314131306
There's an old joke that goes something like this. A tourist in New York City asks a resident how to get to a famous concert venue, saying, "How do you get to Carnegie Hall?" To which the resident replies, "Practice." Aside from the slight difference in topic, this is almost the same as asking, "How do I get to high-quality code that I can use Continuous Delivery on?" You could easily say, "Practice." By this, what you mean is that you need to test early and often to ensure that you have high-quality code. Everyone knows that unit testing is a large part of that equation. Managers (and others) have learned that you need to watch the code coverage metrics to see that you are testing every line of your code. People feel comfortable that if you test all the code that you're never going to be blind-sided by a bug that you missed during development. But, as most of us who have actually paid attention to code coverage know, that is misplaced comfort. That's because it's too easy to fall prey to one of two fallacies about code coverage. First, it's too easy to game the metric, if you need to impress your management into complacency. And second, it is a poor metric to judge quality by. Unit testing is the answer for high-quality code, but how much testing is enough? There are qualitative metrics, such as you have enough unit tests when you don't have production problems, but that really begs the question. There are static and dynamic code metrics that you can produce, but those also fall short of the goal. However, there is one technique to use that goes a long way to answering the question unambiguously. Mutation Testing. Mutation Testing assumes 100% code coverage. It then takes your nice happy code and messes with it. Negate a conditional. The code now does something else. Do your unit tests find that bug? Good! How about changing a conditional. Oops. The mutation survives, and the unit tests don't find it? Bad!! This session describes the problem and one tool that can be used to fix it for good. The tool is called PIT, and it’s for Java code. We will see the results in a couple of small projects, and then see what it looks like in a not so small open source project. We will see the role that mutation testing can have on quality, and how we would use it in our build automation to get us further down the road to having successful deliveries all the time - not train wrecks at just the wrong time.]]>
There's an old joke that goes something like this. A tourist in New York City asks a resident how to get to a famous concert venue, saying, "How do you get to Carnegie Hall?" To which the resident replies, "Practice." Aside from the slight difference in topic, this is almost the same as asking, "How do I get to high-quality code that I can use Continuous Delivery on?" You could easily say, "Practice." By this, what you mean is that you need to test early and often to ensure that you have high-quality code. Everyone knows that unit testing is a large part of that equation. Managers (and others) have learned that you need to watch the code coverage metrics to see that you are testing every line of your code. People feel comfortable that if you test all the code that you're never going to be blind-sided by a bug that you missed during development. But, as most of us who have actually paid attention to code coverage know, that is misplaced comfort. That's because it's too easy to fall prey to one of two fallacies about code coverage. First, it's too easy to game the metric, if you need to impress your management into complacency. And second, it is a poor metric to judge quality by. Unit testing is the answer for high-quality code, but how much testing is enough? There are qualitative metrics, such as you have enough unit tests when you don't have production problems, but that really begs the question. There are static and dynamic code metrics that you can produce, but those also fall short of the goal. However, there is one technique to use that goes a long way to answering the question unambiguously. Mutation Testing. Mutation Testing assumes 100% code coverage. It then takes your nice happy code and messes with it. Negate a conditional. The code now does something else. Do your unit tests find that bug? Good! How about changing a conditional. Oops. The mutation survives, and the unit tests don't find it? Bad!! This session describes the problem and one tool that can be used to fix it for good. The tool is called PIT, and it’s for Java code. We will see the results in a couple of small projects, and then see what it looks like in a not so small open source project. We will see the role that mutation testing can have on quality, and how we would use it in our build automation to get us further down the road to having successful deliveries all the time - not train wrecks at just the wrong time.]]> Mon, 14 Mar 2016 13:13:05 GMT /slideshow/howard-deiner-agile-india-2016-how-much-unit-testing-is-enough-ask-a-mutant-army-to-find-out/59529564 hdeiner@slideshare.net(hdeiner) Howard Deiner - Agile india 2016 - How Much Unit Testing is Enough - Ask a Mutant Army to Find Out! hdeiner There's an old joke that goes something like this. A tourist in New York City asks a resident how to get to a famous concert venue, saying, "How do you get to Carnegie Hall?" To which the resident replies, "Practice." Aside from the slight difference in topic, this is almost the same as asking, "How do I get to high-quality code that I can use Continuous Delivery on?" You could easily say, "Practice." By this, what you mean is that you need to test early and often to ensure that you have high-quality code. Everyone knows that unit testing is a large part of that equation. Managers (and others) have learned that you need to watch the code coverage metrics to see that you are testing every line of your code. People feel comfortable that if you test all the code that you're never going to be blind-sided by a bug that you missed during development. But, as most of us who have actually paid attention to code coverage know, that is misplaced comfort. That's because it's too easy to fall prey to one of two fallacies about code coverage. First, it's too easy to game the metric, if you need to impress your management into complacency. And second, it is a poor metric to judge quality by. Unit testing is the answer for high-quality code, but how much testing is enough? There are qualitative metrics, such as you have enough unit tests when you don't have production problems, but that really begs the question. There are static and dynamic code metrics that you can produce, but those also fall short of the goal. However, there is one technique to use that goes a long way to answering the question unambiguously. Mutation Testing. Mutation Testing assumes 100% code coverage. It then takes your nice happy code and messes with it. Negate a conditional. The code now does something else. Do your unit tests find that bug? Good! How about changing a conditional. Oops. The mutation survives, and the unit tests don't find it? Bad!! This session describes the problem and one tool that can be used to fix it for good. The tool is called PIT, and it’s for Java code. We will see the results in a couple of small projects, and then see what it looks like in a not so small open source project. We will see the role that mutation testing can have on quality, and how we would use it in our build automation to get us further down the road to having successful deliveries all the time - not train wrecks at just the wrong time. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-agileindia2016-howmuchunittestingisenough-askamutantarmytofindout-160314131306-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> There&#39;s an old joke that goes something like this. A tourist in New York City asks a resident how to get to a famous concert venue, saying, &quot;How do you get to Carnegie Hall?&quot; To which the resident replies, &quot;Practice.&quot; Aside from the slight difference in topic, this is almost the same as asking, &quot;How do I get to high-quality code that I can use Continuous Delivery on?&quot; You could easily say, &quot;Practice.&quot; By this, what you mean is that you need to test early and often to ensure that you have high-quality code. Everyone knows that unit testing is a large part of that equation. Managers (and others) have learned that you need to watch the code coverage metrics to see that you are testing every line of your code. People feel comfortable that if you test all the code that you&#39;re never going to be blind-sided by a bug that you missed during development. But, as most of us who have actually paid attention to code coverage know, that is misplaced comfort. That&#39;s because it&#39;s too easy to fall prey to one of two fallacies about code coverage. First, it&#39;s too easy to game the metric, if you need to impress your management into complacency. And second, it is a poor metric to judge quality by. Unit testing is the answer for high-quality code, but how much testing is enough? There are qualitative metrics, such as you have enough unit tests when you don&#39;t have production problems, but that really begs the question. There are static and dynamic code metrics that you can produce, but those also fall short of the goal. However, there is one technique to use that goes a long way to answering the question unambiguously. Mutation Testing. Mutation Testing assumes 100% code coverage. It then takes your nice happy code and messes with it. Negate a conditional. The code now does something else. Do your unit tests find that bug? Good! How about changing a conditional. Oops. The mutation survives, and the unit tests don&#39;t find it? Bad!! This session describes the problem and one tool that can be used to fix it for good. The tool is called PIT, and it’s for Java code. We will see the results in a couple of small projects, and then see what it looks like in a not so small open source project. We will see the role that mutation testing can have on quality, and how we would use it in our build automation to get us further down the road to having successful deliveries all the time - not train wrecks at just the wrong time.
Howard Deiner - Agile india 2016 - How Much Unit Testing is Enough - Ask a Mutant Army to Find Out! from Howard Deiner
]]> 827 6 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-agileindia2016-howmuchunittestingisenough-askamutantarmytofindout-160314131306-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Why Johnny Can't Unit Test His Legacy Code - And What You Can Do About It /slideshow/why-johnny-cant-unit-test-his-legacy-code-and-what-you-can-do-about-it/53938310 howarddeiner-softwarearchitect2015-whyjohnnycantunittesthislegacycode-andwhatyoucandoaboutit-151014175102-lva1-app6891
Back in 1955, Rudolf Flesch wrote his seminal book “Why Johnny Can’t Read”. The book became a flash point about how American education was depriving children of the joys of knowledge by not properly training them in the correct way to learn to read, by phonics, rather than the "whole word” guessing that was popular at the time. The book was a bellwether about the “crisis in education” at the time. Today’s session will not be about education, reading, or whether phonics are desirable or not. But the session today does address a serious problem that just about everyone in the IT industry faces. We suffer because our legacy code is not unit tested. Actually, lack of unit testing in legacy code (which is really a tautology) is just an easily observed symptom of the real issue, which is lack of quality and lack of knowledge in the code that we depend on, day after day. When the code shows a defect, most organisations expect a quick resolution to the problem and hope for the best. The same tack is taken when the code needs to be extended. This technique, called “code and pray”, rarely ends well. Organizations that try to do the right thing will give their development team the additional responsibility to unit test their code. Everyone knows that unit testing will go a long way in addressing the quality issue. The bet is that the time and effort taken to unit test the code will fix the quality problem. And they’re right. There are many studies that show this result. But there is one fatal flaw in these best intentions. Unit testing legacy code is hard. Really hard. And many times, this one fact torpedoes the entire effort that was supposed to make things better. This is the first part of a two part series on Johnny (the other being “Why Johnny STILL Can’t Unit Test His Legacy Code”). In this session, we will look at the technical issues surrounding refactoring legacy code. ]]>
Back in 1955, Rudolf Flesch wrote his seminal book “Why Johnny Can’t Read”. The book became a flash point about how American education was depriving children of the joys of knowledge by not properly training them in the correct way to learn to read, by phonics, rather than the "whole word” guessing that was popular at the time. The book was a bellwether about the “crisis in education” at the time. Today’s session will not be about education, reading, or whether phonics are desirable or not. But the session today does address a serious problem that just about everyone in the IT industry faces. We suffer because our legacy code is not unit tested. Actually, lack of unit testing in legacy code (which is really a tautology) is just an easily observed symptom of the real issue, which is lack of quality and lack of knowledge in the code that we depend on, day after day. When the code shows a defect, most organisations expect a quick resolution to the problem and hope for the best. The same tack is taken when the code needs to be extended. This technique, called “code and pray”, rarely ends well. Organizations that try to do the right thing will give their development team the additional responsibility to unit test their code. Everyone knows that unit testing will go a long way in addressing the quality issue. The bet is that the time and effort taken to unit test the code will fix the quality problem. And they’re right. There are many studies that show this result. But there is one fatal flaw in these best intentions. Unit testing legacy code is hard. Really hard. And many times, this one fact torpedoes the entire effort that was supposed to make things better. This is the first part of a two part series on Johnny (the other being “Why Johnny STILL Can’t Unit Test His Legacy Code”). In this session, we will look at the technical issues surrounding refactoring legacy code. ]]> Wed, 14 Oct 2015 17:51:02 GMT /slideshow/why-johnny-cant-unit-test-his-legacy-code-and-what-you-can-do-about-it/53938310 hdeiner@slideshare.net(hdeiner) Why Johnny Can't Unit Test His Legacy Code - And What You Can Do About It hdeiner Back in 1955, Rudolf Flesch wrote his seminal book “Why Johnny Can’t Read”. The book became a flash point about how American education was depriving children of the joys of knowledge by not properly training them in the correct way to learn to read, by phonics, rather than the "whole word” guessing that was popular at the time. The book was a bellwether about the “crisis in education” at the time. Today’s session will not be about education, reading, or whether phonics are desirable or not. But the session today does address a serious problem that just about everyone in the IT industry faces. We suffer because our legacy code is not unit tested. Actually, lack of unit testing in legacy code (which is really a tautology) is just an easily observed symptom of the real issue, which is lack of quality and lack of knowledge in the code that we depend on, day after day. When the code shows a defect, most organisations expect a quick resolution to the problem and hope for the best. The same tack is taken when the code needs to be extended. This technique, called “code and pray”, rarely ends well. Organizations that try to do the right thing will give their development team the additional responsibility to unit test their code. Everyone knows that unit testing will go a long way in addressing the quality issue. The bet is that the time and effort taken to unit test the code will fix the quality problem. And they’re right. There are many studies that show this result. But there is one fatal flaw in these best intentions. Unit testing legacy code is hard. Really hard. And many times, this one fact torpedoes the entire effort that was supposed to make things better. This is the first part of a two part series on Johnny (the other being “Why Johnny STILL Can’t Unit Test His Legacy Code”). In this session, we will look at the technical issues surrounding refactoring legacy code. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-softwarearchitect2015-whyjohnnycantunittesthislegacycode-andwhatyoucandoaboutit-151014175102-lva1-app6891-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Back in 1955, Rudolf Flesch wrote his seminal book “Why Johnny Can’t Read”. The book became a flash point about how American education was depriving children of the joys of knowledge by not properly training them in the correct way to learn to read, by phonics, rather than the &quot;whole word” guessing that was popular at the time. The book was a bellwether about the “crisis in education” at the time. Today’s session will not be about education, reading, or whether phonics are desirable or not. But the session today does address a serious problem that just about everyone in the IT industry faces. We suffer because our legacy code is not unit tested. Actually, lack of unit testing in legacy code (which is really a tautology) is just an easily observed symptom of the real issue, which is lack of quality and lack of knowledge in the code that we depend on, day after day. When the code shows a defect, most organisations expect a quick resolution to the problem and hope for the best. The same tack is taken when the code needs to be extended. This technique, called “code and pray”, rarely ends well. Organizations that try to do the right thing will give their development team the additional responsibility to unit test their code. Everyone knows that unit testing will go a long way in addressing the quality issue. The bet is that the time and effort taken to unit test the code will fix the quality problem. And they’re right. There are many studies that show this result. But there is one fatal flaw in these best intentions. Unit testing legacy code is hard. Really hard. And many times, this one fact torpedoes the entire effort that was supposed to make things better. This is the first part of a two part series on Johnny (the other being “Why Johnny STILL Can’t Unit Test His Legacy Code”). In this session, we will look at the technical issues surrounding refactoring legacy code.
Why Johnny Can't Unit Test His Legacy Code - And What You Can Do About It from Howard Deiner
]]> 940 10 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-softwarearchitect2015-whyjohnnycantunittesthislegacycode-andwhatyoucandoaboutit-151014175102-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Why Johnny STILL Can't Unit Test His Legacy Code - And What You Can Do About It /slideshow/why-johnny-still-cant-unit-test-his-legacy-code-and-what-you-can-do-about-it/53937998 howarddeiner-softwarearchitect2015-whyjohnnystillcantunittesthislegacycode-andwhatyoucandoaboutit-151014174250-lva1-app6892
Here, we look at the organizational and managerial issues surrounding refactoring legacy code. Topics that will be discussed include: 1) The definition of legacy code. It’s not just old card reader driver code that hasn’t been updated in a while. 2) The definition of unit testing. Running it has to be quick as an eye blink and repeatable. That’s going to obviate dependencies on our class under test. Especially ones that require databases, user interfaces and so on. 3) What’s the real goal of this, anyway? Looking into the TCO issues and the support of an Agile and Lean Startup mentality to aid the business attain its goals. 4) The need to write appropriate integration tests before we journeying into refactoring. How we, as managers, have to support that undertaking first. 5) Is unit testing merely “a tax” on otherwise available developer cycles to get features done? 6) Why, as managers, we sometimes think that integration tests are enough. 7) Why the metric of code coverage isn’t enough, although we might think that’s the goal. This will be a discussion that gets into the notion of why code coverage is merely a management report that serves as a starting point. 8) When are we done with writing unit tests? If 100% coverage isn’t the goal, what is? 9) The role of more advanced tools, such as Java PIT mutant testing and Microsoft Pex, in finding test suites that truly test quality. How to break the news to your developers, as well! 10) Examples of code that make a developer’s job a nightmare when they are trying to insert true unit tests. 11) How we, as managers, must change from a culture that might tell our people what to do and become one that leads and enables them.]]>
Here, we look at the organizational and managerial issues surrounding refactoring legacy code. Topics that will be discussed include: 1) The definition of legacy code. It’s not just old card reader driver code that hasn’t been updated in a while. 2) The definition of unit testing. Running it has to be quick as an eye blink and repeatable. That’s going to obviate dependencies on our class under test. Especially ones that require databases, user interfaces and so on. 3) What’s the real goal of this, anyway? Looking into the TCO issues and the support of an Agile and Lean Startup mentality to aid the business attain its goals. 4) The need to write appropriate integration tests before we journeying into refactoring. How we, as managers, have to support that undertaking first. 5) Is unit testing merely “a tax” on otherwise available developer cycles to get features done? 6) Why, as managers, we sometimes think that integration tests are enough. 7) Why the metric of code coverage isn’t enough, although we might think that’s the goal. This will be a discussion that gets into the notion of why code coverage is merely a management report that serves as a starting point. 8) When are we done with writing unit tests? If 100% coverage isn’t the goal, what is? 9) The role of more advanced tools, such as Java PIT mutant testing and Microsoft Pex, in finding test suites that truly test quality. How to break the news to your developers, as well! 10) Examples of code that make a developer’s job a nightmare when they are trying to insert true unit tests. 11) How we, as managers, must change from a culture that might tell our people what to do and become one that leads and enables them.]]> Wed, 14 Oct 2015 17:42:50 GMT /slideshow/why-johnny-still-cant-unit-test-his-legacy-code-and-what-you-can-do-about-it/53937998 hdeiner@slideshare.net(hdeiner) Why Johnny STILL Can't Unit Test His Legacy Code - And What You Can Do About It hdeiner Here, we look at the organizational and managerial issues surrounding refactoring legacy code. Topics that will be discussed include: 1) The definition of legacy code. It’s not just old card reader driver code that hasn’t been updated in a while. 2) The definition of unit testing. Running it has to be quick as an eye blink and repeatable. That’s going to obviate dependencies on our class under test. Especially ones that require databases, user interfaces and so on. 3) What’s the real goal of this, anyway? Looking into the TCO issues and the support of an Agile and Lean Startup mentality to aid the business attain its goals. 4) The need to write appropriate integration tests before we journeying into refactoring. How we, as managers, have to support that undertaking first. 5) Is unit testing merely “a tax” on otherwise available developer cycles to get features done? 6) Why, as managers, we sometimes think that integration tests are enough. 7) Why the metric of code coverage isn’t enough, although we might think that’s the goal. This will be a discussion that gets into the notion of why code coverage is merely a management report that serves as a starting point. 8) When are we done with writing unit tests? If 100% coverage isn’t the goal, what is? 9) The role of more advanced tools, such as Java PIT mutant testing and Microsoft Pex, in finding test suites that truly test quality. How to break the news to your developers, as well! 10) Examples of code that make a developer’s job a nightmare when they are trying to insert true unit tests. 11) How we, as managers, must change from a culture that might tell our people what to do and become one that leads and enables them. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-softwarearchitect2015-whyjohnnystillcantunittesthislegacycode-andwhatyoucandoaboutit-151014174250-lva1-app6892-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Here, we look at the organizational and managerial issues surrounding refactoring legacy code. Topics that will be discussed include: 1) The definition of legacy code. It’s not just old card reader driver code that hasn’t been updated in a while. 2) The definition of unit testing. Running it has to be quick as an eye blink and repeatable. That’s going to obviate dependencies on our class under test. Especially ones that require databases, user interfaces and so on. 3) What’s the real goal of this, anyway? Looking into the TCO issues and the support of an Agile and Lean Startup mentality to aid the business attain its goals. 4) The need to write appropriate integration tests before we journeying into refactoring. How we, as managers, have to support that undertaking first. 5) Is unit testing merely “a tax” on otherwise available developer cycles to get features done? 6) Why, as managers, we sometimes think that integration tests are enough. 7) Why the metric of code coverage isn’t enough, although we might think that’s the goal. This will be a discussion that gets into the notion of why code coverage is merely a management report that serves as a starting point. 8) When are we done with writing unit tests? If 100% coverage isn’t the goal, what is? 9) The role of more advanced tools, such as Java PIT mutant testing and Microsoft Pex, in finding test suites that truly test quality. How to break the news to your developers, as well! 10) Examples of code that make a developer’s job a nightmare when they are trying to insert true unit tests. 11) How we, as managers, must change from a culture that might tell our people what to do and become one that leads and enables them.
Why Johnny STILL Can't Unit Test His Legacy Code - And What You Can Do About It from Howard Deiner
]]> 344 6 https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-softwarearchitect2015-whyjohnnystillcantunittesthislegacycode-andwhatyoucandoaboutit-151014174250-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Getting Past the 50+70=120 Calculator in Cucumber /slideshow/getting-past-the-5070120-calculator-in-cucumber-46183325/46183325 gettingpastthe5070120calculatorincucumber-150323131529-conversion-gate01
With the best of intentions, people have flocked to behaviour-driven development by way of Cucumber over the past few years, and that’s a great thing! But just like dieting, where great things can fall to the wayside due to the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to the pressure to deliver more and more functionality, sprint after sprint. Often, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how product owners and the delivery team should start to communicate. But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt. In this session, Howard will guide you through 12 of the most important issues to tackle in your garden of executable requirements. He will discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin-driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques). By the end of the session, you should have plenty to indulge in on a healthy diet of BDD!]]>
With the best of intentions, people have flocked to behaviour-driven development by way of Cucumber over the past few years, and that’s a great thing! But just like dieting, where great things can fall to the wayside due to the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to the pressure to deliver more and more functionality, sprint after sprint. Often, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how product owners and the delivery team should start to communicate. But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt. In this session, Howard will guide you through 12 of the most important issues to tackle in your garden of executable requirements. He will discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin-driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques). By the end of the session, you should have plenty to indulge in on a healthy diet of BDD!]]> Mon, 23 Mar 2015 13:15:28 GMT /slideshow/getting-past-the-5070120-calculator-in-cucumber-46183325/46183325 hdeiner@slideshare.net(hdeiner) Getting Past the 50+70=120 Calculator in Cucumber hdeiner With the best of intentions, people have flocked to behaviour-driven development by way of Cucumber over the past few years, and that’s a great thing! But just like dieting, where great things can fall to the wayside due to the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to the pressure to deliver more and more functionality, sprint after sprint. Often, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how product owners and the delivery team should start to communicate. But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt. In this session, Howard will guide you through 12 of the most important issues to tackle in your garden of executable requirements. He will discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin-driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques). By the end of the session, you should have plenty to indulge in on a healthy diet of BDD! <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/gettingpastthe5070120calculatorincucumber-150323131529-conversion-gate01-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> With the best of intentions, people have flocked to behaviour-driven development by way of Cucumber over the past few years, and that’s a great thing! But just like dieting, where great things can fall to the wayside due to the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to the pressure to deliver more and more functionality, sprint after sprint. Often, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how product owners and the delivery team should start to communicate. But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt. In this session, Howard will guide you through 12 of the most important issues to tackle in your garden of executable requirements. He will discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin-driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques). By the end of the session, you should have plenty to indulge in on a healthy diet of BDD!
Getting Past the 50+70=120 Calculator in Cucumber from Howard Deiner
]]> 791 3 https://cdn.slidesharecdn.com/ss_thumbnails/gettingpastthe5070120calculatorincucumber-150323131529-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Continuous Delivery - The Whys, Whats, and Hows /slideshow/continuous-delivery-the-whys-whats-and-hows/46182716 continuousdelivery-thewhyswhatsandhows-150323130244-conversion-gate01
DevOps is commonly believed to be accomplished by having the development staff collaborate more closely with the operations staff. That’s definitely necessary, but woefully inadequate to achieve the goal of faster and better delivery in “the last mile” of an Agile shop. We need to address the fact that the DevOps concept cannot be accomplished in an Agile environment without a combination of Scrum-style collaboration augmented with a large dollop of architectural enablement, properly addressing environmental concerns, focusing on automated testing, and actually using true automated deployment practices. In this session, Howard will discuss the rationale behind Continuous Delivery, along with specific practices to get you started on making your sprints toward customer satisfaction less tiring and more enjoyable for everyone involved.]]>
DevOps is commonly believed to be accomplished by having the development staff collaborate more closely with the operations staff. That’s definitely necessary, but woefully inadequate to achieve the goal of faster and better delivery in “the last mile” of an Agile shop. We need to address the fact that the DevOps concept cannot be accomplished in an Agile environment without a combination of Scrum-style collaboration augmented with a large dollop of architectural enablement, properly addressing environmental concerns, focusing on automated testing, and actually using true automated deployment practices. In this session, Howard will discuss the rationale behind Continuous Delivery, along with specific practices to get you started on making your sprints toward customer satisfaction less tiring and more enjoyable for everyone involved.]]> Mon, 23 Mar 2015 13:02:44 GMT /slideshow/continuous-delivery-the-whys-whats-and-hows/46182716 hdeiner@slideshare.net(hdeiner) Continuous Delivery - The Whys, Whats, and Hows hdeiner DevOps is commonly believed to be accomplished by having the development staff collaborate more closely with the operations staff. That’s definitely necessary, but woefully inadequate to achieve the goal of faster and better delivery in “the last mile” of an Agile shop. We need to address the fact that the DevOps concept cannot be accomplished in an Agile environment without a combination of Scrum-style collaboration augmented with a large dollop of architectural enablement, properly addressing environmental concerns, focusing on automated testing, and actually using true automated deployment practices. In this session, Howard will discuss the rationale behind Continuous Delivery, along with specific practices to get you started on making your sprints toward customer satisfaction less tiring and more enjoyable for everyone involved. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/continuousdelivery-thewhyswhatsandhows-150323130244-conversion-gate01-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> DevOps is commonly believed to be accomplished by having the development staff collaborate more closely with the operations staff. That’s definitely necessary, but woefully inadequate to achieve the goal of faster and better delivery in “the last mile” of an Agile shop. We need to address the fact that the DevOps concept cannot be accomplished in an Agile environment without a combination of Scrum-style collaboration augmented with a large dollop of architectural enablement, properly addressing environmental concerns, focusing on automated testing, and actually using true automated deployment practices. In this session, Howard will discuss the rationale behind Continuous Delivery, along with specific practices to get you started on making your sprints toward customer satisfaction less tiring and more enjoyable for everyone involved.
Continuous Delivery - The Whys, Whats, and Hows from Howard Deiner
]]> 891 7 https://cdn.slidesharecdn.com/ss_thumbnails/continuousdelivery-thewhyswhatsandhows-150323130244-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Agility at Scale: Platform Versus Product Concerns - Agile Pune 2014 /slideshow/agility-at-scale-platform-versus-product-concerns-agile-pune-2014/41707507 agilityatscale-platformversusproductconcerns-reducedresolution-141118093530-conversion-gate02
A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood. This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.]]>
A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood. This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.]]> Tue, 18 Nov 2014 09:35:30 GMT /slideshow/agility-at-scale-platform-versus-product-concerns-agile-pune-2014/41707507 hdeiner@slideshare.net(hdeiner) Agility at Scale: Platform Versus Product Concerns - Agile Pune 2014 hdeiner A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood. This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/agilityatscale-platformversusproductconcerns-reducedresolution-141118093530-conversion-gate02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> A common failure mode for organizations attempting to adopt an Agile style of software development occurs when an attempt is made to “Scale Agile”. Suddenly, the organization finds that there are scheduling problems between teams. Delivery team members suddenly find that they are required to serve on several teams at once. Dependencies surface, and teams find it difficult to come together in a common cadence to produce working software in a continuously delivered fashion. Many times, these issues become so grave that the organization reverts back to the Waterfall model that they came to hate, but at least understood. This session explores Agile scaling concerns, and places particular emphasis on an architecturally significant distinction in the software to be created, and the components produced to allow the software to be created. That distinction revolves around cross cutting platform concerns versus product feature creation concerns. We will examine the distinctions and explore solutions that should help your organization get past these issues when it comes to portfolio management, by paying attention to extrinsic versus intrinsic value metrics.
Agility at Scale: Platform Versus Product Concerns - Agile Pune 2014 from Howard Deiner
]]> 1731 11 https://cdn.slidesharecdn.com/ss_thumbnails/agilityatscale-platformversusproductconcerns-reducedresolution-141118093530-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Agile/Lean Startup IT Portfolio Management - No Longer Oxymorphic! /slideshow/agile-lean-startup-it-portfolio-management-no-longer-oxymorphic/40370132 agile-leanstartupitportfoliomanagement-nolongeroxymorphicdownsampled-141016153845-conversion-gate02
Centralized development resources are commonplace in many of the late adopter organizations that struggle with Agile transformations. These centralized development resources tend to be doubly damming on the organization trying to become Agile: they lead to project thinking and management (rather than product thinking and leadership), and they lead to small incremental product development optimizations (rather than broad scale new and disruptive product breakouts). This session focuses on the mechanics of a portfolio management technique intended to guide the organization into the use of Lean Startup thinking to challenge Product Managers with, paired with the right type of fiscal rigor to make CFOs happy. Examples of how a Lean Startup Business Model Canvas can be paired with lightweight cost projections and revenue forecasts will be presented, with encouragement for organizations to specialize the artifact to suit their particular needs.]]>
Centralized development resources are commonplace in many of the late adopter organizations that struggle with Agile transformations. These centralized development resources tend to be doubly damming on the organization trying to become Agile: they lead to project thinking and management (rather than product thinking and leadership), and they lead to small incremental product development optimizations (rather than broad scale new and disruptive product breakouts). This session focuses on the mechanics of a portfolio management technique intended to guide the organization into the use of Lean Startup thinking to challenge Product Managers with, paired with the right type of fiscal rigor to make CFOs happy. Examples of how a Lean Startup Business Model Canvas can be paired with lightweight cost projections and revenue forecasts will be presented, with encouragement for organizations to specialize the artifact to suit their particular needs.]]> Thu, 16 Oct 2014 15:38:45 GMT /slideshow/agile-lean-startup-it-portfolio-management-no-longer-oxymorphic/40370132 hdeiner@slideshare.net(hdeiner) Agile/Lean Startup IT Portfolio Management - No Longer Oxymorphic! hdeiner Centralized development resources are commonplace in many of the late adopter organizations that struggle with Agile transformations. These centralized development resources tend to be doubly damming on the organization trying to become Agile: they lead to project thinking and management (rather than product thinking and leadership), and they lead to small incremental product development optimizations (rather than broad scale new and disruptive product breakouts). This session focuses on the mechanics of a portfolio management technique intended to guide the organization into the use of Lean Startup thinking to challenge Product Managers with, paired with the right type of fiscal rigor to make CFOs happy. Examples of how a Lean Startup Business Model Canvas can be paired with lightweight cost projections and revenue forecasts will be presented, with encouragement for organizations to specialize the artifact to suit their particular needs. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/agile-leanstartupitportfoliomanagement-nolongeroxymorphicdownsampled-141016153845-conversion-gate02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Centralized development resources are commonplace in many of the late adopter organizations that struggle with Agile transformations. These centralized development resources tend to be doubly damming on the organization trying to become Agile: they lead to project thinking and management (rather than product thinking and leadership), and they lead to small incremental product development optimizations (rather than broad scale new and disruptive product breakouts). This session focuses on the mechanics of a portfolio management technique intended to guide the organization into the use of Lean Startup thinking to challenge Product Managers with, paired with the right type of fiscal rigor to make CFOs happy. Examples of how a Lean Startup Business Model Canvas can be paired with lightweight cost projections and revenue forecasts will be presented, with encouragement for organizations to specialize the artifact to suit their particular needs.
Agile/Lean Startup IT Portfolio Management - No Longer Oxymorphic! from Howard Deiner
]]> 1493 10 https://cdn.slidesharecdn.com/ss_thumbnails/agile-leanstartupitportfoliomanagement-nolongeroxymorphicdownsampled-141016153845-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Lean Thinking and What it Means to the Agile Mindset /slideshow/lean-thinking-and-what-it-means-to-the-agile-mindset/34857544 leanthinkingandwhatitmeanstotheagilemindset-140519095757-phpapp01
Long before the Agile revolution for software development began, industry had learned that efficient production of goods required intense attention to quality, teamwork, and continuous improvement. These themes of Lean Manufacturing (which was further refined into the Toyota Production System) were never part of the original formulation of the Agile Manifesto, and are rarely mentioned as part of the traditional Agile/Scrum recipe for teams transforming to the new “Agile” mindset. The reality is that the traditional Agile/Scrum recipe is actually a “dumbed down” version of the Toyota Production System, and makes it easier for organisations to grasp and start from. However, if organisations really want to achieve the goal of producing the software they need in a fashion that leads to High Performance Teams and Sustainable Engineering, they will need to understand the principles of Lean so they can incorporate them into their unique process. This session teaches the basics of Lean, and demonstrates how they apply to Agile development.]]>
Long before the Agile revolution for software development began, industry had learned that efficient production of goods required intense attention to quality, teamwork, and continuous improvement. These themes of Lean Manufacturing (which was further refined into the Toyota Production System) were never part of the original formulation of the Agile Manifesto, and are rarely mentioned as part of the traditional Agile/Scrum recipe for teams transforming to the new “Agile” mindset. The reality is that the traditional Agile/Scrum recipe is actually a “dumbed down” version of the Toyota Production System, and makes it easier for organisations to grasp and start from. However, if organisations really want to achieve the goal of producing the software they need in a fashion that leads to High Performance Teams and Sustainable Engineering, they will need to understand the principles of Lean so they can incorporate them into their unique process. This session teaches the basics of Lean, and demonstrates how they apply to Agile development.]]> Mon, 19 May 2014 09:57:57 GMT /slideshow/lean-thinking-and-what-it-means-to-the-agile-mindset/34857544 hdeiner@slideshare.net(hdeiner) Lean Thinking and What it Means to the Agile Mindset hdeiner Long before the Agile revolution for software development began, industry had learned that efficient production of goods required intense attention to quality, teamwork, and continuous improvement. These themes of Lean Manufacturing (which was further refined into the Toyota Production System) were never part of the original formulation of the Agile Manifesto, and are rarely mentioned as part of the traditional Agile/Scrum recipe for teams transforming to the new “Agile” mindset. The reality is that the traditional Agile/Scrum recipe is actually a “dumbed down” version of the Toyota Production System, and makes it easier for organisations to grasp and start from. However, if organisations really want to achieve the goal of producing the software they need in a fashion that leads to High Performance Teams and Sustainable Engineering, they will need to understand the principles of Lean so they can incorporate them into their unique process. This session teaches the basics of Lean, and demonstrates how they apply to Agile development. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/leanthinkingandwhatitmeanstotheagilemindset-140519095757-phpapp01-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Long before the Agile revolution for software development began, industry had learned that efficient production of goods required intense attention to quality, teamwork, and continuous improvement. These themes of Lean Manufacturing (which was further refined into the Toyota Production System) were never part of the original formulation of the Agile Manifesto, and are rarely mentioned as part of the traditional Agile/Scrum recipe for teams transforming to the new “Agile” mindset. The reality is that the traditional Agile/Scrum recipe is actually a “dumbed down” version of the Toyota Production System, and makes it easier for organisations to grasp and start from. However, if organisations really want to achieve the goal of producing the software they need in a fashion that leads to High Performance Teams and Sustainable Engineering, they will need to understand the principles of Lean so they can incorporate them into their unique process. This session teaches the basics of Lean, and demonstrates how they apply to Agile development.
Lean Thinking and What it Means to the Agile Mindset from Howard Deiner
]]> 1024 5 https://cdn.slidesharecdn.com/ss_thumbnails/leanthinkingandwhatitmeanstotheagilemindset-140519095757-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation White http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Keep Agile Development from Becoming Fragile Development /slideshow/keep-agile-development-from-becoming-fragile-development/31615537 keepagiledevelopmentfrombecomingfragiledevelopment-140225055121-phpapp02
]]>
]]> Tue, 25 Feb 2014 05:51:21 GMT /slideshow/keep-agile-development-from-becoming-fragile-development/31615537 hdeiner@slideshare.net(hdeiner) Keep Agile Development from Becoming Fragile Development hdeiner <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/keepagiledevelopmentfrombecomingfragiledevelopment-140225055121-phpapp02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br>
Keep Agile Development from Becoming Fragile Development from Howard Deiner
]]> 416 2 https://cdn.slidesharecdn.com/ss_thumbnails/keepagiledevelopmentfrombecomingfragiledevelopment-140225055121-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Agility at Scale - Platform Versus Product Concerns /slideshow/agility-at-scale-platform-versus-product-concerns/31615501 agilityatscale-platformversusproductconcerns-140225055023-phpapp02
]]>
]]> Tue, 25 Feb 2014 05:50:22 GMT /slideshow/agility-at-scale-platform-versus-product-concerns/31615501 hdeiner@slideshare.net(hdeiner) Agility at Scale - Platform Versus Product Concerns hdeiner <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/agilityatscale-platformversusproductconcerns-140225055023-phpapp02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br>
Agility at Scale - Platform Versus Product Concerns from Howard Deiner
]]> 587 3 https://cdn.slidesharecdn.com/ss_thumbnails/agilityatscale-platformversusproductconcerns-140225055023-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Acceptance Test and Behavior Driven Development – The Secret Sauce to Modern Requirements /slideshow/acceptance-test-and-behavior-driven-development-the-secret-sauce-to-modern-requirements/31615461 acceptancetestandbehaviourdrivendevelopmentthesecretsaucetomodernrequirements-140225054934-phpapp02
]]>
]]> Tue, 25 Feb 2014 05:49:34 GMT /slideshow/acceptance-test-and-behavior-driven-development-the-secret-sauce-to-modern-requirements/31615461 hdeiner@slideshare.net(hdeiner) Acceptance Test and Behavior Driven Development – The Secret Sauce to Modern Requirements hdeiner <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/acceptancetestandbehaviourdrivendevelopmentthesecretsaucetomodernrequirements-140225054934-phpapp02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br>
Acceptance Test and Behavior Driven Development – The Secret Sauce to Modern Requirements from Howard Deiner
]]> 724 5 https://cdn.slidesharecdn.com/ss_thumbnails/acceptancetestandbehaviourdrivendevelopmentthesecretsaucetomodernrequirements-140225054934-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Pivoting Your Organization to Become Agile Testers /slideshow/pivoting-your-organization-to-become-agile-testers-31615184/31615184 pivotingyourorganizationtobecomeagiletesters-140225054046-phpapp02
Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists. This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start. We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue. And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.]]>
Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists. This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start. We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue. And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.]]> Tue, 25 Feb 2014 05:40:46 GMT /slideshow/pivoting-your-organization-to-become-agile-testers-31615184/31615184 hdeiner@slideshare.net(hdeiner) Pivoting Your Organization to Become Agile Testers hdeiner Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists. This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start. We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue. And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/pivotingyourorganizationtobecomeagiletesters-140225054046-phpapp02-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists. This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start. We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue. And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.
Pivoting Your Organization to Become Agile Testers from Howard Deiner
]]> 693 4 https://cdn.slidesharecdn.com/ss_thumbnails/pivotingyourorganizationtobecomeagiletesters-140225054046-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 https://cdn.slidesharecdn.com/profile-photo-hdeiner-48x48.jpg?cb=1694105216 Howard has been a software professional since 1975 and has consistently engaged in ever higher levels of responsibility. Starting in the world of application development in general, and commercial development, in particular, Howard has worked his way through many titles over the years - everything from programmer to architect to development manager to consultant. His innate curiosity has been a constant driving force over time. Understanding how things work now and being able to make new things as the need arises have served him well. He now focuses on driving innovation and improvement at the very core of the software creation process itself. www.deinersoft.com https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-synchronousvsasynchronousdigitalcircuitsasananalogytoorganizational-190315202318-thumbnail.jpg?width=320&height=320&fit=bounds hdeiner/synchronous-vs-asynchronous-digital-circuits-as-an-analogy-to-organizational-dysfunction-applied-to-devops-practices Synchronous vs Asynchr... https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-devopsproeurope2019-pivotingacompanytowardsgitopsandcontinuousdelivery-190315201936-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/pivoting-a-company-towards-gitops-and-continuous-delivery-a-technical-practices-coachs-tale-for-the-misbegotten/136625242 Pivoting a Company Tow... https://cdn.slidesharecdn.com/ss_thumbnails/howarddeiner-xpdaysukraine2017-improvingyourorganizationstechnicalprowesswithlegacycoderetreats-171112214008-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/improving-your-organizations-technical-prowess-with-legacy-code-retreats/81946077 Improving Your Organiz...