GO EAGLES!

1 Comment

GO EAGLES!

I’m originally from central Pennsylvania, having grown up on a farm in Lancaster County. We were about an hour and a half from Philadelphia. And you couldn’t help but connect to the local Philly teams.

The Eagles are one of those teams that always seemed to struggle, yet the local fan base is incredibly loyal to them. Disgruntled, complaining, obnoxious, whiney, but still loyal. And I am one of those diehard Eagles fans.

Now I moved away from Pennsylvania in the 1980’s. But my heart is still with those sports teams. So, you can imagine how I felt when the Eagles won the 2017 Super Bowl.

Elated, surprised, justified, humbled, fulfilled are some of the feelings that came to me.

1 Comment

3 Key Agile-centric Metrics

Comment

3 Key Agile-centric Metrics

My friend and colleague Shaun Bradshaw and I were coaching at a client recently. We started to have a conversation about velocity, not directly driven by the clients’ context, but simply in general.

Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management. And I was struggling to “get there”.

Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:

  • Velocity gaining stability over time (predictability, low variance)
  • And increasing over time (short-term burst)

As part of newly formed and/or newly coached agile teams.

Now I really get what he was saying. And I agree that teams in these contexts should be displaying activity and behavior towards those two results.

Comment

Communicating with Metaphor’s

Comment

Communicating with Metaphor’s

One of the things that I’ve come to value in my agile journey is our local Raleigh / Durham agile community. It’s one that I’ve had a hand in creating and guiding over the years. But one that’s taken on a life of its own.

I can’t tell you how many wonderful agilists are here in my local area. Some are:

Mary Thorn, Josh Anderson, Ken Pugh, Jason Tanner, Laurie Williams, Agile Bill Krebs, Andy Hunt, Ken Auer, Catherine Louis, Cory Bryan, Jeff Barschaw, Tom Wessel, my colleagues at Zenergy Technologies, and the leaders of our local AgileRTP and ALN groups. Literally, we have a community of thousands in our Meetup groups and our local TriAgile conference draws 500+ folks annually.

www.triagile.com

A couple of other local folks that I want to call out are Laura Burke Olsen, Arjay Hinek, and Matt Phillips. They are collaborators in a group/website entitled Collaboration Explored. It is a website focused on Collaboration inspired by the late Jean Tabaka. I think it’s wonderful that these folks (and others) are continuing the work that Jean inspired.

Comment

Bob’s 8-Rules of Agile Architecture, part-2

1 Comment

Bob’s 8-Rules of Agile Architecture, part-2

In the first part of this post, we explored these “rules”:

  1. Allow Architecture to Emerge
  2. Treat it Like a Product
  3. A Picture is Worth…
  4. Everyone IS an Architect and Everyone OWNS the Architecture

Now, I’d like to continue sharing the final set of four rules for your consideration in your agile architectural travels.

#5) Keep it Simple and Connect to the Customer

This one is quite near and dear to my heart. Why might you ask? Because I really like complexity. I like engineering complex solutions to simple…complex customer problems. And it’s also quite comfortable for me to fall into that over-engineering, gold-plating, doing more than is required mindset.

Why?

1 Comment

Bob’s 8-Rules of Agile Architecture, part-1

Comment

Bob’s 8-Rules of Agile Architecture, part-1

Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am.

Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture “fits” in agile contexts.

In no particular order, here are my guidelines:

#1) Allow Architecture to Emerge

I know you’ve heard this before, but it’s really, really important. The difference is moving from traditional architecture, which –

  • Performs Big Design Up Front (BDUF), aka Big Bang;
  • Develops a “complete” architectural concept before coding begins;
  • Approaches construction horizontally, with delayed layer integration

Comment

The 4-KEYS to Effectively Working with Distributed Agile Teams

Comment

The 4-KEYS to Effectively Working with Distributed Agile Teams

My first piece of advice is this:

DON’T DO IT!!!

Probably the worst possible setup for “team” is spreading them around the country or the world or the universe and expecting them to behave and deliver like a close, cohesive team.

My second bit of advice for those of you that blame it on “Management” and say you don’t have any say in the matter…is:

WRONG, YOU HAVE LOTS TO SAY IN SUSTAINING DISTRIBUTED TEAMS OR CREATING ANOTHER STRATEGY!!!

I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it. That is but complain about it.

I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:

Key Takeaways

  • Team structure reflects in product architecture
  • Distributed teams can perform pair programming by using some remote pairing techniques and tools.
  • Microservices influence a good distributed team structure
  • Increase co-ordination within a team by encouraging T-shaped engineers
  • DevOps tools and practices are valuable for Distributed Agile Teams
  • Increase efficiency of Continuous Integration and automation testing in distributed teams by using cloud

While the article is titled and implies a focus on culture, it really focuses more on technical tactics or tooling as the key to distributed teams.

Comment

How does "Documentation" Fit into Agile?

Comment

How does "Documentation" Fit into Agile?

I've been teaching, coaching, and speaking about agile approaches for over 15 years in conferences all over the world. 

In that time, there are a set of questions that everyone seems to be concerned about. I think the top 5 might include the following:

  1. What tools do you recommend we use for tracking our teams?
  2. How do we estimate fixed scope / fixed time projects with agile?
  3. How do I fit my current metrics / KPI dashboard into our agile teams?
  4. Do you really need a ScrumMaster and/or Product Owner? And if so, what do they do?
  5. How does documentation work? We're in a regulated environment and agile doesn't support documentation.

And as time goes on, the frequency of the questions hasn't really declined. So, they're still relevant and indicative of things folks are grappling with in their understanding of agility.

A week or so ago I came across a blog post from Angela Wick entitled - Agile Requirements Documentation - What's Really Needed?

It's the most cogent and common sense answer to #5 above that I've ever seen. And if you know me, when I reference another blog, I usually have something to add or a point or two I disagree with. With Angela's piece, there wasn't a point I couldn't agree with.

It's now my "Go To" reference for folks who are struggling with the questions around -

  • What are agile requirements documents?
  • How much is enough?
  • What to write and what not to write?
  • What should be the focus? 
  • Who writes it?

and any other questions from my clients. Please read her entire blog. You'll find insights and value that will be helpful in your agile journey!

Stay agile my friends,

Bob.

 

 

Comment

The “1” Thing

Comment

The “1” Thing

I was facilitating a full-day Leadership Summit at the Agile Development conference in Orlando in November.

There were ~70 leaders in the room and I wanted to surface their expectations for the summit so that everyone could understand the most important topics to the entire group.

I decided to do an exercise called “The 1-Thing” in homage to the movie City Slickers. I asked each table group to:

  • Pick a facilitator;
  • Have each table member write down the 1-thing they would like to learn from the workshop. I.e., their #1 challenge, question, or interesting topic;
  • Then the facilitator would collect all of the 1-things from their tables;
  • Next, each facilitator would read all of the 1-things;
  • Finally, we discussed as a group, the major themes we heard. We found about 10 compelling themes to keep an eye on.

Comment

My Heros: Rob Sabourin

Comment

My Heros: Rob Sabourin

There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.

I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.

The third one up is: Rob Sabourin

Rob is a stalwart in the testing community. He's been talking about software testing for, what seems like, forever. He has a real passion for all aspects of testing. While I've traveled and done similar work to Rob in the software testing arena, I can't hold a candle to the depth, breadth, and real-world applicability of his experience. 

He's affiliated with McGill University and has facilitated quite a few research projects over the years. So, he's giving back to students and to our community as well. Sometimes I've wondered how many people have been influenced (for the absolute better) by Rob. I can't even imagine the numbers.

If you've ever attended a talk, workshop or another session format by Rob, a few things always stand out:

  • His passion and energy just blows you away;
  • His encyclopedic knowledge of the subject matter;
  • And his sense of humor, with a unique ability to "connect" with his audience.

all make Rob a unique and valuable gift to our community.

I Am A Bug

In 1999, Rob published a book with his daughter Catherine that explained the craft of software testing to everyone, including children. Years ago I used to buy copies of it as gifts for testers on my teams who had young children.

While I kid with Rob that he really should have written (write) more books, I am a Bug is truly unique and a classic gift to our testing community. 

When I "met" him

Around 2001-2 I started working on my first book - Software Endgames. It was later published in 2004. I was new to the community and I was aware of him by his reputation and interests. One of the common interests we had was defect workflows, triage, and generally how to effectively handle bugs in software projects. This was one of the main themes of Software Endgames, so I thought I'd ask Rob to review my manuscript.

While I didn't know him personally at the time, I thought, what the hell, all I could do is ask. So I sent him an email introduction and a copy of the manuscript. He immediately replied and agreed to give me some feedback.

2-3 weeks later I received a VERY detailed, chapter by chapter, review of Software Endgames. It was feedback beyond my expectations and incredibly helpful. Rob also sent me encouragement that the book added value to the community and that lifted my spirits to continue in the books finalization process.

To this day, his incredible generosity in taking the time to help and support a total stranger sticks out to me.  He made Software Endgames and me far better for the experience. And the example.

WRAPPING UP

One of the defining aspects of my heroes is that they’ll probably be embarrassed to be categorized in that way. Nonetheless, they are my heroes.

They’ve helped me to become the person, trainer, speaker, and coach that I am today. Whether they’re aware of it or not.

Rob Sabourin, you've shown me what it's like to be a professional. To maintain your energy and passion around doing what you love. You've also been a role model to me. I've learned much by simply watching you work. Not only in front of a class, but as an individual. Your generosity in helping me with my book has stuck with me. And encouraged me to "give back" to folks as much as I can.

But beyond my accolades, I consider you a colleague and, most importantly, a dear friend. It's this that I'm most proud of and humbled by. 

I’m incredibly blessed to know you and want you to know that you are my Hero.

Stay agile my friends,

Bob.

Comment