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

Meta-Cast LIVE @ Red Hat Agile Day 2017

Comment

Meta-Cast LIVE @ Red Hat Agile Day 2017

Josh and I were invited to deliver a live version of the Meta-cast for Red Hat Agile Day this past October.

Here's the description of our session:

The “Meta-Cast” Comes Alive

Since 2011, Bob Galen and Josh Anderson have been recording the Meta-Cast podcast. It’s an agile focused discussion that has literally covered every agile topic in its seven years and over 120 episodes. The podcast reaches listeners on virtually every continent and has received numerous accolades from listeners and fellow podcasters alike. In this session, Bob and Josh will be bringing the Meta-cast to you, a live audience. The podcast will be recorded and streamed live. We will gather your most challenging, interesting, and potentially exasperating agile questions and challenges. Then we’ll answer each of them with our collaborative and fun style. This session will prove to be fun, insightful, and driven by YOUR needs. So please, join the Meta-cast and try to “stump the chumps” or simply get some free coaching towards your greatest challenges.

Here's a link to the video recording of the session: https://bluejeans.com/s/MWMJy

And here's a link to the associated Meta-cast: http://www.meta-cast.com/2017/10/episode-122-red-hat-agile-day-q-session.html

Hope you enjoy it! We hope to do a similar session at future conferences. 

Stay agile my friends,

Bob.

Comment

2017 Agile Dev + Better Software - Tricentis Interview

Comment

2017 Agile Dev + Better Software - Tricentis Interview

I met a colleague, Noel Wurst, at the Agile Development conference. He's now working for Tricentis and he asked me to do an interview for their website content. Of course, I agreed.

I thought I'd share my replies to his questions. And I want to thank Noel for asking me. It was an honor to contribute...

Here are the interview questions that Noel asked and my replies:

1. Continuous feedback: I hear a lot of people talking about needing to shorten feedback loops, automate reporting, and development, test, and release cycles that deliver continuous feedback. And I agree. CF is highly valuable. But sometimes I wonder if, once people put those things in place, can they immediately act or respond to that feedback? How important is being able to do that, and not just collect or note that feedback, but adjust on the fly to make new decisions, pivots, and responses continuously as well?

I think this is a really important point, Noel. And it’s not simply related to continuous feedback, but also to the continuous improvement cycle. For example, feedback on adjustments that are raised in team, project, or organizational retrospectives. To your point, our lean-age should be towards doing something about our discoveries, in taking action.

Comment