Tuesday, 24 June 2014

Agile - Days of Future Past, Days of Future Present

On Monday night some colleagues and I attended a thought provoking presentation entitled The Future of Agile (If Any). I believe that agile patterns and practices are fundamental to the continued successful growth of an IT company, so hence the questions I left with felt weighty enough to share more widely:

  1. What physical actions can you take today to increase the level of trust between your Development Team and the rest of your business?
  2. When (not if) a major catastrophe is caused by software, how will we, in the IT Industry, answer the question: "how did you let this happen?"?

The link between these questions is a third:
3. What does the future hold for Agile Development Practices? Is it rosy or is bleak?

Uncle Bob, one of the founders of the Agile Manifesto, explored these questions for about an hour.

After his usual diversion into natural phenomena (this time it was interference patterns), Bob explored Agile's history, from it's humble beginnings to present day.

Kent Beck, at the creation of the Agile Manifesto, said: "We want to heal the divide between business and development". The group that met and formed the Manifesto recognised that this divide could be bridged by building trust, which in turn, is built by transparency. The original practices sought to provide this transparency.

One of my colleagues provided the definition of software as being soft "because you can squidge it about." TDD, Pairing, Refactoring and Simple Design help keep software soft. Bob stated that these practices could be replaced by others, but only if some core values (from Extreme Programming) could still be met:

  • Simplicity
  • Feedback
  • Communication
  • Courage
  • Respect

In his opinion, TDD, for example, is the best way of getting feedback when developing code, but he welcomed any suggestions of alternative practices that still gave the same amount of feedback as TDD.

Bob recognised that Scrum has helped Agile move from the margin to mainstream, but questioned whether Scrum has allowed team autonomy and self-organisation to overrule minimum standards, practices and principles that give improve a software team's maturity (such as pairing and TDD). This was a particular concern for Agile's future, as, in his opinion, the community is very immature. This opinion was based on a rough and ready estimation that the number of developers world-wide is doubling every five years, and so hence the vast majority of developers in the world have less than 5 years experience.

He then looked to the future and posed the question: What major catastrophe will be caused by software? When it happens, how will Development defend itself against the accusation of "how did you let this happen?"?

On a positive note (in response to a question I asked) Bob stated that the disciplines encompassed by Agile Software Development are a positive step towards maturity (providing their adoption continues to spread and become the norm).

The main question I left with, was back to the original purpose of the manifesto: how do we increase the level of trust and transparency between Development and the rest of the business?

Friday, 14 February 2014

Experience report from the Kanban Coaching Exchange - Exploring Kanban through it's values

I enjoyed a great evening last night at the Kanban Coaching Exchange, hearing Mike Burrows explore Kanban via a value system. This post summarises my notes and observations from the evening.

Some sub-titles were:

  • Kanban is "a humane start with what you do now approach to change"
  • Kanban encourages "Leadership at every level"

We kicked of with some quick exercises to familiarise ourselves with the values (Mike's posted them on his blog). I enjoyed being part of a very like-minded group (including @drewpreston and @jose_casal), which finished the first exercise quickly and got full-marks :-) The beer and success must have gone to our heads though, as we missed 100% on the second :-(

The values were grouped into three Agendas:

1 - Sustainability

  • Transparency
  • Balance
  • Collaboration
Collaboration is more than just "being nice to each other"; it's about creative relationships that, together, achieve something. Surprise, dissappointment or frustration in the team is often a sign that collaboration is missing or sub-optimal.

2 - Service Orientation

  • Customer focus - how quickly does the team validate that they've met the customer's needs. Can they even do this (does the data exist and can they access it)?
  • Flow
  • Leadership (at every level)

3- Survivability

  • Understanding
  • Agreement
  • Respect

These are disciplines (that take time and effort to do well), particularly relevant to making changes to a system/process. A related anti-pattern is "unsafe change", comprised of:

  • Bravado (too fast)
  • Complacency (too slow)
  • Tampering (too random)

This was my first time at the meetup and I really enjoyed it. Great location, speaker, beer, pizza, discussion and people.

Wednesday, 22 January 2014

Team Safety

How safe is your team? Is team safety important?

My colleague raised these excellent questions in a recent interview we conducted for our Scrum-master vacancy. Then this week I was challenged by some uncomfortable, but important, questions. Unfortunately, this was before I read a thought-for-the-week article on how Jesus invited questions. All this got me thinking about why team safety is important, and how we can improve it.


Why is safety important?

When people feel safe in a team, they are not afraid to ask questions. These may be curious, or knowledge-seeking questions, or they may be challenging, uncomfortable questions. Either way, these kinds of questions benefit both the individuals and the team. Such questions help build and spread knowledge as well as improve artefacts, processes and behaviours.

Safety can also be viewed as the absence of fear. People tend to be afraid of making mistakes, of getting things wrong. But we often learn by our mistakes. It’s only in taking risks that we make new discoveries (think of Columbus, Neil Armstrong) and move things forward. When people feel safe in a team, they have the confidence to step out of their comfort zone and take a risk, even if it leads to failure. They know that their team-members will support them, whatever the outcome.

How can we improve team safety?

A team dressed in safety gear
It's got to be more than just issuing hard-hats and fluro-vests, or books and training courses.

People feel safe when they trust each other. People feel safe when they respect each other. The excellent book, Team Geek prefixes trust and respect with humility (HRT - spoken as “heart”), which is also a vital ingredient for a healthy team. If you work in an IT team and haven’t read Team Geek, I highly recommend it - we have several copies going round our office (I did say more than just books)!

I’ve been very challenged this year (already!) by how to live out these values, firstly for myself, and, secondly, to encourage them in the teams I lead and am part of (be they family, work or social). As a leader and manager of a software team, my goal (as put by the Agile Scout, Peter Saddington) is to love the team and inspire them. Inspiring the behaviour and values that increase team safety is quite a challenge, but a vital one to engage with.

I feel like it’s going to be a long year! Perhaps it’s time for a retrospective, starting with a Safety Check? This great technique provides a safe way for the team members to share their comfort/safety level, ahead of the team discussing potentially difficult, “touchy-feely” type subjects. Writing this blog post actually led me to the Safety Check article, so for me, this post has been very worthwhile, and I’m starting to feel just a tiny bit more confident already!