By the invitation of Kevin Greene, I appeared with a distinguished panel including James Hill, Mehdi Mirakhorli, and Michael Angelo, to discuss Software Liability & Attestation at NIST’s Spring Forum at MITRE headquarters.

It was an honour and privilege to appear with such an array of panelists at the forum. All topics and speakers at the forum are involved with some of the most pressing Cyber Security issues of our era.

I was guest lecturer at Kenneth Levene Graduate School of Business and was honoured to teach the students of complexity, empiricism, and the origins of Agile practices.

Always a pleasure to talk with graduate students. Professor Emily McNair invited me to the University of Regina to speak about Agile practices in the modern enterprise. The GBUS 865 course focuses on Project Management principles.

I was honoured to be invited by Ross Chayka and the team at Global Online PMDay to share my thoughts about post-covid office design and team structure.

Work-from-home and work-from-office are part of our future. With rare exceptions, companies will blend the two concepts to create work environments that enable remote-working and in-person interaction as well. Let’s explore recent signals in the market that indicate the most likely scenarios as companies re-engage a post-Covid world of work.

I was honoured to be invited by Ross Chayka and the team at Ukraine PMDay to share my thoughts about organizational design and culture in agile companies.

With a lens on the history of work, I examine the contrast between industrial manufacturing and modern hi-tech product development. The contrast between Fred Taylor’s “Scientific Management” and the empirical patterns of predominant Agile practices begs the question: “How is it that Taylor’s Scientific Management is so unscientific?”

Organized by Nawaz Butt, I was honoured to share my thoughts about the ways Empiricism has helped the Agile Community to adapt over time. Given three examples: Scrum Values, User Stories, Velocity, I hosted discussion about major changes that have occured in the collective mindset of the Agile Community. By “doing it and helping others to do it” we continue to learn and evolve.

Since 2001, when the Manifesto for Agile Software Development was published, the Agile community has evolved — and exploded! And all through the evolution of the Agile community, the effect of empiricism is apparent. Individuals and collectives are continuously inspecting their circumstance and adapting their practices, goals, and values. It’s been a remarkable journey. Let’s reflect on a few key moments from our community’s past to better understand, with the benefit of hindsight, modern Agility and our possible futures.

Organized by Francis Delusong, I’ll share straight-forward answers to common questions people have about investing in Agile expertise and skills development.

RSVP Here.

This Salesforce community group provides opportunities to hear and learn different perspectives of Salesforce project delivery and implementation.

This event, hosted by Kira Systems was sponsored by AllCloud, Diabsolut and me.

Organized by Bob Frei and Khurshid Akbar, I’ll present new ideas to a contraverial topic. We will compare and contrast a vast variety of team structures; consider the constraints they impose on people and the flow of work; and learn strategies to change the work environment to better support Agile teams.

“I’m a BA, how should I contribute in an Agile team?”

“I’m an Designer, am I considered part of the Agile team or not?”

“I’m in a distributed team, is that okay?”

These are familiar questions. Team structures vary in every company. From remote-only to collocated and everything in between — from strictly segregated (BA, QA, Developer, Designer, Architect, DBA, etc) to fluid and self-organizing. Not all structures are equally productive and effective, and not all companies can support all team structures. For that reason, there are no correct answers to the questions above, and all valid advice must start with “it depends”.

If you listen closely, you might hear the faint echoes: “One solution to rule them all”, they said. “We’ll save millions”, they said. “We’ll launch the new system with just the push of a button” “The flick of a switch.” And some fool decided to name the new system Phoenix – it would “rise from the ashes” they said. What happened next, you ask?

It’s been an unbelievable catastrophe! Since the launch of Phoenix Payroll System:

• 2 federal elections have passed.
• A constract churn of executives.
• Billions spent.
• Billions more to go (not to mention a decade of litigation).
• The system still fails to deliver accurate payroll across the country.

The silver lining is knowing that all government officials agree that Phoenix is never going to work. They all agree it has failed. (Since when has our government unanimously agreed on anything?!) They do agree on this.

The proof? They’ve tendered an NPP (Notice of Proposed Procurement) for what they’re calling the “next generation HR and pay solution”.

Will they abandon and replace Phoenix? Will they surgically overhaul Phoenix? Is a new mega-project underway?

In this session, we examine the history of Canada’s Phoenix Payroll system, understand its current state, and — given what we know of the government’s track-record and recent policy changes — speculate whether the billions they’ll spend next will render any value for Canadians.

With Wayne Hetherington, and Farah Fallah, I presented at Agile 2019 in Washington D.C.

You’re a project manager and you’ve just been given an Agile project. You ask for reports and you get burndown charts, velocity graphs, and cumulative flow diagrams. What in the world are these?

Metrics are different in Agile environments, but the questions remain the same. Come and see what your brain needs to understand the tracking of products built in an Agile way. We’ll build an Agile dashboard that you can take into your next meeting.

Learn why standard metrics are not well suited for agile products; how to pick a good metric and focus on what you need to measure; what an Agile dashboard might look like for your next product.

Myth: “Agile teams don’t document.”

Truth: Agile teams produce excellent and valuable documentation.

This session is a sense-making workshop to simplify valuable documentation and reduce wasteful documentation. Agile Engineering practices have revolutionized the ways in which documentation is treated and produced. In high-stakes environments with heavy compliance and audit requirements, a tendency toward exhaustive documentation is dangerously common. This workshop provides direct guidance and simple tools to help a document-heavy workplace think differently about documentation.

Myth: “Agile teams don’t document.”

Truth: Agile teams produce excellent and valuable documentation.

This session is a sense-making workshop to simplify valuable documentation and reduce wasteful documentation. Agile Engineering practices have revolutionized the ways in which documentation is treated and produced. In high-stakes environments with heavy compliance and audit requirements, a tendency toward exhaustive documentation is dangerously common. This workshop provides direct guidance and simple tools to help a document-heavy workplace think differently about documentation.