Jason Little's Agile Blog

For those who are familiar with some of my other posts, I seem to follow a similar pattern when talking about Agile.  Based on using Agile as the tool to help implement the Rockefeller Habits when I was working at Q4, I’ve always thought that the focus and goal is always to help an organization be successful based on how that company defines success.

This was the focus for a session I proposed at Agile Coach Camp this weekend in Waterloo.  First off, I love Coach Camp!  The energy, openness and shared learning that happens is simply amazing.  It is truly inspiration for me to see how passionate everyone is about Agile and giving back to the community.

I had originally titled the session “Focus on Success over Focusing on ‘Being Agile’” and I was pleased with the open dialogue that came out and helped me sort out the thoughts in my mind around this topic.    I’ve mind-mapped and framed a mini-book based on a post I wrote last December that I feel very strongly can help bridge the gap or remove the disconnect between organizations that want to adopt Agile with the message being communicated from the Agile community.

While I am a firm believer in the Manifesto and the principles of Agile, I don’t think that message resonates as well with clients and organizations that want to adopt Agile as much as using Agile as a tool to reach a goal does.

The whitepaper I had hope to publish many months ago started evolving into this mini-book but not having written a book before I am struggling a little!  This is a great chance to eat my own dog-food and use Agile as the tool to accomplish my goal of writing this book.  Well, I think that is enough ramblings for now, you can view the summary of the session here!

The organization I’m currently working with is suffering from ‘we have no time’ disorder.  Demand is exceeding capability which is leaving little time for ‘non-contextual’ learning for the lack of a better phrase.

While one team has been making some great strides with root cause analysis, they have been struggling to turn those learnings into actions simply due to the volume of work that needs to get done.  In addition to ‘we have no time‘ disorder, they have also been diagnosed with ‘we have to‘ syndrome.  A dangerous combination of diseases indeed.

Enter Open Space.

Now that this particular team has gathered a bunch of data that narrows the focus of what parts of the application are causing the most problems, (amongst other organizational causes that are out of scope here), I’m planning on conducting an Open Space to gather the more subjective data as well.

So why an Open Space as opposed to a typical brainstorm session?

I see this as an opportunity to teach within context which will help the team with:

- self-organization skills (facilitation, time-boxes, collaboration)
- spreading domain and application knowledge amongst the team
- gaining perspective from multiple disciplines (QA/DEV/Business)
- giving everyone on the team the opportunity to speak up (team has some dominant personality issues)
- developing a framework for problem solving and brainstorming so they can be as effective as possible with future meetings
- having fun! get folks together and excited about their work!

These are the mechanics I’m planning on using, as I think some tweaking is necessary to get this to work in context:

1. Setup the open space concept: give team members a few days to digest how an open space works and why we are trying this approach.  This will be wrapped in the business goal for this session (gain consensus on the part of the application that will become the focus for this quarterly initiative.)
2. Open Space Intro: 10 minutes – re-state how an Open Space works and state the business goal of the session.
3. Lightning Talks: 30 minutes – each team member will be allocated 2 minutes to present what they want to talk about.  Ideally we will post this in the wiki ahead of time and I suspect folks will pair up.
4. The Twist!: 1 – 2 hours – Here’s where it gets risky.  Now it’s ideal for all team members to be part of each talk since there will be actual work derived from the output of this session.  Depending on the number of ’sessions’ that are created, as a team, we may agree to do “X” number of sessions and everyone will participate or we will vote on what 2 sessions to do.  I suspect based on the hard data gathered there will only be 2 – 3 major functional parts of the application chosen by the team.  The backup plan is to use the hard data in conjunction with voting, fist of five or other consensus techniques to decide what topic(s) to drill down on.  The sessions themselves will functional much like a typical brainstorming session.
5. Retrospective: 15 minutes.  For me to see how effective this was as a coach and for the team to see if there are techniques they can use going forward to have more effective meetings.

I’ll follow-up this post after the session has been held, but would love to hear your thoughts and suggestions!

It’s amazing how the meaning of this simple word can dramatically change by how it’s written.   Agile (Big A) has structure and is comprised of set of disciplined practices designed to get results, whereas agile (little a) is simply ‘do-whatever’ with little or no discipline and structure.

I often find that people are confused by the differences.

Want to be Agile?

• educate yourself:  understand what it is and what the impacts will be to your organization
• educate yourself:  no, that isn’t a typo.  Get educated.
• hire a coach:  no, not because I am one, but because it’s really a good idea.
• listen to your coach: we don’t have hidden agendas.  We want progress.  You are the people doing all the hard work. A coach can help guide you there but they can’t change your culture, define your requirements, develop and test your software and automate your deployment process.
• do not fear failure: through failure comes learning.  The saying  “failure is not an option” should be rephrased to “failure is not optional”
• empower your teams and invest in people:  managers need to foster learning and lead by serving. Help your people.  Get them training and cultivate those relationships.
• attack your problems: Agile will create visibility.  Deal with it.
• resist temptation to panic:  Agile will not fail you.  You will fail Agile.
• be open to crazy ideas:  it might sound nuts to have a programmer and tester sit beside each other and work together, but it just might work.

Want to be agile?

• do it yourself:  don’t hire a coach or even better, hire one and ignore everything they say.  The benefit of this is that you can waste more money.
• use agile as an excuse:  are your processes too bloated? Spent too much time planning and only have a week to build a system that will probably take 6 months?  Call the project ‘agile’ so you can fast-track it and skip all the internal bureaucracy.  Then blame Agile (yes, big A) when it doesn’t work.
• strive for mediocrity: want crappy results only faster?  agile will get you there.
• don’t listen to the teams: duct-tape that 8 year old application together at all costs.  Time spent improving the code would be wasted when you can be adding more features.
• don’t plan: change priorities early and often to be as ‘nimble’ as possible.
• buy lots of expensive tools: the pricier the better.  If they cost a lot, they must be able to make you agile.
• invent solutions to problems that don’t exist:  force process onto the teams to make your life easier, even if it means longer time to market, increased cost and overhead.
• multi-task: if you have one high-performing team, take away team members to work on other projects at the same time.  Since they are high-performing, they will definitely be able to handle it.

Agile is comprised of a disciplined set of tools and practices.  And they work.  While there are subtle differences between Agile and agile on paper, the difference between becoming Agile vs becoming agile are the differences between great success and catastrophic failure.