• All
  • Agile
  • Agile Adoption
  • Agile Organisations
  • Coaching
  • JAFAC
  • KanbanFor1
  • Product Development
  • Product Owner
  • Retrospectives
  • Scrum Master
  • Self-Selection
  • User stories
Read More

Evolving the Story map

I can’t say enough about how useful story maps are and how essential they are on any Agile project. Jeff Pattonis the undisputed (certainly in my mind) master of the story map and it’s well worth looking at the materials on his site. Jeff summarises a story map as, “A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do.

 

Read More

Exploring servant leadership

A few weeks ago I was sitting next to a log fire, sharing a glass of wine with a few like minded individuals chatting about all things Agile, one of the things we discussed was a time when one of the party was a Scrum Master and that they had a team admin who used to collect all the story data and do the typing up for each sprint. My immediate reaction was that of outrage, “how as a servant leader could you, farm off ‘menial’ tasks to someone else, that’s an integral part of the role”.

It got me thinking, am I the odd one out here?

Most of the Agile literature I have read over the years mentions servant leadership, but never really goes in to too much detail. A quick hike to the lazy man’s oracle, (Wikipedia) and as the saying goes “the more you know, the less you know you know”. To help me learn and understand servant leadership a little more, I decided to dissect the Wikipedia commentary and see what emerged for me.

Robert K. Greenleaf never specifically defined servant leadership but, based on the writings of Greenleaf and others, it can still be defined as a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.”

Read More

Kanban is not for the Idle or Newbies

For four of my six and a half Agile years I was solidly in the Scrum camp, Lean, in my opinion, was already part of Scrum and its influence made Scrum even better. I don’t think that any Agile practice is for the work shy and there is a lot of personal courage needed to get any practice working well. Many people call Kanban an evolutionary rather than revolutionary process (my disagreement of this bland throw away statement will be in a later post), and I think this allows too many people keep the dinosaurs roaming the earth, if the mass extinction event has just happened then apart from the obvious sense of loss , at least you have an empty playing field to start from. Scrum at least with its slightly more prescriptive approach gives you somewhere to start.

About two years ago Kanban for software finally entered my Agile sphere. I initially relegated it to the ideal-for-support-teams division, and sneered at the new kid on the block. But time spent seeing Kanban in action and listening to the wise words of people like Gareth Evans (understanding the cost of delay was a revelation for me)  and presentations including “Agile isn’t the point, better is the point,” by Michael Bromley, made me think about Kanban in a more positive light.

Read More

The Wall of Pain

Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later.

I recently visited an organisation that had a wall of pain which I thought was an excellent idea as it highlighted the levels of technical debt in the project. This involved a section of the workspace dedicated to items that needed refactoring at a later stage. This made me think about pain and our tolerance to it.

The wall had lots of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team.

That said i am not sure how much the pain was actually felt, as i said there were lots of cards and they were not easy to see when the team did their stand up in front of the visible workspace, so they did not feel like they were always on the mind of the team.

Read More

Visible workspaces – a house of cards or something far more solid?

Many people’s first encounter with an implementation of an Agile framework is the visible workspace. I find first reactions to this very telling: for some it feels like a natural way of expressing their work and they can see what is happening in an instant, while for others it’s some cards on a wall that don’t look professional and ”what’s this got to do with real planning anyway”. The professional part of me hides that sinking feeling inside when you know how much energy you are going to have to put in to get them to see that Gantt does not always (even rarely) equal a plan that works.

So for those who don’t know what a visible work space is here is a short list of what it is and what it is not. A visible workspace is:

  • A focal point for the project team, especially during a horizon
  • A representation of the work planned for the iteration
  • An easy way to see who is doing what and when

 

  • A planning tool for the team
  • A repository for non sprint information too, such as highlighting levels of technical debt
  • A living document
  • Easy to understand for anyone in the organisation
Read More

The document dilemma

The Agile manifesto states “Working software over comprehensive documentation” – this seems to be one of the biggest mindset shifts that organisations need to make when adopting any Agile framework. For some people that simple statement brings up visions of chaos, lack of control, and the worst fear of developers doing what they want. At the other end of the spectrum that’s exactly what some people hope it does mean.

If you ask people within most software development teams / companies what they do it is very unlikely that you would get the response “write documents about the products for our clients”. Most responses would be about the latest website or the latest Google hack they are doing. So inherently at an external client facing level we do value working software over comprehensive documentation. Where I believe this value changes is during the production of the working software and the legal requirements from the iron grip of the contract.

Read More

Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.

So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.