agile

I’m Not Here to Be Your Friend

I was recently talking with a friend who was having some problems with adopting Scrum on a couple of their teams.  They were describing symptoms I’ve seen before in organizations where the QA folks struggle to keep up with the rest of the team.  Because I enjoy inflicting help on people, I offered to talk to them on my own time to offer some stories and experiences that might help them.

Some of the symptoms included not finishing the sprint work, disagreements about what done meant to the developers, testers and business people, struggling to finish regression, missed deadlines and releases.  It’s always tough to gather enough context in a short amount of time to offer some advice.  I could see the main challenge was getting the team to buy into a shared goal and removing the silos.   Having said that, these guys seemed quite collaborative, I think they were simply having problems adjusting to Agile given they’ve only been trying it for a couple of months.   I think they’re on the right track and seem committed to improving which is just great.  Anytime people want to give up their own time to learn is a good thing in my books.

As we talked about ideas about how to find balance I suggested one way to help manage these symptoms is to pull less work.  Of course every action has some impact and I mentioned that this can create idle time, especially in cases where “the development work” is low effort but the “testing work” is high.  You could have developers idle! Nooooo!  I could see an adverse reaction to that suggestion so I made a joke about making sure “resources” are 100% utilized!  The reality is, people need slack, especially to learn a new process and move forward.

I asked the product owner flatly that if they are missing releases now.  He said yes.  I asked if they have quality problems as a result of in-sufficient testing.  He said yes.  I then asked what’s the harm of slowing down?  Your missing releases with lower-than-desired quality now.  You’re only fooling yourself if you think slowing down is going to cause problems because you already have those problems now.

I could feel a bit of shock from a couple of people in the room after I said that.

The point is, when you are looking for a coach or consultant, they’re not there to be your friend.  They are there to help you figure out how to solve, manage or cope with your problems and you are not going to like some of the answers you get.  A good coach is going to tell you either the brutal or kind truth and the best you can do is establish personal safety by having an agreement and shared understanding about what is expected from the coach from your perspective and the same from the coaches perspective.  Once you can get that agreement in place what unfolds can happen in the name of progress.

Why the Agile Community is Awesome

I was bummed to miss out on Agile Coach Camp in Columbus a couple weeks ago so I had to settle for enjoying the tweet stream.  One such tweet that stuck out was this one:

“The #agile community is too closed. We are doing intellectual incest, and congratulating ourselves for it.” ~@mhsutton #ACCUS

I can understand and appreciate the comment, I’ve posted many times about how I think the Agile community is disconnected from the reality that organizations are going through.  Having said that, I’d have to disagree with the statement that the Agile community is too closed. Read More

Understand How the Work Evolves

Growing organizations can fall into the trap of thinking scaling is easy.  Simply add functional departments to break the work into compartments, flow it through the system and voila, infinite scaling!  I’m often perplexed about how the structures I see in organizations are similar regardless of the type of work they are doing.

There’s usually a development team, test team, release team, product team, implementation/support team etc and these groups are usually silo’d each with their own hierarchy.   Perhaps fodder for another post, I find that these structures and hierarchy often mimic manufacturing.  Put some requirements in one end and out pops the toaster from the other end.

You can avoid scaling problems, or at least minimize them, by understanding how the work evolves as you grow. Read More

Switch to our mobile site