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.

Advertisements
Tagged , , , , ,

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.

Tagged , , , ,

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.

Tagged , , , , , ,

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.

Tagged , , , , , , , , , ,

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.

Tagged , , ,

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.

Wax on, wax off

I’ve been following a thread on the Yahoo Scrum Development group recently, in it a discussion has been taking place as to whether or not the name of Certified Scrum Master course is in fact a little misleading when in actual fact, the course that you attend neither ensures that you are a master nor does it test you in any way to be able to certify that you meet a given set of standards. The inclusion of the word master I presume is due to the fact that Scrum defines a role within the team of Scrum Master, the arguments against the word certification do perhaps have some foundation though.

Inevitably, as the mailing list thread was actually started by a post from an author with a subject of “Scrum is not Agile” (The premise of which was that a lot of companies are jumping on the Scrum bandwagon and then calling themselves Agile, when in fact Scrum is just a step down the line to Agility, something with which I agree.) other opinions about how effective Scrum is come to the fore, in one of these, an author states that he thinks that it’s not until you have implemented Scrum, in part or wholly on at least 3 projects that you can see where the practices it defines stand or fall and certainly not until you can start to criticise it as a process. In a reply to this author, I think Kelly Waters makes a good point that principles should come before practices (The reply links through to a blog post which is well worth a read.).

In a conversation that I was having with somebody the other day he said that if the movies were anything to be believed you could get a black belt in any given martial art by meditating in a monastery for a couple of years. By the same token I don’t think my attendance, or anybody else’s for that matter, of a Certified Scrum Master course certified me nor made me a master, it aided me in bringing clarity to some of the reading around the topic that I had been doing and also allowed me to ask Mike Cohn, a well respected member of the Agile community, some questions that my reading hadn’t covered.

We’ve recently sent some people on a CSM course which has aroused others’ interest in the subject. When I saw an email from somebody requesting attendance of one of these courses I was a little sceptical as to the reasons behind the request and if I’m honest, a little annoyed. For me it’s important that we don’t lose sight of the main goal which is to deliver software more effectively. I think that taking an Agile approach will aid us in achieving that, I also think that there are elements of Scrum that can form part of the solution but it’s more important for me that people realise that it’s necessary to understand the principles behind what is being proposed before jumping on the next band wagon, be it Scrum, XP, TDD, FDD etc.

What’s in a name?

I’ve done a lot of reading about the topic of Project Management using SCRUM and worked on a project before Christmas in which I used it as a framework. I would like to think that one of the successes of the project was that it has opened a few peoples eyes to the fact that there are different ways of running projects other than perhaps the more traditional methods. It has led to a lot of people starting to talk of the use of Scrum in the organisation. This is no bad thing, I must confess though that I didn’t follow the framework to the letter, furthermore, nor would I suggest it, I do think it has a lot to offer but it is important that you implement it in a way that works for you rather than blindly following practices dictated by somebody else.

It’s better to understand the principles and the values. I have always suggested that people read some of the books that I have and also a number of blogs that I subscribe to. I suggest these with the intention that they get sufficient information to enable them to make their own mind up, for them to then be able to have a discussion with somebody else as to the merits of taking an approach like that.

Papers like Scrum and XP from the Trenches make very interesting reading and focusses on the outcomes of implementing practices but are certainly no starting point, rather perhaps the Agile Manifesto.

For me, the understanding is as important as the implementing, a point that is made very well by Tobias’s recent article.

Tobias makes some points that struck a chord with my own thinking. In his first point he suggests that Product Owners should be part of the team. One of the successes of the Skunkworks project that I worked on was the time commitment from the steering group, sure we suffered from a lack of direction at time though I consider this my own fault more than anything but they were always there when we needed them. If anything I would request for future projects of that nature that one Product Owner is nominated at the beginning of a project and that they, where possible, collocate with the team.

The point relating to length of Sprint / Iteration is interesting, I used one week Sprints on the Skunkworks project owing to the time scales that we had, this worked well for us but it was very intense. Thankfully we never hit any major problems that deflected our main efforts too much, in subsequent conversations that I have had with people though I have recommended a 2 week Sprint, in my mind a 30 day cycle would still be too long for the team to develop any sort of rhythm. This is my own personal feeling, I guess it’s just what works for you.

Having only used Story Points to estimate for a short while I can not really comment, however when we did use them I could see how they benefited as a tool to both gain a better understanding of any given problem but also to speed up the estimation process.

Points 4 and 5 are the ones that stand out the most for me. We didn’t implement a task board until about 3 weeks from the conclusion of the project but it had a profound effect in everyone’s (By everyone I include people outside of the team.) understanding of what we needed to achieve in the time remaining. From the outset I had maintained an Excel Spreadsheet for the Product Backlog which was fine but it wasn’t visible to the people it actually needed to be to. The more I think about it, the more I think that visibility is a key driver to the success of a project, it allows for people to make decisions earlier that can bring something back on track for example, rather than being confronted with something monumental at the end (The biggest failing of a waterfall approach in my mind.).

Finally, I can see that point 7 makes some sense, I do however think that new teams, either freshly assembled or established ones with some exposure to SCRUM, benefit from somebody taking the SCRUM Master role on. I think that an important part of the SCRUM Master role is for them to own the SCRUM process and that they should be able to act as a a reference point / coach to team members.

For me, the principles of SCRUM just make sense, what makes more sense though is doing what is right for you to get the project delivered. It doesn’t matter what you call it. As long as it works.

Well, Well, Well

This is the first of a couple of posts that I have had in my drafts waiting to be completed for a while now, I apologise if they seem a little out of context.

I came across this blog post in which the author makes a couple of points that are similar to those that I was trying to convey whilst working on the Skunkworks project before Christmas to the Steering Group and in particular, the person who was acting as the Product Owner.

I know all of this stuff shouldn’t still be bothering me, I am off work for another 9 weeks but it is. It’s important for me that the product that we were working to develop doesn’t fall flat on it’s face. Before I left it sounded though that it was going to be released to the general public and a press release made about it, having just checked the URL though it would appear that somebody has put some sort of Username / Password on it to deny access so maybe it has been sent to a limited audience. Let’s hope so.

The trouble that I think there is with releasing software that is not fully functioning is that, in my opinion, people are prepared to try any new piece of software, be it desktop or web based, I share the sentiments of the author of this post, however, that people will only continue to use software that is functioning fully. I think the rule that 80% of users only use 20% of the functionality is true and that if we as a company are to continue to develop software aimed at the commerical market we should concentrate on delivering the core feature set very well with our first bit of funding looking to then focus on the other 80%. Sadly, during the meeting that I attended with the digital steering group prior to my departure when I suggested this as an approach, I don’t think it was taken on board. Still, on my return I can perhaps continue to work moving to delivering software in that way. I think there are definitely others in the department that share my desire to see us work in this way.

Given the time constraints that we were exposed to during the project’s lifecycle one thing that we didn’t build in was scalability, we did everything that was necessary to allow to us to deliver as quickly as possible, because of the hosting environment that the organisation has and the controls that are enforced we were unable to use things like rails or django which is unfortunate as these would have obviously given us an advantage in terms of speed to deliver. Scalability will become an issue if this sofware is released to the general public without a team gaving been established to support and develop it going forward. In my opinion if the company is going to fund this going forward a Scrum team or at the very least a project team should be established to progress this piece of software in a way that those on the digital steering group would expect.

It’s interesting times for my company and my department in particular and I am dissapointed that I am not there to experience it and be part of it.