Carl Bruiners Agile / IT Development Consultant

27Aug/110

User story breakdown

Many people have asked me about my blog post concerning the Difference between a user story and story, so to make things even more clear I have generated the graphic below explaining the breakdown of User Stories. I have omitted the acceptance criteria in each of the stories as this post is about the flow of stories, but always remember to add acceptance criteria to your stories.

Story Breakdown Carl Bruiners

Story Breakdown

24Aug/110

Professional pride

For me one of the key characteristics of a good worker is that they have professional pride in what they deliver. Not a quality obsessive who keeps over engineering a piece of code to make it 'perfect', for those reading this who fall into that category perfection is subjective and often means little in valuable return with diminishing returns (a future blog post) and aren't normally working in a TDD environment.

Someone with professional pride wants to get the job done right and deliver on time with a hint of exceeding the expectations of those they report to / deliver to.

Characteristics of someone with professional pride;

  • Chips in when a team member is struggling
  • Doesn't like letting the team down
  • Works overtime to get the job done if they fell behind
  • Push's the technical edge slightly without risking the timeline or complicating the product
  • Constructively helps drive the team to meet the required QA within the commitment period
  • Personally feels responsible for a successful delivery
  • Thrives on kudos and not only focused on money (though the persons boss should reward accordingly for a individual having professional pride)
  • Willing to take on challenges outside of their expertise when asked
  • Wants to help raise the teams productivity, efficiency, etc..
  • Wants to demonstrate a piece of tech or an improved way to work / product enhancement that they have researched in their own time

Characteristics of someone 'lacking' professional pride;

  • Doesn't care if they fail to meet a commitment
  • Doesn't care if the team fails to meet its commitment as long as they have completed their work
  • Fails to communicate any risks at the earliest possible point
  • Doesn't want to help assist a team mate in trouble
  • Makes excuses for not being able to work outside of their comfort zone when required (i.e. coding language, product domain, etc...)
  • Only concerned with getting paid and doesn't care about the success of the product
  • Only enjoys the glory jobs and shy's away from mucking in when required
  • Doesn't care.... ;-) feel free to add any point here

There are more characteristics, but I like to time box each posting I write to a maximum of 20mins, so I'll revisit the lists above again in the near future.

19Aug/110

Success is having good leadership

For a number of years I've heard businesses discuss the importance of strategy and what the business strategy is or should be. This is completely valid, but what is often missed out is that strategy without leadership is a complete waste of time. Who is going to take ownership of seeing that strategy through?

I'm going to give two great examples of failed strategy due to the lack of leadership, both the companies names will remain unanimous, both were at polar opposites, one a global corporate giant and the other, though a heavy weight in its own industry, was a charity. Both organisations were at different stages with defining strategy, but both stories should serve to remind you why leadership is critical.

The charity's senior management decided to ask each department, some with no representation at the senior level, to define its own strategy without any direction from the senior management. The outcome of this was obvious, long before each department attempted to define a strategy, this exercise failed. The strategy (or lack of) failed because of a number of reasons all related to leadership. There was no direction or guidance from the senior management on how each department should go about defining their strategy and how this would align with other departments. The outcome was that only a handful of departments defined anything slightly useful, and then these individual department strategies would clash with other departments views. This led to the creation of a 'fluffy' strategy, little meaning and very little value. The senior management were happy though, a fluffy strategy lacks definition and therefore direction, so affectively any individual department's agenda would be supported under the fluffy strategy.

All this strategy helped achieve was to allow further abuse my various departments by having a fluffy strategy that validated anything they wanted to do. A fluffy strategy is more dangerous than not having one.

The large corporate had a well defined strategy, the nominated leader opened the doors to the palace, sent the customary email to the whole of the business and then slammed shut not only the palace doors, but the iron coated titanium gates. Who was ensuring that the strategy was being carried out? Local heads? The do'ers in the business? Who? Sure the vision had been shared, but then the missions were left to everyone else to carry out, but where was mission control? Was the nominated leader to thinly spread to engage on a regular basis? Disinterested?

There is reason in each of the questions marks above, as no one really knew the answers. Great leaders realise that it is not enough to tell someone quickly what they want, but that they have to remain engaged until those who need to understand actually understand what you are trying to convey and achieve. Even then a good leader remains particially suspicious, and keeps engaged until the point that was conveyed has been delivered against.