How to be an Agile Coach

It was a London Agile Discussion titled “So you want to be an agile coach? Well, what is it and how do you become one?”

We split into 3 teams and the first exercise we did was to write on post notes everything we thought an Agile Coach did and the characteristics they would need to perform this role. Then we reviewed the things we had written down and had to put C (coach), S (scrum master) or both on each post it note if we thought this was a role that the Scrum Master may also do. Do both these roles do a similar thing and need the same characteristics to do well? Is an Agile Coach just doing the Scrum Master role but just on a bigger level?

IMG_0058From this we were given categories to sort the cards into which were meant to be the different types of Agile Coaches, including guide, cheerleader, guardian of quality and performance, servant, shepherd, bull-dozer or others. These choices came from the book by Lyssa Adkins. This caused a few interesting conversations depending on how the person imagined each category type to be like.
IMG_0061Then all teams came together to present what they had done, making one main post it note sorting result. If the individual groups had differences with where certain post its should go this was now amplified but discussed to a consensus.
IMG_0063It was a very interesting meetup as for me I feel there are a lot of Agile Coaches but maybe doing slightly different roles. It got me wondering would it be better if someone was a coach first and then moved into agile? Is the real need coaching or is it more counselling? 

Very interesting discussions and a good night.

Agile Transformation

pw

I was at a customer site today and the customer was having issues with “Agile Transformation” and how to open their department’s eyes to this process, not only their department but the rest of their Organisation.

The concern was about how to convince people to try something new and move away from the normal waterfall approach. It is very interesting to see how people are afraid of the unknown and doing something new. For me you can’t get an organisation to change without proof. You need an initial, maybe small, project where you can actual show people what the differences are and how this works compared to the old approach. When you can show that changes aren’t going to cost anything, that their are demo’s so you can see how the project is going at regular intervals. That the stakeholders and users have a say in what is being delivered rather than just being told this is the software to use.

If you are having similar issues or just need a steer at how to encourage people to try something new I’d recommend reading this as it’s a good little insight. The other thing I do is not use words such as ‘agile’, ‘scrum’, ‘kanban’… These words don’t put a customer at ease, it can be like you’re part of a cult and they have no idea what you are talking about. People want to see something in action, once they think it is the right thing then they may want to know a bit of background about it. Show and then tell.

How to split user stories – London Agile Discussion Group

The London Agile Discussion Group were talking about How to Split User stories which is a topic of great interest as it is hard to do this quickly but well and it is always great to hear how other people deal with similar experiences.

You start a project and depending what side of the fence you sit on depends which issues/experiences you may have. For me in the Business Analyst role on a new project you need to ensure that there is a clear vision for the team to work towards. Then you start working on the requirements with your Product Owner/Customer. This is where it can get interesting as even what seems like the most basic requirement actually probably isn’t. A request for a login page seems quite innocent but if that if the only acceptance criteria is that Job Blogs can login and that is what is delivered I’m pretty sure most customers will say that is not what I wanted. There are different levels of requirements, bronze, silver and gold. What is needed now and how much time do they want spent on this requirement. Do they need registration as well, do details have to be collected, does it need to link to LDAP? Even a story that seems basic need to be split a little more.

Why do you split stories? We came up with a few reasons but there are a lot more:

  • Promote discussion and understanding
  • Several people can work on it
  • Reduce time to deliver and get feedback
  • Fail fast
  • Fit into an iteration
  • Improve acceptance criteria
  • Get better requirements

There are different ways to slice up a story, vertical or horizontal.  Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”

slicingA horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture and this isn’t the wrong way of thinking about its as most things are built this way. If you were to build a house, you would slice up the project horizontally. First you would pour the foundation,  then put up the walls. Finally the roof goes on and many more steps, leaving the finishing work for last. This same thinking usually gets applied to breaking up backlogs in Agile development. It would seem silly to build a house where you finished one room completely at a time.

There is a distinct difference though, between developing software in an Agile way and building a house. In Agile software development you don’t know exactly what you are going to build until you are done building it. With a house I hope this isn’t the case! You start with some blueprints that you have drawn up ahead of time.  You know exactly where each wall will be and where each outlet will be.  You may have even built houses before that are very similar. When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.

To be Agile means responding to change. Building a house, you do not expect the customer to say “hmm, yeah, I don’t really like that wall there” or “actually, I am thinking we are going to need 5 bedrooms now.” In developing software when the customer can see how it is turning out, requirements may start to change and new ideas appear.
slicing hVertical slicing is basically building one room at a time. It is not functional as a house straight away, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost. The point in building our software “one room at a time,” is to give the customer a chance to see the product as it is being built and this enables them to test it out. They can’t live there until it is all done.  But, they will have the ability to step into a room and envision it with all their furniture in there.

Customers don’t care about foundations and framed in walls.  As a developer, you may be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse how can they test it? Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.

The idea is that instead of breaking a backlog up into the following:

  • Implement database layer for A, B and C
  • Implement business logic layer for A, B and C
  • Implement user interface for A, B and C

The backlog is broken up into something like:

  • Implement A from end to end
  • Implement B from end to end
  • Implement C from end to end

Developers think about the horizontal slicing when planning out the implementation of a backlog, wanting to implement things by building one layer at a time. Thinking about how to break apart a backlog into vertical slices requires a step outside the understanding of the code and implementation, instead thinking about the backlog in small pieces of working functionality. There is always some progression of functionality that can be found in a large backlog. Meaning there are always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development. Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste. Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices. It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that were not planned for.

Vertical slicing is about delivering working functionality as soon as possible, delivering working functionality as soon as possible is important and valuable.

There is a good flow chart on how to spilt stories how to Split a User Story that helps you break it into smaller sections and obviously mentioning INVEST that we reviewed in the meeting. Stories should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

ecWe then split into small groups to run through an exercise on Elephant Carpaccio. You ideally need 2 hours to run this and you need developers for this. We decided to do it without the coding and show and tell. You need to make a calculator, what are your stories for this, how do you split up the project and how do you ensure you get value sooner. I think this exercise was an eye opener and I’d like to run it again as it makes you think, trying to work out the priorities and what would be most useful. I also think it was good as it tried to make you split up the stories as small as possible but each story had to add extra value and could be demoed. I’d recommend this to teams to help developers see the different on how you could split stories. It was a very interesting session.

 

Agile Talks and Conferences

There are a lot of Agile Conferences that happen throughout the year. If you are interested in finding out what is going on this site is quite useful.

The good thing is most places are recording the talks, so if there is no budget you can still watch and learn. You do miss the discussions that arose from the talk afterwards but it does allow you to hear the latest ideas being promoted. Agile on the Beach in Cornwall has just happened and the videos and presentations are up. There was a good mix of agile for developers and agile for the business.

Coming up in London is the Business Analysis Conference 2013 with a few more talks on Agile for a Business Analyst including one of the Agile Practitioner Organisers, Christian Heldstab, talking about 10 Things a BA Should Know About Agile.

Another place for good talks is Skills Matter who have courses and some free evening talks, which are recoded as well in case you can’t make it.

This year I went to Sync Conference, which for next year will be in October where there was an agile stream and a technical stream. It’s only a day but there were a good crowd there and you table hop at dinner which allows you to speak to most people there.  The talks can be found here.

Sometimes I think there may be a bit too much information out there! Though this way you have no reason to stop learning.