Category Archives: scrum

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.


One Piece Flow, One Piece At a Time

There’s been a lot of interesting conversation regarding the use of Kanban / Continuous Flow Development models and it’s something that I see a great deal of benefit in. I find myself struggling to understand whether it would be possible to start a team that hasn’t really used a process of any description before out with something like Kanban and for them to reap the benefits that people are discussing.

I think the reason I’m struggling a little is that I’ve read nothing that would suggest that Kanban in particular is teaching a team the principles behind the practices and whilst I’m sure that some would disagree, from what I’ve read there isn’t too much focus in that area and given Kanban’s relative infancy, there’s little to speak of about the practices either. For example, whilst I’m sure most could easily see how something like Kanban allows a team to Eliminate Waste, might they miss the fact that the process of mapping your Value Stream allows you to See the Whole (i.e. that your kanban should represent all stages in the life cycle of a feature request)?

At the moment and perhaps given my current circumstance, I feel a lot more comfortable that using a vanilla Scrum implementation will help the teams here at least move towards understanding the principles behind Lean so that we would then be positioned at a later date to implement a flow based model. It was Benjamin Mitchells tweet

Good tips from @henrikkniberg on software processes: evolve the right process for your context, expand your toolkit and experiment!

earlier that prompted me to make this post though I was also reminded of Matt Wynne and Rob Bowley’s presentation at XP Day Evolving from Scrum to Lean. Matt Wynne in particular once posted that for teams, Scrum is The Stabiliser Wheels on Your First Bike and that for organisations, it is like a bulldozer.

Following a suggestion from Rob who attended a presentation by Jeff Sutherland at BT titled Shock Therapy and my later watching a video which is of very similar content, we’re running an experiment here with one of the teams and have got them using Scrum with 1 week iterations.

Scrum is a collection of great tools, and the idea is that when used in this manner, they will help a team very quickly evolve to understand the problems they are facing (retrospectives come in very useful here) and the advantages of working in small batches to best be able to deliver to their definition of done every iteration. It’s easily understood (I accept that to some Kanban may also be easily understood) and some of the agile principles are baked in, it increases communication between the Product Owner(s) and the development team and its iterative nature means that the team is doing this over and over and in doing so, means that the practices and the principles that we’re talking about with them are there for them to see in action, time and time again. I should add that we’re not using Scrum alone, we’re using engineering practices such as TDD, refactoring any of the legacy code we come across and generally focussing in on quality throughout, we’re getting acceptance criteria up front which alone is proving worth the effort.

If the ultimate goal is to move to One Piece Flow then, how specifically is our current use of Scrum helping us?

As I suggest above, there are a number of benefits to Scrum but in respect of doing 1 week iterations, first and foremost, it’s giving both the team and their customers a much greater degree of visibility and better still, it’s happening sooner rather than later.

From the team’s perspective, any of the issues that they are facing are immediately apparent, furthermore and small issues that we might not have caught in say a 2 or 3 week iteration cycle are raised in their importance. The team really need to remove any impediment that they come across as soon as they can to give them as much of a chance as possible of delivering the feature that they have committed to at the end of the iteration. Any problems downstream of the development work going on (e.g. testing, deployment) becomes much more apparent. Doing a retrospective at the end of each iteration and taking meaningful actions away is allowing them to tackle some of the more process based issues they face, they have started to realise too that rather than relying on key people to do repetitive small jobs that come in, they should all be capable of carrying out the task and that furthermore, there would be real advantage in writing a tool so that the job can be done by people outside of the team.

From the business’ perspective, the team is creating a lot of data, quickly. This data includes the team’s velocity, the amount of time a feature that is requested takes to go from being requested to be being delivered and in that we’re also tracking how long that feature is in development.

Whilst I mention above it’s worthy of note again that secondly, it’s helping the team form together as a successful unit, it’s forcing them to self organise. I’ve mentioned before Tuckman’s team development model (I’ve previously heard learning models such as Shu Ha Ri and the Dreyfus model referred to when discussing this advancement.)

Of course, we’ve had a few problems outside of the team too, there are some people that feel that the amount of time that not only do the development team require of their customers in prioritisation sessions and in analysing requirements but that they themselves spend in meetings every week adds too much of an overhead. So far I’ve answered this by saying that the team have some clear goals to meet and once they have done so, they are free to move to whatever they deem appropriate, be that longer iterations or indeed a Continuous Flow Model. I’m also working to help people understand that software development is an inherently collaborative process and that in my opinion, you’ll never see the true efficiency gains to be had from a software team until you change the organisation to accomodate that, something that this post by James Shore alludes to.

Anyway, I’m off to the eXtreme Tuesday Club’s inaugral Kanban Klub meeting tomorrow night so perhaps some of the things that I am struggling with about Kanban will be answered then. In the meantime, Scrum is seeing a little of a renaissance in my estimation as a tool to help development teams quickly mature in to ones that don’t just apply processes and don’t think to ask questions but ones that are questionning for themselves which process that they should be using.

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.

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.

The life of an Agile zealot

Zealot isn’t a word that you (by that I mean me…) come across too much but I’ve encountered it twice recently. I’ve been speaking to a couple of the senior management team about how I can sell Agile throughout the organisation and both of them have commented on the language that I use, one going as far telling me that I can sometimes come across as a zealot when I talk about Agile to people and if I remember rightly, the other told me that I can appear to be a fundamentalist.

Whilst neither of these descriptions are great from a personal perspective, the feedback is obviously useful and if I’m honest, it’s fair comment.

I want to see Agile principles and their associated practices adopted across the organisation, I think they offer a lot, both to the business and to the developers involved. Having given the feedback consideration I went away and thought about what I stand for and how I can communicate that to people in a manner that won’t alienate them to me.

My starting point was to think about what Agile means to me and to come up with 3 points. I’ve detailed those below:

  • About setting up development teams to embrace change, they do this through intelligent solution design and with increased involvement with the customer to understand business priorities and associated requirements.
  • About a process of continual planning rather than attempting to predict the outcome of everything in advance.
  • About delivering increments of working software to the client, both to suffice business requirements sooner but also to allow them to understand the capabilities of the software that we can produce for them.

I’d be interested in hearing other peoples’ thoughts on this, I must confess that I do find it frustrating that people just don’t seem to get what to me, are the obvious advantages.

I also volunteered to one of the afore mentioned managers to write a document describing how I see Agile development working here. As that comes about I will post samples.

Size does matter

I’ve just seen this post on Chip’s blog. He questions whether 30 days for a Sprint (which is what the Scrum process recommends) is perhaps too long, I’ve always thought so myself and in fact, if I remember rightly, Mike Cohn suggested 2 week Sprints on the Scrum Master Certification course that I attended.

When I ran the project before Christmas I used 1 week sprints, I deemed them to be appropriate as it was for 8 weeks and so I wanted to establish a rhythm within the team very quickly as well as provide feedback to the client as soon as possible. This placed the team under an immense amount of pressure and as Chip rightly says almost promotes a feeling of chaos.

What is also interesting is that we have a couple of teams that are permanently involved in a programme of project work relating on two of our biggest applications. Whilst those teams are primarily focussed on the development of new features they also have to handle the support calls that we receive that pertain to those systems.

The two teams in question have recently decided to implement Scrum, however, rather than the 30 day Sprints that the traditionalists suggest they are using 10 days. As I understand it, they have approached the problem differently with one team opting to roll the support calls in to their Product Backlog and the other having established a separate team that handles the issues.

I’ve also given consideration previously to how an Agile approach might work in one of our SAP development teams. About 6 months ago a live issues team was created to work through the backlog of bugs raised by the business. I think the Scrum model could be extended to manage the release of fixes and ]the business priorities within those. This is of course, always a little more difficult when there are multiple business owners, one method that I have been made aware of for dealing with this though is to allow a different member of the business to adopt the Product Owner role on a rotational basis for each of the Sprints.

For me though, I think 2 weeks feels about right for the length of an iteration. It doesn’t put the team under an undue amount of pressure nor does it extend the feedback loop by too much.