Overcome the 6 Traps of an Agile Transformation

We were fortunate to have David Hawks of Agile Velocity speak at our Dallas October meeting–it was a great session! Accelerating learning is the key to unlocking the true potential of Agile, and David shared the 6 traps agile teams fall into which prevent learning and how to overcome them. Often organizations implement the process aspects of agile/scrum but fail to find the key to unlocking its true potential. His slides on “Overcome the 6 Traps of an Agile Transformation” can be found on slideshare:

How to handle [fill-in-the-blank] work in Scrum

As more teams are adopting Scrum around Dallas, I’ve been hearing more questions about how to handle work that is not specifically requested by the Product Owner.  How do you handle production support issues in Scrum?  How about technical debt?  How do you plan time for research?  How do you manage defects?  According to the Scrum Guide, “the Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases,” but what does that look like in execution?

Our September Dallas meeting was an open discussion for folks to bring their questions and share experiences about how to deal with all of the work that doesn’t fit so neatly in a Product Backlog.  We ended up with NINE topics:

  1. Dependencies on infrastructure teams
  2. Dependencies on waterfall teams
  3. Dependencies on external vendors
  4. Hybrid work — agile + waterfall
  5. Unable to finish stories because of multiple opinions/committee
  6. Date-driven + fixed scope + fixed budget challenges
  7. Production support
  8. Multiple projects/changing velocity from one project to the next
  9. Supporting multiple apps/products

Since there were so many topics, we held two rounds of small group discussions and reported out learning after each round.  It was a productive and engaging meetup, and the comments afterward were great:

  • I had a great time and learned some valuable insights from fellow scrummers.
  • Best experience [at the meetup]. Gained lot of insight.
  • Great breakout sessions and helpful recommendations. Allison, thank you for facilitating.

Thank you to everyone who attended and made it a rich evening of learning!

Three Thoughts From August’s DFW Scrum Meetup

This writeup comes from Quentin Donnellan who originally posted it on his blog on August 18, 2015. 

I’ve got a flight to Kansas City to meet the SpiderOak marketing team tomorrow morning, so I’ll make this quick! I just got back home from my first DFW Scrum meetup, and I highly recommend it to any software guys in the area (they meet on the 3rd Tuesday of each month, in Addison and Southlake concurrently).

I had originally planned to fly out to Kansas City late tonight, but a couple weeks ago I noticed that this meetup group was going to be hosting a talk on “Release Process” and figured, as I’ve been tasked with the role of release manager for the SpiderOak web team, this would be a hugely beneficial experience. It was.

You can find the presentation by William “RED” Davidson in full on the group’s Meetup page; I wanted to just mention a few things that stuck out to me during the course of the talk/discussion.

1. Jeremy wants to do…

One of the early slides Mr. Davidson showed us was a picture of some dude’s face, and this sentence below it: “Jeremy wants to do…”. The point was that when coming up with user stories, you shouldn’t put them in terms of some ambiguous “user” (i.e. User needs to select X from Y on page Z), but instead think about it in terms of what actual people need to do. “Jeremy needs to do this thing on this page”. And add a huge picture of a person’s face. Seriously; thinking of your “user” as actual people (with real faces) is powerful.

2. Sit down with your customer while they use your product.

One gentlemen in the room made the very awesome comment that, if possible, you should sit next to one of your customers while they use your product. That’s awesome advice. For those of us out there who build internal tools for our respective companies, this is a very simple thing to do. While I’m in Kansas City let’s see if I can’t get my team member to work on the CMS I built for them – just by watching how they interact with the thing will tell me more than any feature request ticket that they could come up with.

3. Three-legged stool

One of the big ideas from Mr. Davidson’s talk was that a release process (and the development process in general) is a 3-legged stool:

  1. Deliver Value & Delight
  2. Improve Product & Processes
  3. Develop the Team

His point was that if you focus too heavily on one of the “legs” (or not enough on one) then you stool become unstable. There was also a sage comment made by another member of the group that went something like this: it’s likely the stool will “wobble” – though it should be a goal to not let the stool fall over, as it were.

There were many comments from leaders among the group about how they were guilty of ignoring some/one of the legs themselves.

Wrap up

In all, I’m very glad I decided to take an early flight out tomorrow so that I could make the trek over to Addison to meet with the DFW Scrum group. I met some good people and definitely learned some valuable things. I highly recommend this group to area developers and will definitely be making it over to my next meeting.

Note: I don’t use Agile/Scrum currently – but I did get a ton of utility out of this talk.

Developing Your Facilitation Skills

I’ve been talking to a number of Scrum Masters recently, specifically about their retrospectives.  They don’t know how to handle the group dynamics comfortably or how to design a fun yet productive meeting or how to deal with the issue that no one wants to bring up.  And as I talk with them about ways to address these, I remember my own path as a Scrum Master and how I grew my facilitation skills: I had experience facilitating meetings from college, I took training workshops after I graduated, and I read and applied what I read intently for each retrospective over a couple of months.  Planning and executing retrospectives became part of my craft, and I am thankful that I learned it because it has paid off tremendously in helping teams and Scrum Masters get better.

If you want to develop your facilitation skills, the Agile Coaching Institute is offering its Agile Facilitator class in Dallas on November 12-13.  It’s a wonderful course that provides techniques and practice–I attended it last year and came away with some new ideas on how to plan meetings that has been really beneficial!  For more information about the course, please visit the Agile Coaching Institute website.

Technical Excellence Takes Discipline

Scrum is the most popular agile framework, and part of what I like about Scrum is that it is elegant in its simplicity and does a great job of making things visible. And after years of seeing Scrum implemented in various organizations and talking to others in the industry, it’s clear that technical excellence is too often neglected by Scrum teams. As an Agile/Scrum Coach, I think it’s important to talk to teams and managers about more than what Scrum alone defines–we must have conversations about other practices and ideas to address the stuff that Scrum has made visible.  Technical practices must be in those conversations, regardless of our own technical backgrounds.

It seems like teams can create technical debt faster in agile than they did previously if they are not following good technical practices. Practices that ensure we are building the code right so it is “rigid in the right places and flexible in the right places.” This is important because successful software may suffer from performance punishment: it did well, so now it needs to do more. Which means that the initial benefits provided by Scrum can come to a screeching halt months or years later if teams are not continuously focused on technical excellence. If Agile is about “embracing change,” then an Agile codebase needs to be able to “embrace change.”

Our July Dallas meetup was titled, “Technical Excellence Doesn’t Just Happen-Igniting Craftsmanship Culture.” Mike Rieser and I co-presented our experiences with Flaccid Scrum and shared how we partnered as coaches to help an organization through a technical turnaround with some tips for others who need to do the same. In our experience working with multiple teams in a single codebase, developers can feel victim to a legacy codebase if only a few people are writing clean code or refactoring; guiding them on how to decrease technical debt while delivering their projects helps “unstuck” their other agile practices.  If you’re interested in learning more, tweet Allison or Mike.

About More with LeSS: A Decade of Descaling with Large-Scale Scrum

We were fortunate in June to have Craig Larman, co-creator of Large-Scale Scrum (LeSS), speak to our group. The main goal of LeSS is not to enable traditional big groups to “meet their commitment” more efficiently—it is to see the ineffectiveness of traditional large-scale organizational design and to change it, by descaling with LeSS towards a simple model for multiple teams that optimizes for agility (flexibility), learning, and flow of value. Change the organization before you expect workers to change.

LeSS is scaled Scrum. It is about applying the principles and ideas of Scrum to many teams working together on one product. These include empirical process control, shippable product every sprint (which heightens transparency, creates a strong feedback loop, and allows early delivery of value), and self-managing teams — including self-management between the teams that are working together on one product. LeSS, like Scrum, contains very few elements. This is very intentional. Because of the need for strong empirical process control and learning, and the vast array of situationally different groups, a one-size-fits-all or detailed prescriptive framework doesn’t really address the root issues. So there’s more learning and adaptation with less defined processes, and that’s a good thing. Hence the slogan, “More with LeSS.”

To learn more about Large-Scale Scrum, visit http://less.works Our members found Craig’s presentation to be thought-provoking, and it gave them new ways of looking at organizational agility.  Our conversations have been greatly influenced by the ideas shared, and at least a few took ideas back to their own organizations right away–signs of a great user group meeting!

Why Agile Teams Often Don’t Thrive


On TUE May 19, we hosted Ron Jeffries (yes the guy who has been building software longer than you have been alive) at DFW Scrum. Ron is a frequent visitor of our group and has provided unbelievable guidance and direction to my own teams in our transition to Scrum and agile development practices.

 Ron spoke to our group on “Why so many agile teams often don’t thrive”. I think someone who actually helped manufacture the “Agile Manifesto” would probably be a good source of information on helping us identify our pitfalls in adoption and progress.

 Ron specified 2 main points to this actual topic:

  1. Teams don’t know how to ship software every sprint

  2. Cultural changes necessary do not take place (like helping a team become better at shipping software each sprint)

 Ron’s points above aren’t really the meat to this topic in my opinion. I had a few people struggle with what Ron was trying to convey and I immediately came to his defense and asked “don’t you guys get it?”. Obviously not, therefore, this blog post. Ron’s message hit me right in the sweet spot and validated my fairly close alignment with his views on agile development practices (he obviously has been a big influence in my journey).

 The point? We spend so much “flipping” time (Ron would have used a different word) on making sure our Scrum Masters, Product Owners, and Organization Stakeholders are prepared for the agile journey that you know who we leave out of this preparation? You got it…THE TEAM!

 If we break Scrum down into its components, we “should” have 1 Product Owner, 1 Scrum Master, and 3-9 Development Team members. Where do you think the force lies in where we spend time in equipping the teams? That’s right, the backlog (which is important), how will the business react, will they engage, do we have the roles required, how will we estimate, how we will plan a roadmap, so on and so forth.

 Those are all important questions to ask, but you know which artifact in Scrum we have lost focus on? The actual increment. The increment is the most important artifact in Scrum. If a team can’t ship software each sprint, they can’t tell a story; thus they can’t get the trust and confidence needed to let the business people focus on the what; letting the teams focus on the how. Too often the teams retreat into a hell where they need to know everything up front because we leave no room for failure, mistake, or God forbid, a misunderstanding in the actual requirement.

 Ron started the talk with relating to why Kent Beck created XP (eXtreme Programming). Basically to protect the team. I have a similar mindset in my transitions to agile and will usually build an API translation layer of communication over the team to protect them as much as possible from the cruft the organization might place on them. Our goal? Ship software! Not time-sheets, estimations, roadmap planning, meetings; SHIPPING SOFTWARE!

 Product Development is a collaborative game. Each team has different skill sets, each human brings a particular experience and skill-set to the team. What we should focus on in our agile adoption is “do these teams have the skills necessary to refactor and work incrementally to deliver slices of software to a tested/integrated environment every sprint”?

 Most of the time, the answer is no, but we will spend all kinds of money on the process, the roles, and the PMO type communication abstraction layer to ensure our teams can be left alone. As they are left alone, they struggle greatly in the organizations deployment, branching, merging, and build strategies. Please don’t misunderstand, I truly believe a team needs to provide the level of transparency to the business and PMO group on our progress, but too often this turns into an inordinate amount of work for the team.

 Ron painted a picture about a company party. Most of the time you find people socializing and talking about business. You usually find the development team folks bunched up together talking about technology and cool patterns they learned over a hack-a-thon project. They do this because they are passionate about the technology in their job and solving problems. Let’s incubate that environment and provide more opportunities for these folks to learn more about technical practices that encourage quick delivery. Branching/Merging techniques that allow us to receive changes frequently to minimize conflicts. The nitty gritty of software development.

 Ron encourages the various groups in Scrum (Scrum AllianceScrum.org, etc…) to think of ways we can foster growth in engineering practices. Let’s build more programs around the team and not just the Scrum Master / Product Owner.

When you go back and look at your teams, let’s see how much extraneous work we have around these folks that could be making them unhappy and uninspired in their quest to build innovative products. If your development environments are a large part of the problem, are we equipping the team with knowledge on how to incrementally refactor, incrementally make better paths to production, etc…?

 Back to Ron’s message, teams often don’t thrive because we don’t equip them with the knowledge and skills of how to incrementally build software. We focus on so much other activities and events in Scrum, that we tend to loose site of the most important thing, the increment. Ron is on a mission to help the Scrum Alliance and other organizations to start focusing on these types of activities that allow Developers an opportunity to show skills based on industry practices that can be learned through various techniques.

 I have an old saying in service organizations that says “if you aren’t servicing the customer directly, you better be servicing someone who is”. In Scrum, I can say “if you aren’t servicing the development team directly, you better be servicing someone who is”.

 We are in the business of shipping software, therefore, we better be the best shippers of software that we can. Are you?