Agile Police or Ambassadors

What do some vegetarians and some agilists have in common? It sounds like the setup of a bad joke, doesn't it?  Actually, some believe their practice is best and you are wrong for doing things differently.  Well, at least that's my first hand experience. Over the weekend, I overheard a conversation while we were dining out.

So-and-so isn't a real vegetarian. She eats fish.

It was a little deja vu to me.  Just days earlier I overheard a similar conversation.

So-and-so isn't really doing Scrum.  They use a Product Owner team.

So, what's our deal?  Should I stop eavesdropping on people or should we address why we get so protective of what we think of as a textbook example of something?  Who's keeping score?  There seems to be a fear the vegetarian police or the Agile police are going to be knocking on doors any day, demanding people stop saying they are vegetarians or agilists.  Sure, I get it. You're disciplined. You're passionate about being a vegetarian or passionate about Scrum. But why do we have to be police and not ambassadors?

Vegetarians

A vegetarian diet is derived from plants, with or without eggs or dairy. Varieties include: Ovo, Lacto, Ovo-lacto, Veganism, Raw veganism, Fruitarianism,...  Those with diets containing fish or poultry may define meat only as flesh from a mammal and may still identify with vegetarianism.  Vegetarianism can be adopted for different reasons, including objection to eating meat out of respect for critters.  Other reasons include religion, health-related, it looks cool, can't afford it, or plain old personal preference.  At the end of the day, to each his or her own.

Agilists

An agilist believes in a set of values and principles (originally for software development) in which requirements and solutions evolve through collaboration between members of cross-functional teams. These teams pull work from a prioritized backlog and provide a demonstrable product increment on a regular interval. It promotes value focused adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. Agile methods can be adopted for different reasons, including the solution is not yet fully defined, our organization says we're going to follow the practices, we accept the mindset, or it looks cool.  In the end, the framework or methodology really doesn't matter. 

Commonality

Before you go off and point your finger at someone and claim they are not a real vegetarian or agilist, stop and think about why they are doing either.  In the end, why are you doing it?  Often, I see the similarities will outway the differences. I see many wanting to benefit from a practice but then have to operate within a constraint. I think that's what prevents many of us from being extremists and I'm quite happy with that.  I actually like the diversity.

Perhaps there should be a 13th principal added to the manifesto.

13.  Acceptance of similarities of practices over judgement of differences

As noted earlier, we need a lot fewer Agile police and a lot more Agile ambassadors.

Correct Context for an Agile Transformation

A few weeks ago, I spoke at the Heart of Agile conference up in Philadelphia. The conference was a two-day conference dedicated to educate attendees on Alistair Cockburn’s new methodology, The Heart of Agile. The Heart of Agile is focused on getting back to the basics of Agile. In the last 15 years, Agile has been weighed down with frameworks and practices of many shapes and sizes. At the Heart of Agile are 4 key concepts: Collaborate, Deliver, Reflect and Improve. From this center we can branch out to all of the principals, practices, skills, and tools.

The two-day event offered:

Opening and closing keynotes by Alistair Cockburn focused on the “Heart of Agile” Speakers - presentations and discussion tracks for Collaborate, Deliver, Reflect, and Improve: Tutorials - Speakers provided presentations and facilitated conversations on hot topics and key trends on Agile principles and practices. This was an opportunity for experienced practitioners to demonstrate and share their knowledge in a specific topic, solution, or technique. Collaborative Conversation - Joint problem-solving with other experienced participants in a topic. A facilitated peer-to-peer event, where everyone had something to contribute to the topic, though may not have been an expert at the topic. The coordinator proposed a topic and a facilitation structure, the attendees worked in small groups (typically 4-8 people), and mutually exchanged and collaborated their outputs. Experience Reports – Experience reports contained first-hand information and reflection: “We saw this…,” “Our team did that…,” or “We learned the following from our experience…” Experience reports served as an exchange opportunity for practitioners to learn from others. Focus of these discussions was to share successes, failures, and lessons learned. Open Space – Ongoing facilitated discussions of topics that were suggested by the attendees.

Experience Report

I was asked to present a report on one of my recent experiences.

Instead of presenting the below embedded deck about the correct context for an Agile transformation, I drew everything on a flipchart. If you know your content, you don't need a PowerPoint deck! I wanted to make the original presentation available for others who were not in the room (and those who were).

Correct Context for an Agile Transformation

If there is one question I would ask, to know if you should view/download this presentation, it would be: Are you exactly like Spotify?  If you are not Spotify or your company business goals do not align with Spotify, then this would be a good presentation to view or to talk with me about.

Get a free copy of the presentation from Derek Huether

Lean Agile Startup Technology Unconference

Background

On October 12th, Hillel Glazer and I hosted our first Agile Baltimore Unconference. Sure, there are other Agile events in the area but I really wanted to create something that was independent and "felt" like Baltimore. The result? The first Agile Baltimore Unconference! I wanted to organize an event that would provide value to both the sponsors and the attendees, at a reasonable price. With less than five days remaining, the event was sold out with 100 attendees.

As part of the registration, we provided an event t-shirt (thank you smartlogic for the t-shirt design and sponsorship). The t-shirts came out great. The Agile Baltimore logo was on the chest and the event sponsors were proudly displayed on the back, with a skyline of Baltimore. It was top-notch design work and printing.

Food was supplied by Sunshine Gille. They provided, breakfast, lunch and cocktail hour. I'm sure others would agree, the Greek lunch was pretty damn good. If you're local to Baltimore, I recommend you look them up for your next event. They were really friendly and easy to work with.

Schedule

So, what is an unconference?

A loosely structured conference emphasizing the informal exchange of information and ideas between participants, rather than following a conventionally structured program of events.

You might have read my blog post back in August, titled Divergence at Agile2015. If I wanted to structure a traditional conference, there would have been a ton more time spent planning the tracks and schedule. For this event, I wanted to focus on getting people to share ideas around the themes of Lean, Agile, Startups, and Technology. I honestly do not believe anyone could say what the most important topics could be 1-3-6 months out. Having the attendees plan out the schedule the day of the event would ensure we would have the more relevant topics.

Never underestimate the power of self-organization. In the first hour and a half of the event, we took somewhere between 300 and 500 ideas and narrowed it down to 9.  If you want to see some great pictures of this in action, click on the picture links below.

Sponsors

When putting this event together, I had a choice. I could charge attendees a lot more money or get some sponsors. After doing some quick math, I realized that we needed sponsors. That's a blog post all on its own. Get too many sponsors and too few registrations and I could forget ever having another event. My goal was to have sponsors who I personally like. I did not want sponsors who would create a local turf war. Of course, I wanted Agile Alliance on board. Done. ETC Baltimore was helping us with the space. Done.  Smartlogic approached us about doing the t-shirt designs and printing. Done.

What was left? Breakfast, lunch, the after-party, lanyards, and enough post-it notes and sharpies to satisfy the needs of a small army of Agilists. Thank you very much to Rally Software and Leankit, both of which had booths and gave product demos.

To underwrite the event, LeadingAgile was there every step of the way. When we needed to write a check for food and not all of the sponsor checks had arrived, it was great to know LeadingAgile had my back.

Photos and Videos

Photos

Photos were saved to the Agile Baltimore Facebook photo stream.  You can see even more out on the Agile Baltimore Lean coffee meetup site.  If you were at the event and took pictures, please send me a copy!  I'll get them posted.

Videos

This was my first real attempt at videography at an event. I used Periscope to do some live streaming on Twitter.  I then saved the videos out to the [Derek Huether YouTube channel]. Periscope won't let you record with a landscape orientation yet so you'll just suffer through the black bars on either side of the videos.  In the video below, you can see an exchange between Mike Cottmeyer, Paul Boos, and others about buy-in techniques when trying to go Agile. Paul Boos is heard saying "Something that promotes individual heroes is an impediment" [YouTube Video]

Summary

Never be afraid to try something you've never done before. I have a newfound respect for those who put on events. It can be exhausting! My heart goes out to the Purple Shirts that I see each year at the Agile20xx events of the Agile Alliance. I wasn't wearing a purple shirt but I was super busy doing behind-the-scenes work. Upon doing a retrospective at the end of the day, I would consider some changes next time around.

• I would like to see lightning conversations or maybe an entire track dedicated to Lean Coffee

• I would like to offer a coaches corner, where attendees could go ask a qualified coach for some help

• Lastly, ironically, I would consider adding a planned track.

Keep your eyes open for the next event. I doubt I can wait an entire year to do this again. Maybe we can do this in Denver or Atlanta? Maybe we can do a half-day Lean Coffee event?

Agile Zombies - Fight the Dead. Fear the Living

Inspired by artwork by Pictofigo

Barriers to Agile Adoption

We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks. Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most. I recently had a client ask me to introduce the elephant in the room. I was asked to actually list some common barriers others have dealt with. I want to thank our friends over a VersionOne for distributing an annual survey of the Agile space. One of the questions? What is preventing you from further agile adoption? Within the last published survey, 4048 people responded and they were able to vote for more than one barrier. The responses may sound familiar.

Barriers of Agile Adoption

[table align="center" caption="" width="500" colwidth="25|25|450" colalign="center|center|left"] #,Percentage,Barrier 1,52%,Ability to change organizational culture 2,41%,General resistance to change 3,35%,Trying to fit agile elements into non-agile framework 4,33%,Availability of personnel with right skills 5,31%,Management support 6,26%,Customer collaboration 7,26%,Project complexity 8,22%,Confidence in the ability to scale 9,14%,Perceived time to scale 10,14%,Budget constraints [/table]

Did they miss any in the list?  How did you overcome your barrier?

Originally posted at LeadingAgile

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal

• (Optional) representative(s) from the Management Team – clarify the high level priorities

• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items

• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team

• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research

• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

How to be Successful with Agile at Scale

Ever asked yourself how you could be successful with Agile at scale? Let me show you how we've done it at LeadingAgile. In this one hour session that I presented to the PM Symposium in Washington DC, I explained how we've been successful by focusing on culture last and predictability first.

New Agile Training Classes Announced

Though I've been doing Enterprise Agile Coaching with LeadingAgile for over a year now, I haven't been doing a lot of training (or blogging).  I've been sticking to agile transformation work and the occasional private class.

Well, it's time for an update.  Dennis Stevens and myself co-authored the International Consortium for Agile (ICAgile) Agile Project Manager learning objectives back in February.  The result was a solid certification even a PMP could respect.

New Classes and Locations

LeadingAgile has decided to offer more public training.  We're offering classes in Atlanta, Denver, Orlando, and Washington DC.

Scrum

Certified ScrumMaster certification class

Certified Scrum Product Owner certification class

PMI

PMI Agile Certified Practitioner (PMI-ACP) certification prep class

ICAgile

Fundamentals of Agile (CIP certification awarded)

Agile Project Management (to be announced)

---

Are in interested in some public training?

Send me an email and I'll get you a special discount code.

---