Viewing entries in
References

Descaling Manifesto

1 Comment

Descaling Manifesto

To be honest, I’ve been aware of and admiring Peter Merel and his work for quite some time—perhaps more than 10 years. That said, I haven’t been a consistent follower, and as I re-reviewed the Descaling Manifesto, he proposes within the XSCALE Alliance, I realized the great work he’s been doing in the agile community. Purposeful and vital work that strikes at the heart of a truly agile mindset and better ways of leading, organizing, and working.

My purpose in writing this post is to acquaint you with Peter, the alliance, and the manifesto. It also encourages you to do a deep dive into everything on the Alliance site looking for new ideas, tactics, and approaches to your scaling challenges. Perhaps in a word, leaning into descaling.

I plan on doing that myself, so look for a more detailed future update sharing my thoughts.

And a Conference!

Finally, I was excited to see Peter planning a virtual conference from October 25th – 27th. I plan on attending to reinvigorate myself, and I hope to see you there too. You can find more info here –

https://www.linkedin.com/posts/petermerel_home-activity-7095253127490121729-Z9Tc

Here’s to descaling. Stay agile, my friends,

Bob.

Oh, and by the way, I just signed the Manifesto. Better late than never I always say…

1 Comment

Standish and other Oracles

1 Comment

Standish and other Oracles

I’ve been seeing these surveys and statistics reference around The Chaos Report for nearly two decades. Often, as in this article here, they are used as citations supporting agile ways of working. And since I’m an aglist, you’d think I would be in full support of them. But I have three core problems with the reports themselves and the incessant quoting of them to support some position.

Trust?

First, I’m not sure I trust the data. Where does it originally come from AND are the collections accurate?

For example, I used to fill in project timesheets at the end of each week. I filled them in with the best recollection I had and with my perception of time spent. I realized over time that I was probably only reporting at 50% accuracy. And that was as an individual contributor. Aggregate that data over 100 developers over 1-+ projects every week. Would you trust what that data was telling you?

So, rolled-up statistics collected from a wide variety of companies doesn’t always make me that trustful and confident in the data.

1 Comment

Distributed Agile Teams

Comment

Distributed Agile Teams

There are literally three things that come up in any of my training adventures—

  1. How to handle estimates and forecasting with fixed-date projects?

  2. What are “Good” agile metrics?

  3. How to be “Agile” with distributed teams?

I thought I’d explore the last question on distributed teams in this post by listing some references that you might find helpful.

First, I think the Jutta Eckstein was the first author in this space. She wrote—Agile Software Development with Distributed Teams: Staying Agile in a Global World in 2010 and updated it in 2018. She was probably one of the first folks who started sharing her experiences in distributed agile and her work has stood the test of time.

Next, Johanna Rothman and Mark Kilby have written perhaps the most complete work on the topic in agile contexts. From Chaos to Successful Distributed Teams: Collaborate to Deliver is an incredibly useful look at how to make distributed teams work in agile contexts. Written by two seasoned coaches from their work in the real world. And here’s an Agile Alliance article they wrote about collaborating on the book.

And here’s Johanna and Mark’s contribution to Comparative Agility’s assessment tool.

Comment

Product Roadmapping

1 Comment

Product Roadmapping

I’d like to start off this post with the following excerpt from the ProductPlan website. I think it sets the stage of things quite nicely: 

“We’re agile, so why do we need a long-term product roadmap?” I hear this question regularly. At first blush, the terms agile and product roadmap seem like a contradiction, but they’re not. In fact, you should have an agile product roadmap.

In most agile product development organizations, the backlog is used by the development team to track what’s coming next, at least for the next few sprints or iterations. Many agile teams rely heavily on the backlog, as it maps out short-term initiatives. But the backlog in itself is not the roadmap. This post explains why you need both.

Product Roadmap vs. Backlog

A product roadmap is different from a backlog. The roadmap defines a strategic view of where the product is headed over the mid to long term, whereas the backlog defines the product features and initiatives for the near term. The roadmap is tied to the organization’s vision and strategic goals, often for the next 12 or more months. In an agile organization, the roadmap provides guidance rather than a strict project plan. 

I also sometimes equate the word Portfolio with Product Roadmap. In my mind, the two are quite synonymous.

1 Comment

Scrum Product Ownership, 3'rd Edition

3 Comments

Scrum Product Ownership, 3'rd Edition

Hi everyone,

I just wanted to share some great news. I’ve just completed the 3’rd Edition of my Scrum Product Owner book.

It’s been a true labor of love that’s taken far longer to finish then I’d originally expected. (sounds like software products, right?) But, to quote a common agile phrase…I am now…

DONE.

Stick a fork in it, Baby!

E-copies (PDF, EPUB, and MOBI) are all available immediately on LeanPub. What’s nice about connecting via LeanPub is that I plan on continuing to evolve content & ideas in the PDF, so it will be a way to “stay in touch” with any future developments of the books’ themes.

Also not that I’ve published several short PDF, blog link books that make it easy to explore my blog posts on 3-specific topics:

  • Agile Coaching

  • Agile Leadership

  • Product Ownership

More information on ALL of the LeanPub copies can be found here: https://leanpub.com/bookstore?search=Robert%20Galen

Amazon

You can find the paper version here: https://www.amazon.com/dp/098850264X/

And the Kindle version here: https://www.amazon.com/Scrum-Product-Ownership-Navigating-Forest-ebook/dp/B07PBGN5NW/

And here’s a link to my Amazon author page: https://www.amazon.com/kindle-dbs/entity/author/B00287V534/

Previous Owners Offer

I’d like to make the following offer for ALL Edition 1 and Edition 2 book owners. If you’ve previously purchased a paper or e-copy of my two previous editions, I’ll give you a free e-copy of the 3’rd Edition. All you have to do is drop me a note and I’ll forward you a coupon for LeanPub to get your copy.

Wrapping Up

It’s been a long time in coming, but I’m incredibly pleased with the results. I hope you pick up a copy of the new book and hope even more so that it provides value to you.

And if you do read it, please consider leaving a review on Amazon. It means so much to me to gain feedback.

Stay agile my friends,

Bob.

3 Comments

Making Technical Debt, well…Visible

Comment

Making Technical Debt, well…Visible

Julee Everett and Ryan Ripley shared a wonderful article on making technical debt more visible. In that article, they focus on visual metrics that illustrate progress in cleaning up debt.

I’d encourage you to read it.

Inspired!

The article also made me think a bit about my own experience with technical debt and how to influence the organization to take it more seriously. Here are some advice tidbits to make your technical debt more visible –

Comment

Recommending Lean Agile Intelligence

Comment

Recommending Lean Agile Intelligence

February 5, 2018

I’m experienced enough in the Scrum community to remember several early attempts at assessing the maturity of agile and Scrum teams.

My point in taking you down “history lane” is that agile assessment tools and frameworks have been thought about since ~2007. So, for the past 10+ years.

The problem is, that none of these, and the ones introduced later, have really done an effective job of helping teams improve.

Comment

Software Endgames 15 Years Later – A Thoughtful Review

Comment

Software Endgames 15 Years Later – A Thoughtful Review

In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.

This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.

I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes. 

Comment