A Lesson Learnt, It’s Not Just About Creating the Right Environment

Following a discussion with members of one of the teams that I work with this week and given a little time to reflect, I think I’ve learnt an important lesson which will help me re-focus myself going forward.

I learnt that it’s not about creating the right environment for a team as you perceive it to be; it’s about providing that team with the necessary support so that they can create the right environment for themselves.

I’ve used “it’s” a couple of times in that statement so firstly let me quantify; I hold the belief that my role within a team is to help them be more effective and that in actual fact I work for the team as opposed to them working for me. Since joining my current company, amongst other things I have been striving to build an environment in which the development teams can work at a sustainable pace. One in which they are afforded the ability to strive towards creating better quality software. I want the people that work within the team to be able to have some fun and also to be able to take pride in the work they’re doing. One of the key things that I’ve been selling for example is that the teams should feel comfortable in their ability to be able to take a requirement from a stakeholder and wrap up in the associated body of work any refactoring they deem necessary.

What I’ve realised since the conversation and following a subsequent one, is that all of that has been seen to be largely hollow talk and that the team in question actually felt that they didn’t have the support, particularly given their burgeoning pipeline of work. I found the last point particularly frustrating at the time, I couldn’t understand why the team members weren’t just going ahead and operating in the manner in which I thought that I was allowing them to. I was convinced that it really was simple; I’d said that they had the capacity within themselves as a team to operate in a certain way and yet their behaviour suggested otherwise. I got to a point in fact where I felt almost depressed that all of my efforts to create something that I believed would yield wonderful results hadn’t been realised and in that respect, I’d not done as well as I could.

Importantly to me, what I’ve realised now is that I’m not spending enough time with the people doing the work, listening to them and understanding the way in which they are working and seeking opportunities to learn from them and ultimately, gaining a better understanding of how I can help them more.

And what of my renewed focus? I’m not going to stop doing what I was doing before. I still think there’s a need to be doing that. It’s time to compliment that with actions as well though.

Tagged , , ,

Dunbar’s Number in Relation to Team Size and the Effect of Shuffles and Shaping

I had an interesting chat with Steve Freeman at the Limited WIP Society meet this week about the way the relationships within a group change in relation to it’s size during which he introduced me to Dunbar’s Number. Based on my reading so far, Dunbar’s number would appear to be commonly thought to be in the region of 150. In the context of our conversation though, Steve suggested that it was actually a sequence (If I remember rightly 1, 2, 5, 12, 30 … 150) of numbers through which you could identify the points at which relationships within a team change.

I’ve always held the belief that in terms of team size, there is a sweet spot of greater than or equal to 5 and  less than or equal to 8. I’ve previously observed that a team of less than 5 find it difficult to self organise and whilst I can’t substantiate this, I theorise that it may be possible to tie this back to the work of the likes of Belbin and Tuckman. At the other end of that scale, I think that a team larger than 8 needs to consider further the leadership structure and it was this point in particular that led Steve to raise Dunbar’s Number.

Of particular interest to me though is that by coincidence, the department that I work within maps to the sequence outlined above. In the past year our organisation has grown and as a consequence the department has roughly doubled in size. Throughout that growth we’ve made some changes to the way in which the teams are structured going from 3 teams with roughly 4 people on each, to our current state of 4 teams with on average 6 people. We’ve chosen to introduce or at least formalise somewhat the existing Lead roles that we had in place (Rob has previously posted details of the Roles and Responsibility documents that we created at the time for those interested.). Through the processes that we use within the teams, we’ve placed a greater emphasis on communication and I think that is paying dividends. Furthermore, communication at a departmental level is good too.

There are of course areas in which I feel we could improve, none of which I can necessarily single out at this stage, it’s my intention to spend some time understanding them more with other members of the department over the coming months. With the probable introduction of another 4 people to the department this year and the fact that that will take us ominously close to a contingent of 30, the next number in the sequence though, I’m keen for my own curiosity’s sake to attempt to measure the effect of any new team members joining. Not only within the context of the team but of the department at large.

Which leads me to question what to measure? I’ve previously used rather crude measures such as capacity of the team to do work both in the lead up to the introduction of a new person and for a period of time thereafter (I appreciate now that this was wrong, mapping a team’s productivity to it’s overall well being was naive.). I’m thinking of perhaps using something like the satisfaction chart towards the end of this post though I must confess that the value I think would derive from the data would be questionable. I’ve always quite liked the Pillar’s of Agile retrospective because as a tool it can be used by a team feasibly on a regular and ongoing basis to drive recognition of the results of the continual changes they are making to their practices. I wonder if this could be purposed in a different manner, I can absolutely see it working at a team level, I’m not sure how it would work at a departmental level though.

How about you? What if anything are you measuring outside the classic delivery / throughput criteria within your team and or department (in which case outside of appraisals too) that could you point to and say “This event caused this impact on us as a team.”? Does it matter to you that this sort of thing be measured?


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 , , , ,

The Greatest Trick The Devil Ever Pulled Was Making People Believe That He Didn’t Exist

James Shore made a great post the other day, Stumbling Through Mediocrity in which he talks about how dysfunctional companies will never truly reap the benefits of an Agile adoption as they aren’t inclined to actually change their ways. Rob Bowley then followed up with his post, Agile Isn’t Enough likening the introduction of agile to dropping a bomb on the internal workings of an organisation which then sends out ripple effects with much wider repercussions that actually get ignored by managers.

I posted a while ago about the fact that I thought that all a team needed to be successful was a clear set of parameters to work within and the support needed to build a learning culture and I maintain that opinion. Indeed when I started at 7digital I was keen not to sell any particular methodology. I set out 3 things that I thought that the department as a whole should focus on; Focus On Quality, Releases as Non Events and Building a Learning Culture. Whenever I spoke about those things I was careful and still am to a certain degree, not to use the dreaded “A” word.

One of the biggest impediments to introducing a change in process whilst I was at my last company, aside from the abundance of people with their own political agenda, was my attempt to introduce “Agile”. I realise now that rather than bestowing the virtues a bunch of practices I should have spent more of my time talking more about the principles. Furthermore, I should have found out whether or not people wanted to change. If they didn’t perceive there to be a need to, then it was my responsibility to find out why, perhaps they had a point and perhaps even in having that conversation they may have heard my point a little more. You live and learn.

What’s interesting though is that whilst there were a large number of people that I used to perceive to be willing to fail, pretty much all of them wanted to get the job done or the project delivered but I was putting it down as a failure because we hadn’t successfully engaged with our Customer, we weren’t in my opinion delivering everything that we could be for them and we hadn’t truly enabled the development team to deliver a quality product. Often I would sight agile as I thought that it would be the answer to these perceived failings and I still think it is, ironically it became a barrier to it though.

Given the posts I mention above, it would suggest that I am not alone in my point of view. My take on it is though, everybody hears the “A” word and thinks “here’s a process that we can use to deliver this piece of software” but actually it won’t. It requires commitment that a lot of people just aren’t willing to give and in many respects, perhaps the word Agile is in fact a hindrance.

Perhaps we should just start sitting with our customers more and hearing exactly what they want from the software that we deliver them and in doing so, put our case across about what we want from them. Do we necessarily have to persuade them of anything other than that we want to deliver the best quality product and that we want to do that by working as closely with them to understand their business model, that we want to as honest and transparent as possible about how we’re progressing. It’s keeping these conversations going throughout the project that’s most difficult. And it’s that very thing that we should be working on the most. The arguments have been won already for how much more successful we are when we use certain techniques as opposed to others, they should be implicit when we say we’re going to develop software.

Madmen In The Halls

I read Tom De Marco’s book Slack a few months ago, the first chapter titled “Madmen in the Halls” starts by suggesting that:

“The legacy of the nineties has been a dangerous corporate delusion: the idea that organizations are effective ony to the extent that all their workers are totally and eternally busy. Anyone who’s not overworked (sweating, staying late, racing from one task to the next, working Saturdays, unable to squeeze time for even the briefest meeting till two weeks after next) is looked on with suspicion. People with a little idle time on their hands may not even be safe. As [one of the authors friends] at Digital Equipment Corporation told [him] during the company’s darkest days, “There are madmen in the halls looking for someone to ax.” Of course, the ones they were looking to ax were the folks who weren’t all that busy.”

It’s sad to be able to draw parallels with some of the rash actions that were being taken then and the drastic ones people are being forced to take now.

Inevitably, as people look to make their respective companys’ more efficient and trim their bottom lines, Development teams are called upon to get the latest cost / time saving feature delivered as soon as possible.

It’s at times like this, when we’re being asked to go as fast as we can it becomes increasingly difficult to sell the fact that we need to deliver a quality product rather than one in which we’ve cut corners, as Jason suggests in his post, perhaps quality will suffer as part of the credit crunch. But now is precisely the time that we should be pushing harder to see the quality of our product improved.

I’m a believer in the Lean principle that you should decide as late as possible and that development teams should seek to defer decisions until the last responsible moment. Should we defer that decision to include unit tests, to tackle that particularly naughty piece of the code that is always causing us problems or to automate our build and deployment process. Definitely not.

Choosing not to pursue quality from the outset is almost like behaving like a student, leave doing it until the last minute and you will either hand in something that’s rushed, doesn’t really meet the expectations and will therefore need to be reworked or having to ask for an extension to the deadline.


It’s like trying to get home when you’re drunk

I met some friends for lunch the other day and when asked how it was going in my new role, I said to them that it was all a bit like doing the Hokey Cokey at the moment. To put that in context, there are a number of changes that I want to see happen here which are superficially, very simple. In attempting them though, and as anybody else who has attempted to implement any type of change will know, you take a step forward, you take a step sideways and sadly, you even take steps backwards.

One of the friends that was at lunch with me summed this up a little better when he suggested that it was rather like trying to get home when you’re drunk. Let’s face it, getting home is a relatively easy thing to do (I’m assuming that you’ve not ended up in another country here…), you often come a cropper though, you might fall asleep on a bus and go past your stop; You might even just be so wobbly that when you’re walking you actually cover 3 times the amount of distance that is actually necessary. The thing to remember though I suppose, is that you get there in the end. You might even learn something along the way. Like for example, to get a taxi next time.

Having had time to reflect on the time I spent at my last company, one of the things that I’ve realised is that for me personally, it’s important to recognise the small wins. If you don’t and you spend your time just raging against the machine at large, you’re not going to do yourself any favours and really if it’s that bad, take some time away, come up with another plan and approach and start again.

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 , , , , , ,

We’re Hiring

Well, it’s been an exciting 5 weeks since joining 7digital, not just for myself but for the company too. I’m sure most of you will have seen some of the press coverage we received on Tuesday when we were the first in Europe to go 100% MP3 and DRM Free. As part of that we also announced opening up our API through our partner program.

Obviously this will increase the demand on the development team here so, as the title suggests, we’re hiring. I’m looking for a couple of Developers at this stage as well as a Software Architect. We’re not going to be able to offer the earth in terms of salaries, what we can offer you though is a very exciting company to be part of, a development team which will be changing lots over the coming months with an increased focus on quality, simplicity and agility.

We’re looking for people that are passionate about their trade, people that want the ability to make a difference and to be part of something. I really believe that my role here is to facilitate change and not to direct it, and that change should come from the people that are doing the work on the ground and that could be you.

If you’re interested, feel free to drop me a line through careers.inbox+development [at] 7digital.com or if you would prefer, contact me directly through my linkedin profile. I’m sure I can persuade you just how much fun this place is and will be to work, come on, when else would you get an opportunity to work in a place that has an Official Badge Of Awesomeness From TechDigest (See the bottom of the article.).


It Was A Stone Groove…

And so it was. Somebody left that message in the leaving card that I received last week when I left BBC Worldwide. I spent an incredible 4 and a bit years working there and have many fond memories of the place and people.

So what now? Well, I’ve started as a Development Manager at 7digital, a start-up based in Shoreditch (Apparently now known as Silicon Roundabout), which promises an exciting opportunity to be part of something as they look to expand their development capabilities. Expect more of the same from this blog (that is, irregular updates and occasional rantings) as I endeavour to help them with things to come.

Now, off to go and do some research on this Waterfall thing, I’ve heard that it’s all the rage.

Tagged ,


The Stretchy MonkeyThis has been overdue for some time now but I should announce to the wider audience that Charlie Rough was born on the 23rd May at 10.40 weighing in at a healthy 8lbs 13oz. Mother and baby were doing well then and still are, we’ve had a few issues as I’m sure most new parents do but thankfully everything seems to be settling down a little now.

We’ve had a bit of time so far for GeekDadding though all we’ve managed to do is create him his blog and email address. More soon though I’m sure and with the recent update to the Lego Digital Designer I think that’s where we’ll be starting.