Reflection

When I left my previous employer, one of my goals with my next gig was to have it expose me to other domains and environments. I wanted to get different perspectives, see agile development at different scales, help spread successes as well as see the challenges, and assist where I could.

I’ve been doing this now for a bit and I can tell you a few things for certain -

  • The answers are far easier than the implementations
  • You are not alone in your struggles
  • People are succeeding even though they might not be considered ‘agile enough’

The answers are far easier than the implementations

‘We have a large amount of dependencies in our software development projects.’
‘Reorganize your work so you don’t have dependencies anymore.’

‘Our testing and regression takes too long.’
‘Test sooner and automate as you go.’

‘We have a large amount of dependencies across agile teams.’
‘Create cross-functional teams that are customer focused to remove dependencies.’

‘We have an international, cross-time zone development team so stand-up times are impossible.’
‘Restructure your agile teams so everyone is together. Oh, and get rid of all the walls between members, make sure everyone is pairing, and for bonus points make sure everyone is using a PowerBook and they sit on beanbags.’

My team and I are frequently asked for advice or pointers with some very common agile or organizational problems. While I personally like the discussion, the reality is I hate the answers. I hate the answers because it’s the easy out. Looking at problems and providing a solution is easy. Even helping create a plan to address the problem is easy. Implementing the solution or plan is hard, rife with unforeseen problems, potentially painful, and most definitely will take a long time. Providing an answer or a plan takes a few minutes to an hour. To implement these solutions and actually have them stick will take a large amount of time and commitment. Do you want to address quality issues? You can’t just train people in TDD and test automation and expect everything to fall in place. Chances are you will have to look deeper – look at your hiring practices for example. Are your interviews focused on obscure API calls or are they focused on quality? How do you create an organization that actually cares about quality, and by doing so not create one that is scared of the ramifications of creating an unforeseen bug?

If you work in a traditional matrixed organization, trying to create cross-functional agile teams isn’t as simple as creating a team and telling them go. There will be headcount issues, territorial issues, domain knowledge and specialization concerns that have to be addressed. You might actually be worse off for 6 months or a year – can you commit to that and see the light at the end of the tunnel?

An answer or a plan will take substantially longer to implement and you will need to adapt it as you go.

You are not alone in your struggles

There are many organizations, sick of late and over-budget projects, that are trying to adopt more agile practices. They read of the benefits – transparency, responsibility, better quality, cost savings. You can’t just wave your hands and these things happen. The larger and older the organization, the chances are there is a high number of existing items that will challenge change as well as agile project management. People struggle with expressing work in stories and planning. Going from large requirements documents to story writing with examples is challenging. It requires focus on output instead of pixels. Now take that a step further and try to lay those stories out into a plan, and it’s enough to want to give up. But don’t; its hard for everyone and you will get there.

I see struggles with how to realign testing (a group that has been on the back-burner for far too long) with development and the core product. I see consistent struggles with quality as well as supporting legacy applications. If you fall into any of these boats, realize you are not alone. There are far more struggling with these changes than there are who are wildly successful with minimal bumps in the road. You will get there.

People are succeeding even though they might not be considered ‘agile enough’

It’s common for organizations to say, ‘We are trying agile development practices, but aren’t quite there yet.’ Steve Ropa wrote an excellent short post on this topic. The reality is you don’t have to be following ‘prescriptive agile’ to be successful. I’ve seen organizations that still have 4-week iterations, but this still has allowed them to cut product delivery time in half. There are teams succeeding without cross-functional teams or without millions of test cases. It’s a journey, and if it is working for you, keep doing it. If something isn’t working, try and address it. Understand why you want to change something and work on it, but be realistic. Some things are hard, don’t be dismayed by that.

As you try to change your practices, celebrate your successes while acknowledging your challenges. Far too many of us forget to celebrate our successes.

This entry was posted in Agile Adoption, Agile Development, Agile Methodologies, Agile Teams. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>