Direct Playback

Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Listen on Spotify!

SPaMCAST 533 features our essay titled, Can Agile (SAFe) Be Interfaced With Waterfall? The long answer is yes, but the short answer is yes, but try to find a way to avoid the self-inflicted complexity. If you can’t avoid mixing and matching frameworks, there are paths to success you can leverage.

Other essays in our series on interfacing SAFe and waterfall efforts include:

Can Agile (SAFe) Be Interfaced With Waterfall? – https://bit.ly/2SLUmou

Interfacing Agile (SAFe) With Waterfall? – Transparency – https://bit.ly/2MWNYFT

Interfacing Agile (SAFe) With Waterfall? –  Synchronization – https://bit.ly/2WVgLio

Interfacing Agile (SAFe) With Waterfall? –  Code – https://bit.ly/2I6eUUR

This week we also have a quick visit from Tom Henricksen.  Tom created the popular Online Agile Summit. Today he announces the DevOps Online Summit that will be held on April 8th through 11th.  After you listen, check out the website! https://www.devopsonlinesummit.com/2019

Jeremy Berriault brings a new installment of the QA Corner (https://qacorner.blog/) to the cast this week.  Jeremy leverages work by Simon Sinek and tackles the “why” of testing.

Re-Read Saturday News
This week we continue our re-read of The Tipping Point by Malcolm Gladwell. In chapter two, Gladwell dives into the law of the few.  There are three types of people that are important to pushing an idea up to and over a tipping point: connectors, mavens, and salespeople.  All three are required. Remember to dust off your copy or buy a new copy and read along!

Current entry:

Week 3 – The Law of the Fewhttps://bit.ly/2Buau46 (more…)

IMG_1858.jpg

Paraphrasing the definition from Wikipedia, a center of excellence (COE) is a team that provides leadership, research, support and/or training for a focus area. COE’s are deployed for many reasons such as developing an organizational skill, rescuing a troubled initiative, or sometimes sheer desperation.  The reason and implementation path of the COE will impact the perception and value delivered This might seem like common knowledge, but to quote Voltaire, “common sense is not so common.” Done well, a COE can help infuse knowledge and energy into an organization. Done differently, a COE ends up becoming bureaucratic auditors under the flag of best practices. (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 514 features our interview with John Clapham. John and I talked DevOps, people, agile, and how all those pieces fit together coherently or not. John even quoted Bill and Ted’s Excellent Adventure. This is a big, fun, informative interview!

John Clapham is an experienced coach, trainer, and consultant, specializing in DevOps and Agile.  He helps teams to build great products, creating environments and systems which are effective, productive and enjoyable to work in. Often this means introducing Scrum, or developing a deeper understanding of the method and it’s principles.  John draws on broad experience as an engineer and lead, he has built web and enterprise applications in government, publishing, telecommunications, commerce, defense and public sector arenas.

Twitter:  @johnC_bristol

Web: http://www.cotelic.co.uk/

 

Re-Read Saturday News

This week we tackle Chapter 9 of The Checklist Manifesto.  The Save is the final chapter in the book.  Next week we will discuss our final thoughts and decide on the next book.  In chapter 9 Atul Gawande talks about his experiences with the surgical checklist he helped to create. The last chapter is a combination of emotion and evidence.

Remember to buy a copy of The Checklist Manifesto and READ along!

Current Installment:

Week 10 – The Savehttps://bit.ly/2NdhaXA (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 498 features our interview John Kordyback.  Agile is more than just Scrum or a bunch values. Agile has a technical side that can’t be ignored. This week, John and I have a wide-ranging conversation covering the technical side of agile, the impact of tools on principles, and the difference in agile approaches for systems of engagement and systems of record.

Bio:

John Kordyback is a Principal Consultant with ThoughtWorks leading technology transformations and applying lean principles within complex enterprises. He is a strong advocate for applying the lean delivery and operational practices found in the Devops and Evolutionary Architecture movements to gain more value from existing technology investments. John has worked in insurance, telecommunications, commodity and securities trading, high tech, energy, and the airline industries. Before his technology career, John worked as a researcher and practitioner for people with disabilities.

Email: jkordyba@thoughtworks.com

Twitter: @jkordyback

Re-Read Saturday News

This week we tackle chapter 20 of L. David Marquet’s Turn the Ship Around! (have you bought your copy?). Chapter 20 completes part 3 which has focused on competence and the run-up to the deployment of the Santa Fe. The title of this chapter is Final Preparations.  We have six or seven weeks left – Steven Adams is pushing for the next book to be Release It, the other option is The Checklist Manifesto.  Both are great . . . thoughts?

Current Installment:

Week 13: Final Preparations –  https://bit.ly/2t1OgSn (more…)

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features our interview with Alex Papadimoulis.  Alex is returning to the Software Process and Measurement Cast to discuss Release.  Release is card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick -taking card games. We also circled back to talk about continuous delivery and DevOps; a bit of lagniappe to add to a great interview.

Alex’s Bio:

Alex

Alex is a speaker and writer who is passionate about looking beyond the code to build great software. In addition to founding Inedo – the makers of BuildMaster, the popular continuous delivery platform – Alex also started The Daily WTF, a fun site dedicated to building software the wrong way.

Contact Information:

Email:  apapadimoulis@inedo.com
Twitter: @apapadimoulis
Web: http://inedo.com/
Other Web: http://thedailywtf.com/

Call to action!

We are just completed a re-read John Kotter’s classic Leading Change on the Software Process and Measurement Blog (www.tcagley.wordpress.com) and are in process of choosing the next book for Re-read Saturday.  Please go to the poll and cast your vote by February 15?  Vote now at Software Process and Measurement Blog!

Next SPaMCast

In the next Software Process and Measurement Cast we will feature our essay on commitment.  What is the power of making a commitment? The making and keeping of commitments are core components of professional behavior. The simple definition of a commitment is a promise to perform. Whether Agile or Waterfall, commitments are used to manage software projects. Commitments drive the behavior of individuals, teams and organizations.  Commitments are powerful!

Shameless Ad for my book!

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

Available in English and Chinese.

DevOps requires participation and cooperation.

DevOps requires participation and cooperation.

There is a general consensus that Agile frameworks are effective for delivering business value. Approaches and frameworks such as DevOps are often leveraged to ensure that Agile is both effective AND efficient.  Using a DevOps approach becomes even more critical for efficiency and effectiveness as projects, programs and organizations get larger requiring more collaboration and coordination. DevOps is a crucial tool for helping teams ensure deployment readiness and that the proliferation of technical environment and tools are effective when scaling Agile.

Implementing DevOps requires the involvement of a number of roles to deliver business value collaboratively. Involvement requires participation to be effective. Participation between developers, QA and TechOps personnel as part of the same value stream begins at planning. The Scaled Agile Framework Enterprise (SAFe) makes a strong statement about involvement and participation by integrating DevOps in the Agile Release Train (one of SAFe’s core structures). Integrating the concept of DevOps in the flow of a project or program helps to ensure that the team takes steps to maintain environments and deployment readiness that extend from the code base to the needed technical environments to build, test and share.

Deployment readiness includes a significant number of activities, all of which require broad involvement. Examples of these activities include:

  1. Version control. Version control is needed for the code (and all code like objects) so that the product can be properly built and that what is in the build is understood (and supposed to be there). Version control generally requires software tools and mutually agreed upon processes, conventions and standards.
  2. Build automation. Build automation pulls together files, objects and other assets into an executable (or consumable for non-code artifacts) form in a repeatable manner without (or with minimal) human interaction. All of the required processes and steps, such as compilation, packaging or generation of installers. [FRAGMENT] Build automation generally deploys and validates code to development or testing environments. Similar to version control, build automation requires tools, processes, conventions, standards and coding the automation.
  3. Deployment automation. Deployment automation is often a specialized version of build automation whose target is production environments. Deployment automation pushes and installs the final build to the production environment. Automation reduces the overhead, and reduces the chance for error (and therefore saves effort).

Professional teams that build software solutions typically require multiple technical environments during the product lifecycle. A typical progression of environments might be development, test (various) and staging. Generally the staging environment (just prior to production) should be the most production like, while development and test environments will have tools and attributes that make development and testing easier. Each of these environments needs to be provisioned and managed. DevOps brings that provisioning and management closer to the teams generating the code, reducing wait times. Automation of the provisioning can give development and testing teams more control over the technical environments (under the watchful eye of the TechOps groups).

As projects and programs become larger the classic separation of development from TechOps will slow a project down, make it more difficult to deliver more often and potentially generate problems in delivery. Implementing DevOps shortens the communication channels so that development, QA and TechOps personnel can collaborate on the environments and tools needed to deliver value faster, better and cheaper. Automation of substantial portions of the processes needed both to build and deploy code and manage the technical environments further improve the ability of the team or teams to deliver value. The savings in time, effort and defects can be better used to deliver more value for the organization.

Untitled

Implementing the concept of DevOps requires that a number of roles work together in a larger team all focused on three simple goals. These teams hereto now, even though focused on the greater good of the organization, are currently operated as silos. Operating in silos forces each team or department to maximize their team-specific goals. Generally, maximizing the efficiency of a specific step or process in the flow work required to deliver value to the business may not yield the most effective or efficient solution overall. DevOps takes a more holistic approach, using a systems thinking approach to view and approach the software value chain. Instead of seeing three or more silos of activity (Agile team, QA and TechOps), a more holistic approach sees the software process as single value chain. The value chain begins with an idea and ends when support is no longer needed. The software value stream can be considered a flow of products and services that are provisioned to deliver a service. The provisioning activity is a metaphor that can be used to highlight who is involved in delivering software in a DevOps environment.

Provisioning is a term often used in the delivery of telecommunications products and services (and other industries), and it is used to describe providing a service and everything needed to a user. Providing the service may include the equipment, network, software, training and the support necessary to begin and to continue using the service. The service is not complete and provisioned until the user can use the service in a manner that meets their needs. Viewing delivery as provisioning enforces a systems view of the processes and environments needed.

Developing, deploying and supporting any software-centric service requires a wide range of roles, products and services, that are often consoldiated into three categories; development teams, QA/testing, technical operations (TechOps).  Examples of  TechOps  roles can include configuration and environment management, security, network, release management and tool support just to name a few. TechOps are charged with providing the environment for services to be delivers and ensuring that those environments are safe, resilient and stable (I can think of any number of other additional attributes).

The roles of all development teams are fairly straightforward (that is not say they are not complex or difficult  Teams, whether Agile or  waterfall, build services in a development environment and then those services migrate through other environments until they are resident in some sort of production environment or environments. Development, QA and TechOps must understand and either create or emulate these environments to ensure that the business needs are met (and that the software runs). Additionally, the development, enhancement and maintenance process generally uses a wide range of tools to make writing, building, debugging, testing, promoting and installing code easier. These tools are part of the environment’s needs to develop and deliver software services.

QA or testing roles are designed to help to ensure that what is being built works, meets the definition of done and delivers the expected value. The process of testing often requires specialized environments to ensure integration and control.  In a similar manner, testing often requires tools for test automation, data preparation and even exploratory testing.

TechOps typically are involved in providing the environment or environments needed to deliver software constructing and allowing access to environments can often cause bottlenecks and constraints in the flow of value to the user. An organization embracing DevOps will actively pursue bottlenecks and constraints that slow the delivery of software. For example many organization leverage automation to provide the development teams with more control over nonproduction environments. Automation shortens the time waiting for another department to take an action and frees TechOps personnel to be actively involved in projects AND to manage overall the organizational technical environment.

DevOps helps to remove the roadblocks that slow the delivery of value by ensuing that Agile teams, QA and TechOps personnel work together so that environmental issues don’t get in the way. We can concieve of DevOps as the intersection of Agile Teams, QA and TechOps however what is more important is the interaction.  Interaction builds trust and empowerment so that the flow through the development, test and production environment is smooth.  The environments used to build software services are critical. Environments will need to be provisioned regardless of which Agile and lean techniques you are using. Even relatively common processes required specific software and storage to function. Consider the tools and coordination needed to use continuous builds and automated testing. If the flow of work needs to stop and wait until the environment is ready the delivery of value will be delayed.