Viewing entries in
Short Takes

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

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

Agile Software Capitalization...Boring!

Comment

Agile Software Capitalization...Boring!

One of the topics that I've typically avoided at agile conferences and in discussions with colleagues is software capitalization. Particularly in agile contexts.

The first reason is that it's usually used as an excuse to undermine agile principles and as a means of continuing old practices. 

The second is that I find it somewhat...boring. Yes, it's often necessary for many enterprise or larger-scale contexts. But I'd rather the teams focus on innovation, customer value, and deliver than on capitalization.

And the third reason, which is somewhat embarrassing, is that I never had a succinct recommendation for folks on how to handle it in agile contexts. I always felt that I said "it depends" too often.

Excuses

But all of those reactions were excuses. And I do realize that it's a serious topic for many folks. So, imagine my delight when I came across a real-world blog post from Stephanie Davis of Valpak in Tampa Florida that explained how they've been handling it. 

And not only that, the post contains some reference post that nicely provides additional capitalization examples and advice.

Wrapping Up

I've shared this post to be my "Go To" reference for capitalization. Thank you, Stephanie, for sharing!

Stay agile my friends,

Bob.

Comment

There IS an I in an Agile Team

1 Comment

There IS an I in an Agile Team

I’m beginning to think that we’re too focused on the team when we talk about agile. Everything is focused towards that end.

Team this and team that.

But what about the individual on the team? I contend that they count too.

  1. Make sure your voice is heard; in many team’s individuals can get lost. Often the loudest of voices seem to become the default voice of the team.
  2. Make sure you take time for yourself; self-learning, downtime / reenergize, reflection are keys to your personal growth and learning. Always increase your value proposition – you.
  3. If you’re introverted, give yourself permission to be alone; this includes working from home and “separating” from the team on occasion to work by yourself.
  4. Gain personal feedback; don’t get caught up in team-only feedback loops. While important, you need personal feedback as well. Make sure you’re getting it from your team and leaders.

1 Comment

My New Role – TechWell Program Chair

1 Comment

My New Role – TechWell Program Chair

I’ve been speaking at TechWell events since around 2000. First, I started out with track talks. Then I started sharing full-day and ½ day workshops. I’ve also been invited to deliver several keynotes at the Star and Agile Dev / Better Software conferences.

All-in-all, it’s been a professional relationship that I’ve really enjoyed.

Recently, the long-time program chair, Lee Copeland, stepped aside. I truly want to thank Lee for the years he invested in helping me grow this side of my consulting practice. I owe him a great deal.

Program Chair & Talent Scout

Given my history and experienced, TechWell approached me to help fill the Program Chair role for the:

  • Agile Development
  • Better Software
  • DevOps

Conference series going forward.

The conference has a West / East format. The West version is held in Las Vegas, typically in early June. The East version is held in Orlando, typically in early November.

The programs are usually developed 8 months in advance of the conference, so you need to reach out to me early if you’re interested in participating.

The program chair is responsible for pulling together approximately:

  • ~4 Keynote presentations
  • ~4 full-day workshops
  • ~20 ½ day workshops
  • ~60 60-minute track talks

across the four major themes (Agile Development, Traditional Software Development, DevOps) of the conference.

And the talent scout part of my role will focus on looking for new and interesting topics, speakers, and formats to introduce to the conferences.

1 Comment

Agile Planning – Getting Punched Every Day

1 Comment

Agile Planning – Getting Punched Every Day

There’s a famous Mike Tyson quote:

Everyone has a Plan
until they get Punched in the Mouth

It reminds me of the ultimate futility of estimating and planning. Or investing too much in both of those endeavors. Particularly in the area of software product development.

Another related quote is from Eisenhower. It surrounds the value of plans (artifact) vs. planning (activity):

I have always found that in preparing for battle that
Plans are Useless,
but Planning is Invaluable

That is:

  • The activity of exploring requirements via user stories and acceptance criteria;
  • The activity of minimizing (MVP) the results so as to learn;
  • The activity of making estimates as a vehicle to explore size, scope, risk, and design approaches;
  • The activity of discussing construction and deployment strategy;
  • The activity of delivering work to stakeholders and gaining their feedback.

Are all more valuable than fixed or static plans, which are intolerant of the punches that are inherent in software development - learning and discovery.

Wrapping Up

The next time you find yourself getting “stuck in” your plans or thinking that planning is more important than doing and adjusting, then please remember these two quotes. Also remembering, that Tyson and Eisenhower weren’t practicing agile software development. But they were indeed…agile.

Stay agile my friends,

Bob.

1 Comment

Just a little…Forgiveness

Comment

Just a little…Forgiveness

I was attending the STPCon conference in Washington, DC last week (week of September 25). As always, there were quite a lot of old friends there. Folks I usually only meet on the conference circuit.

The conference committee tried a Lightning Talk format for the first time. They invited 7-8 speakers on stage to give 5-minute, focused talks. Dot Graham gave one that is still sticking with me.

She focused on creating (fostering, inviting, inspiring, allowing) a mistake culture. One where everyone focused on two aspects of their mistakes:

  • Learning from them, and
  • Forgiving themselves for them.

I’ve heard the learning part many times before. But this is the first time that I’ve heard “forgiveness” mentioned as part of creating a learning culture and it struck me.

In a team environment mistakes always happen. Sometimes they’re small things. And other time, they’re large ones which have an impact on the entire team.

I have a saying that I often share in my coaching and teaching. I amplify that agile teams (all teams really) succeed and fail as a team. That is, we don’t throw anyone under the bus, but we deal with everything from the solidarity of a WHOLE TEAM perspective.

I now want to add other attributes to that description:

  • We reflect as a team;
  • We learn as a team;
  • We make mistakes as a team;
  • And we forgive ourselves as a team.

I love the Norm Kerth sentiments regarding the Prime Directive for retrospectives where he sets the stage for the “intentions” of all attendees.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

I think this sentiment helps us in our view towards mistakes and our forgiving each other (including ourselves) for making those mistakes.

I know that I for one can be really hard on myself when confronting the things I’ve done wrong.

As Dot reminded me, I want to encourage all of you in your agile journeys to be kind and forgiving of one another. Remember, they are ONLY mistakes and we all make them!

Stay agile my friends,

Bob.

Comment

DevOps Explained...Simply

4 Comments

DevOps Explained...Simply

I wish I could remember the young lady’s name. She was from a European DevOps tooling and consulting firm and she did an interview with me at one of the TechWell Star conferences. I believe it was StarWest at the end of 2016.

She was interviewing speakers to get their take on the implications of DevOps in agile, testing, and across software methodologies.

I recall vividly that she referred to DevOps as an evolutionary step beyond “agile” in nearly in every question she asked. And I told her I struggled with that idea. She was also very automation centric and extremely tools centric in her questions – referencing and emphasizing various DevOps oriented tools at every opportunity.

It’s not that I was defending agile. It’s that I have a very different view to DevOps and what it means than I was hearing from my interviewer. And I continued to explain and amplify my view in nearly every answer.

At the end of the interview, I felt that she understood my point of view. And that she had rationalized it against her own to create a more cohesive mental model for DevOps. I asked her to send me the link to the final interview, but to-date, I haven’t heard back.

And I continue to get questions during my coaching and consulting around DevOps, so I was inspired to write this post as a means of sharing my views.

4 Comments

You might be an agile leader if...

13 Comments

You might be an agile leader if...

I've been invited to do a keynote at the Agile Development, Better Software, DevOps conference in Orlando in November. 

The abstract for my talk is:

In case you haven’t heard, the leadership landscape has been changing—and continues to change—to keep up with the accelerating pace of business. And agile development has been an incubator of new leadership approaches. It has introduced or fostered many innovative concepts: servant leadership, self-directed teams, empowerment, emotional intelligence, employee engagement, trust, self-selection, open spaces—and even Lean Coffee “meetings.” Channeling comedian Jeff Foxworthy, Bob Galen shares patterns and anti-patterns that surround the leadership shift to more agile tactics and the mindset that many leaders face and often struggle to adopt. Having personally endured the massive change of becoming an agile leader, Bob shares his journey and discusses how you can tackle your new role—the tactics you’ll need to change, the stance you’ll need to assume, and the role models you’ll need to leave behind. Bob explores the new lean, value-based delivery perspective that provides the right focus for delighting your internal and external customers. Prepare to have your mind blown a bit—and never again think of leading in the same way.

Request

I'm looking for help in constructing my keynote. If you have an idea to fill in the blank:

You might be an Agile Leader if ___________

Please add a comment to this post. I'd be incredibly appreciative and you might get your idea woven into the final keynote. I'll even send you a link to the keynote video if you want to see your idea "in action".

Thanks so much and stay agile my friends,

Bob.

13 Comments