Tag Archives: agile

Using The Voice Of the Customer As Input For A Retrospective

Previously, I have worked with a team whose overall effectiveness has been called in to question by people who the team interfaced with. Upon further investigation it became clear that the perception those people had of the team was largely based on anecdote and yet, as the lead of the team said, perception is reality.

The lead and I sat to discuss this and agreed to substantiate some of the comments being made and the process that we would follow to derive actions that we could then take towards discernible improvements. I think that what we ended with is an interesting way of looking at gaining input in to a team’s retrospective and contrary to the way I have seen it done previously, namely that the team sourced opinion from outside of the team rather than internally, and so wanted to share it.

We started by identifying the customers of the team and given that this was the first instance of running this process, we also chose to keep the group size small, identifying just the key individuals with an agreement that in subsequent iterations, we would extend the group.

We designed a small survey comprising 4 questions that we would ask of the individuals:

  1. What is your perception of the team’s performance?
  2. On a scale of 1 to 10, how would you rate the performance of the team?
  3. Given the rating that you have just given the team, how could we make ourselves a 10?
  4. Can you suggest any ways in which we could measure the effect of the improvements that you suggest?

Questions 1 and 2 in the above were actually of little significance in respect of helping the team to improve, their purpose focused more on providing some context to the presentation that would be made back to the team after the interviews had been conducted.

Question 3 gave the person being interviewed an opportunity to make specific recommendations for how the team could improve and so in our opinion, was the most important. Less important then was question 4 though it did serve to make the people being interviewed question the feedback that they had in response to question 3 and to offer the team with some sense of measures that they could use that would be meaningful to their customers.

With this data, the team lead conducted a Retrospective. It started with a presentation of the information that had been collected. The team was told from the outset that this was data that had been collected and that while they may disagree with some of the comments made, it was the perception of others and that therefore they needed to accept it as it was.

The remainder of the Retrospective was split in to three sections, an idea generation session titled “What Changes Can We Make That Will Result In Improvement?”, followed by an associated filtering session which looked at the ideas generated and asked the question “How Will We Know That The Change Is An Improvement?”. The purpose of this filtering session was to filter out those ideas that could not be measured one way or another. The team estimated the value an item would have in respect of impacting their performance using a relative scale and followed that by estimating the effort involved in bringing about the change. Both of these estimates were done using a relative points scale. Finally, the value estimate was then divided by the effort estimate to give an indication of the Return on Investment and the item with the highest return was selected for action by the team.


An Agile Adoption Pattern: Wax On, Wax Off

I know I’ve said before that I don’t believe in an Agile Adoption initiative but humour me a little here…

As I rode home dodging in and out of traffic a couple of weeks ago, with the saddle still as low as it would go from the last descent that we did on the bike ride over the Downs that weekend, I realised that it really can be the simple things in life that are most pleasing. It was good to be sat in the saddle cruising down the road on my bike. Then, at a point where I hopped off a kerb back in to a side road and the bag on my back swung round knocking me off balance I quickly realised that it was also the simple things that can catch you out.

Some 5 weeks ago now I set the first team up to use the processes that I want the whole department to be using in time. We did 3 1 week iterations and have recently completed one that ran for 2 weeks. As I took the team through the initial estimation exercise I was reminded of the discussion that has been taking place about whether or not estimation is waste. I agree with all of the points made and I think that once a team has realised it’s velocity it can take the decision to move away from lengthy planning exercises and indeed estimation entirely. Why then have I suggested to them that they estimate their stories? I think they have to start somewhere, the team needs to understand their velocity and in understanding your velocity they can start to look at the things that are slowing them down. One of the things that I have previously said is that it’s important for a team to gain some momentum, to get an idea of their rhythm and this is one way that I think they can do that.

At the same time though, I was advocating keeping the Product Manager away from the team, even when they were saying that this was a hinderance to them in their retrospectives. My reasoning for this was to enable them to get started without interruption. The piece of software that they’re working on was created as a Proof of Concept previously and we’re now looking to take it through to a Private Beta and so I thought the team had enough to go on for a short time without the additional “noise” generated by having a Product Manager involved, on the assumption that whilst the initial requirement was to get a production version of the software shipped once they started seeing the software during the demos, they would then start wanting additional features and distract the team. What has actually happened though is that we’ve ended up having to wait for a few decisions to be made which ultimately have slowed us down. This could have been avoided if I had got the Product Manager involved from the outset.

Ultimately, you have to start somewhere, doing a regular planning meeting allows the Product Manager to give the team the priorities, the stand ups allow the team to plan on a daily basis and to remove any obstacles, the retrospective allows you to inspect and adapt and the demos allow the Product Manager to seethe result of what the team have been working on, it enables them to feel part of the process and to look at how they could extend the product.

How do you introduce new processes to teams? Do the simple things, do them regularly and learn as you go. Wax on, Wax Off.

Agile: Like Fingernails On A Chalkboard

This is a post that I’ve had in my drafts for some time now, mainly because I’ve been trying to temper it’s message somewhat, having posted Agile Adoption – Just Say No the other day though I thought it was worth posting as a follow up as it relates to the last of the 3 points that I made.

Handling Polystyrene, somebody running their fingers down a chalkboard, two things that have always made me cringe. Well, you can now add the word Agile to that.

It seems that in my haste to see Agile adopted, I’ve not taken the time to clearly state to people why I see it as a worthwhile pursuit. After our recent reorganisation there’s even more talk of a move to Agile, we’ve got our own Agile Consultant, there’s even some people working on defining an Agile process. All good stuff.

Or perhaps not. There are some things to be really concerned about here, to desire to have, or to create an Agile process misses the point somewhat I think, there are plenty of good books out there which will help with a vanilla implementation such as Agile Project Management with SCRUM (Microsoft Professional)*, more importantly though let’s not pit Agile against Waterfall (for that is what is implied) – let’s not suggest that one is better than the other because there isn’t an argument there.

So what can we be doing, if not Agile, what should we be aiming for?

Well in my head it’s simple (some people might take the opportunity here to say that most things are…), we should be aiming to do the best job for our customers that we can. That’s a pretty vague and unsubstantial statement, to be more specific, if we’re considering delivering projects / products at an enterprise level, I think you need the following two things:

1. A Clear Governance Model

This serves two purposes, it ensures that the customer is getting sufficient visibility of the progress being made on a project, it commits them to the project in some way, it is a vehicle for communication with them. Secondly, it gives the team some parameters to work within, consider the Forming, Storming, Norming and Performing group development model which suggests that during the forming stage a team will meet and understand the opportunity and challenges that they are presented with. If we focus on the typical challenges faced by project managers I think it’s fair to say that attempting to work within the classic Time, Scope and Budgetary constraints is one of those challenges but we should also recognise that there’s always some movement on those and that in that the challenge is to operate within a set of parameters and in my opinion those parameters should be mandated by the governance model both from a tolerance perspective and a communication / escalation perspective. My point here being that how the team is delivering is not important to the customer nor in fact to the team initially, they should set out a set of principles by which they want to be driven (perhaps during the storming and norming phases) in each instance based on their knowledge of their environment and allow the practices that they use to evolve as their landscape changes around them.

2. A Culture In Which It Is OK To Make Mistakes

This may make some of you think, that would never work in an organisation but let’s face it (and be honest) we all make mistakes on a daily basis, it’s what you do about those mistakes that define you and your organisation. Now granted, you don’t create a culture, you build relationships and trust but as well as that, I think you need to build an environment of learning, one where you’re looking to continually evolve and that everybody’s committed to furthering themselves and others around them. All very easy to write about, a lot harder to actually implement and live by.

* I don’t necessarily subscribe to the opinion that Scrum is sufficient as an agile process in itself, I agree wholeheartedly with my colleague Matt Wynne that Scrum is a vehicle for introducing a change culture at an organisational level and like the stabilisers on a kids bike for a team – see the full post here.

Agile Adoption – Just Say No

Mishkin Berteig has posted an interesting article regarding what he considers the best agile practices to implement now, that is those that deliver the highest return on investment. After the recent reshuffle here I’ve had the opportunity to start to work more closely with a couple of our development teams which has been great.

I agree with all of the points that Mishkin makes, I would in fact add one to them, I think teams should be running Retrospectives from the outset, one of the fundamental principles certainly in Scrum terms is to Inspect and Adapt and it’s not until a team starts to learn to understand its’ own performance and has the desire to improve itself will they realise any value in what they’re doing. Retrospectives give teams an opportunity to reflect over their last iteration / sprint and indeed over the entire time that they have been working towards delivering the software, it allows them to see the improvements that they’ve made as well as the areas that still need some work.

As I get to spend more time watching and helping teams adopt agile practices though, I’m starting to distil further my own opinions on how to approach a so called adoption, I think this largely boils down to 3 things:

1. Understand Why

It’s a concern that so often I hear people talking about that fact that we’re doing this one agile or see people doing a sit down stand up (the clue’s in the title folks) just because they think they should be. Before you get started take a look at what you’re already doing; what is it that you think you could be doing better, understand why you think you need to change, you could perhaps even consider running a retrospective to gather some information first.

2. Be able to clearly state your vision for any change

If you’re going to make a change, I think you should be able to clearly state not only the reason why but the vision you have for how the change will be effected and most importantly where you’re aiming for. In that, I also think you should need to be able to measure how effective the change you’re making is. Discuss the principles that are aligned with your vision, I think the Lean Software Development principles are a pretty good starting point for a discussion round this.

3. Don’t use the word agile

This is a bit of a difficult one. If you’re going to change what you’re doing and even have any inclination to want to use agile techniques, don’t call it agile. Why? Well, for a couple of reasons; Firstly there are those people that you’ll come across that are naturally resistant to it and it’s better not to expose yourself to that pain in the first place and secondly, I don’t think that to be agile should be the end goal. Sure business agility will deliver a lot of benefit to your organisation which they’ll thank you for but agile isn’t necessarily the only way to achieve that. By constantly reviewing what you’re doing and aspiring to do it better at all times you’ll deliver huge value, Dr Deming’s plan-do-check-act cycle (on which agile is loosely based) should help you there as a framework by which to carry that out.

I’d be interested to hear what you all think, have I missed the point or am I along the right lines?

Beware The Iterative Approach

During one of our regular divisional management meetings recently, I was pleased to hear the announcement that all development projects will now be approached iteratively.

Strangely, even though this is the first real sign of an acceptance that we should be considering other methods for software delivery and given that I have been trying to promote alternative ways of delivering software for some time now, you’d think I’d be pleased. However, I feel nervous and am inclined to urge caution.

Why? Well, I’m just not sure that the people that are making this declaration actually understand what it means to be iterative, sure it means that we’ll approach stuff in iterations, mini phases if you like, but haven’t we seen that somewhere before? Let’s say you have 6 features to implement and your initial estimates suggest that each of those will take a month to complete, I think that what’s being suggested is that we’ll approach each of those in an iteration. What happens if the sixth feature that you do actually ends up taking 2 months? More importantly, what happens if the sixth feature is the one that is of most value to your customer?

In my opinion, approaching software development in an iterative manner means that, given the example above, you would consider a portion of each of the six features and look to complete each of those portions in the first iteration, and then revisit them (starting again if necessary)  in the second and so on and so until all of the features have been delivered. The two main benefits of this are that the customer gets to start using their software as early as possible and secondly, information starts to flow from the development team about their confidence of being able to deliver to the afore mentioned estimates.