This year was my first visit to Agile 2011 and I came home with a suitcase full of learning to go along with the suitcase full of vendor handouts. I think the conference organizers did a fantastic job. The location and facility was great and accommodated many hallway conversations, especially in Coach’s Corner (thx Mark Levison for setting that up) and the Open Jam area. I also want to thank the volunteers, particularly Charlotte who was the volunteer in my session. She gave me some feedback during my session that I was able to use right away which was awesome.
I managed to go to a few sessions and spent most of the time in the hallways and Coach’s Corner. I love talking to people to see how they’ve implemented Agile, what challenges they’ve had and how they over-come them. I was super-excited to finally meet Lisa Crispin as we have been trading tweets for the last year or so!
My boss asked me yesterday what my one take-away was. After the first day attending Lisa Crispin and Janet Gregory’s session titled ‘Yeehaw, we’re Agile testers, now what?‘ and David Hussman’s and Tim McCoy’s session titled ‘Integrated Product Development‘, my takeaway was clear.
Culture is important.
Let me explain. When I was new to Agile, I attended a local event a couple of years ago the panel at the meetup were unanimous in their opinion that companies with the right culture can really leverage the benefits of Agile. Lisa and Janet’s session, while on the testing track, were about the effects poor culture and structures have on testing outcomes. An example they used was a discussion around issues attendees had with “QA keeping up”. The discussion at my table was with people in larger companies (although I’ve seen the same effect in smaller ones) and they had similar problems:
Given the discussion at my table it was clear there were severe system related problems contributing to this outcome:
- whole team doesn’t participate in planning – a ‘lead’ and/or ‘managers’ plan the sprint and hand it over to the ‘team’. The reasons at the table were because “it’s a waste of time to have the whole team in planning, they should be doing real work”. Oh that’s a beauty, I’ve seen that in every organization I’ve worked in. That’s called the 100% Utilization Trap.
- The testers are 9 timezones away because it’s cheaper to hire point/click testers offshore
- Organizational structure that prevents cross-functional team creation and optimization (IE: functional silos with different objectives and purpose. The job of development is to push changes out, the job of QA is to be a ‘gate’ to those changes and the job of IT is to prevent anything from changing)
I could go on, but I think that frames the problem(s) nicely. So you are left with what I consider ‘Agile Adoption‘ and not ‘Agile Transformation‘ or ‘Tactical Agile‘ (Thx Michael Spayd for the definition). In my session I talked about how your organization size, culture, structures and people affect your Agile implementation. Organizations with more rigid process/politics and top-down pushed initiatives will not understand Agile values and principles. When you hear people in the Agile community talk about organizations that “don’t get it” I will bet this is the type of organization they’re referring to. You’ll hear managers in these organizations say things like “we can’t just have people do whatever they want” or “that can’t possibly work here” or “we can’t do that because…” These organizations also tend to have strong functional silos and people are more concerned with their title than delivering value. One person at the session had actually removed all titles and people were considered ‘team members’.
Agile Adoption may be more suitable in this case because Agile may be seen as a set of processes and practices and not a mindset. On the flip side, Agile Transformation is more about evolving a new mindset that is based on Agile values and principles. I have another post brewing about that since it was the gist of my session.
If you’re interested in learning more about culture, check out The Re-Engineering Alternative by William Schneider…after finishing reading my post by the way.
David and Tim’s session on Integrated Product Management was a bit more subtle. My takeaway from that was “Product Driven Outcomes over Process Driven Outcomes“. Again this speaks to culture. Process driven outcomes generally follow a pattern where you are ready to release and there’s no technical reason for not releasing other than you can’t figure out how to push it through your process. That’s just an example. I’ve experienced the joy of working in a product driven outcome focused team twice in my career, the energy and culture is drastically different than companies I’ve worked in that follow a process driven outcome process.
That may be confusing, here’s a better explanation. Organizations that want to know ‘how Agile they are’ or how closely they are following Scrum likely have a more process driven approach because of the structures in place (hierarchy, functional silos etc). These structures have been created by management and they are extremely hard to change because these structures have been setup to enforce the behaviour you’re getting. From my experience, organizations tend to put more structures in place to try and circumvent the poor outcomes they’re getting as a result of creating these structures in the first place.
Never was this more clear than when I was talking to a fellow who was asking me how they could start using Agile, in particular Scrum, in their organization. You can read the details here and I can tell you that his department was one that “got it”. They are actually leveraging the benefits of Kanban and have a ‘Kaizen’ (continuous improvement) mentality. Of course the mechanics needed some work, but they really seemed to understand The Agile Mindset based on what he described.
To make a long story short when I hear phrases like “one Agile size doesn’t fit all” and “agile is hard“, I don’t find them helpful. It took me years to start to begin understanding why it’s hard and with each step a new door of learning opens. It’s exhilarating and depressing all at the same time! There are so many factors that help shape what you think Agile is and how you can incorporate Agile into your organization. Everything from the type of business you are, what types of products or services you offer, your size, culture, people, state of technology and more. Once you can learn how to understand your organization, you’ll be in much better shape to figure out how to shape your path to more successful outcomes whether it be via Transformation or Adoption.