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 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 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), “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 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 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 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.

Organizations are embracing Continuous Delivery (CD) for many reasons nowadays, including:

• better throughput and stability of systems built and managed
• better effectiveness of the organization, resulting in better financial outcomes for the organization
• better job satisfaction for members of the organization
• a desire to play with shiny new things and engage in resume driven development

When we take a deeper look at what the goals are, and talk about how we accomplish those goals, many times the discussion starts to devolve into a discussion of tools and tool capability. And many times, the deciding factors of one tool versus another tool speak to the capabilities of the tools to work in the existing organizational structure.

But this approach is flawed. If we view CD as an organization change to achieve the goals stated before, then we should expect that the organizational structure, as well as the organization’s guiding principles will have to change as well.

This talk will center around the premise that the changes that are needed to accomplish CD, and subsequently achieve the benefits associated with that involve the use of new tools (potentially bright and shiny, as well as resume enhancing). But the tools are merely necessary but not sufficient in attaining the organizational’s CD goals. True teamwork both from both a technical team perspective as well as inter-team collaboration as required to truly get to full positive outcomes for DevOps based CD. We’ll speak to some tools, but mostly talk about good teams and the top quality software that they need to produce, and how they need to go about that.

In his book “Understanding the Four Rules of Simple Design”, Corey Haines lays out the basics for getting people together for a day and practice coding better. Unhappily, many of us have to deal with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. J. B. Rainsberger has started a variation on on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to extend that pattern and have retreat for those of us who work legacy code in Java often.

We will learn and practice 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.

By the end of the day, in addition to being tired and completely ready to put away our laptops forever, we will have gained valuable insights and practical experience with a topic no one likes to talk about - getting better working with legacy code!

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.  We look at the Java mututation tool called PIT.  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.

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 organizations 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 one part of a two part series on Johnny (the other being “Why Johnny Can’t Unit Test His Legacy Code”).  In this session, we will look at the organizational and managerial issues surrounding refactoring legacy code.  There is no full frontal code in the session, and you needn’t fear any lack in technical knowledge.  You will leave with a better understanding of what you can do about solving the problem.

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 organizations 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 one 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.  There may be full frontal code to look at and discuss.  You may be called on to help us achieve greatness in technical discussions.  You will leave with a better understanding of what you can do about solving the problem.

With the best of intentions, people have flocked to Behavior 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 from the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to pressure to deliver more and more functionality Sprint over Sprint.  Many times, 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.

Howard will guide you through 12 of the most important issues to work on in your garden of executable requirements.  We’ll 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!

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. 

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 organizations to grasp and start from. However, if organizations 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 organizations 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.

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.

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.

“Fixed price, fixed deliverables, and fixed schedule” contracts are just about the worst way to write contracts involving software, yet they are the most popular – so what are some techniques to use to fix that?

Organizations that perform professional services for software development or develop software on a work for hire basis are usually engaged bound by extensive contracts.  These contracts are typically characterized as “fixed price, fixed deliverables, and fixed schedule.”  These, of course, are the vertices of the “Iron Triangle of Software Development” and foreshadow a poor outcome due to issues that make the requirements gathering and project estimation phases that precede contract negotiation so prone to error.

Given this, the question becomes one of “how can I engage clients in a way that allows us each to achieve our goals?”  If Agile and Lean methods are the status quo for good development practices, how can I write contracts for development services that embrace this mindset and let each side achieve it’s goals better?  This lecture and roundtable explores the many facets of this question and provides the attendee answers that they can use going forward.

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.