Monday, April 21, 2014

Not just Agile - ____ Agile!

Let's do whatever we want and call it a new flavor of Agile!
Every now and again, I meet a team that's doing things very differently than your traditional Agile team. They often label themselves with a prefix - they're not just Agile, they're "Extreme Agile" or "Hyper Agile". Personally, I think that the term Agile encompasses all that a team would ever aspire to be, though Agile teams may be at varying levels of maturity. Scrum, Kanban, SAFe, DevOps - whatever you want to call yourselves, your team should strive to get better and better at aligning with the Agile Manifesto and its Principles. This means your practices reflect Agility and your are continuously improving.

So how can you tell if you're Agile? I recommend asking three groups of people: your peers, your clients, and yourselves.

Your Peers
If you're an Agile team operating as part of a larger organization, there should be a balance between competition and collaboration between teams. Everyone wants their team to be the best, but not because the other teams are so bad. You should be working hard to improve your competition, a.k.a. the other teams in the company, so that they, in turn, will push you to be better.

Ask your peers how Agile you are and be prepared for some candid yet constructive feedback. Remember, you're all in this together. Cross-pollination and frequent feedback from your peers makes everyone better.

Your Clients
It doesn't matter what the nature of your team is, your code is being used by someone. Whether it's an end-customer, a business user in another division, another system within your technical organization, etc., there's somebody who uses what it is you're building. The Agile Manifesto and its Principles make it very clear what kind of relationship with and service to our customers we should be striving for. All you have to do is ask your clients whether they feel that relationship and service is there.

You should also look for ways to continuously improve how your interact with and serve your clients. What delights your customers today will soon become the status quo. If you're a good Agile team, you're meeting with your customers and getting feedback on a frequent basis, anyway. Take some time to go over how you're delivering, not just what you're delivering.

We are often our harshest critics. I encourage all Agile teams to have everyone on the team fill out some sort of self-assessment on a regular basis (a quick search will provide you some examples). By getting as many responses as possible, you avoid the extreme ups and downs that come from individuals. Look at the mean and median results, then discuss your perceived strengths and weaknesses as a team.

Sometimes we feel we're at the top of our class because we're excelling at what we understand Agile to be. It's important to stay involved with the greater Agile community so you can find out the latest and (potentially) greatest practices and techniques for driving Agility. Even more importantly, recognize that there's no such thing as perfection, only better, and instill a passion for continuous improvement within your team.

And Also...
I'm sure there are other ways to gauge a team's Agility. What other ways would you recommend for teams to assess how Agile they are? Is there a place for "Extreme" or "Hyper" Agile in our vernacular? Is it a positive thing to have pockets of disproportionately high Agile maturity in your organization? What are you doing to drive an overall increasing Agile maturity?

Monday, April 7, 2014

Discord in Agileland

I've seen a lot of blog posts and articles circulating about how horrible the state of Agile has become. The central theme to these is that the term "Agile" has moved away from the principles that they established to the practices that are commonly used by "Agile" teams and organizations. I'd like to gently suggest that we not throw the baby out with the bath water.

Look, I totally get it. I really do. A quick glance at my own blog's history will tell you that I'm a huge advocate of sticking to the Agile principles and paradigm. Adopting practices, techniques, frameworks, or methodologies without internalizing the Agile Manifesto and its Principles is an exercise in diminishing returns (if any). However, it's also very difficult to ascertain how well an organization has internalized Agile into its culture. Like the saying goes, "The proof is in the tasting of the pudding," meaning that Agile teams do, in fact, behave differently because of how they've internalized Agile.

Theological Agility
"You will respect the sacred parchment" -- 5 reasons Agile is like a cult
One of the better blog posts that I've read on the subject was written by Dave Thomas, one of the Agile Manifesto's original signatories. In "Agile is Dead (Long Live Agility)", he writes, "Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."

People have exploited the agile brand to push their own agendas, that's for sure. All too often these days you meet someone trying to sell a practice or approach who can't name more than a couple of the Agile Principles (if any). I have personally trained people on Agile who had "heard so much about it", yet had never heard of such a thing as the Agile Manifesto.

So yes, we do need to work on getting back to our roots. However, that does not make all practices and approaches evil. This way of thinking is way too theological for an approach that must be practically applicable.

Making a living off of changing people's lives is not a crime against Agile. Furthermore, there are some practices that have existed for long enough that I would consider a team to be un-Agile or a low-maturity Agile team if they weren't doing them.

By their Fruits
By their fruits ye shall know them - Agile Teams have Agile practices, produce quality value, and are happy!
In his blog post "The Corruption of Agile", Andrew Binstock writes about the evils of building a brand off of Agile. He states that teams can be doing Agile practices without being Agile, and they can be Agile without doing Agile practices. My confusion is: how do you know a team is Agile if they aren't acting Agile? Practices such as TDD and Continuous Integration enable the team to deliver the values stated in the Agile Manifesto and its principles. If a team's not doing them, what are they doing to get there? Do they inspect and adapt on a regular basis? Are they striving to deliver something to their customers every 2 weeks to 2 months (with a preference for the shorter timescale)? How do you know they are Agile if their practices aren't Agile?

Agile practices can be a good gauge for a team's Agility. I do not advocate their use as the only metric of Agility, but they provide a good starting point for assessing a team. If a team is using Scrum and has implemented TDD and Continuous Integration, it's going to take a fair amount of convincing for me to believe they aren't "Agile", for how did they get to that point if they weren't continuously improving? Perhaps they were Agile at one time and had grown stale, but there is certainly evidence that they were at least Agile at one point in time.

Keep an Open Mind
Do we need to focus on our roots, the foundation of Agile culture that will breed lasting success in our teams? Absolutely! Our people should be consistently reminded of what it means to be Agile to ensure they are adapting towards greater Agility instead of away from it. Are people who introduce practices, approaches, and techniques that enable and empower a team to become more Agile inherently evil? Absolutely not! A team that understands what Agility is can tell when someone's trying to pull one over on them versus a person who genuinely has their best interests at heart.

I love going to conferences and learning about the latest and greatest in the Agile world. I love being a part of a community that is so obsessed with making people's lives better. I love the healthy debate and pragmatism that comes with experience. And I loathe those who are clearly pushing their own agenda without a reality check or an understanding of what Agile is really all about. I think it's time we took a more measured approach to our criticism, understanding that not all Agile consultants are wolves in sheep's clothing; indeed, more of them than you think are just trying to make the world a better place.

Friday, April 4, 2014

Favorite Agile Principle

There's been a lot of buzz lately in the Agile community about how far we've gotten from our roots. Most of the talk is around the evils of associating specific approaches with Agile; some have gone so far as to say if you advocate a practice as standard for Agile then you've lost your compass. I have some ideas brewing around those ideas. In the mean time, I thought I'd throw out a positive post to encourage people to get back to their Agile roots. My question is simple: What's your favorite Agile Principle?

Mine is easy: "Simplicity -- the art of maximizing the amount of work not done -- is essential". This principle is elegant and so applicable to my life. I am constantly over-complicating my life, so I've made this principle my mantra to keep me in check.

I understand that all of the Principles are important, so don't get hung up on the question. I'm not asking which one is best or most "Agile", I just want to know which is your favorite.

If you need a refresher, they can be found here:
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Wednesday, April 2, 2014

Introspective: Where are the Introspectives?

I mentioned a couple of weeks ago that I was going to try out LinkedIn's publishing tool. I've really enjoyed using it, so I've decided to keep this blog to more technical subjects and use LinkedIn for more general advice and introspection. I'll continue to blog here for the foreseeable future, especially on Agile topics that are too technical for a broad, diverse audience. If you'd like to follow my posts on LinkedIn, you can find them on my LinkedIn author page.