My mind wonders…

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.

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.).

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.

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.

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?

One of my colleagues recently sent me a quote from this site which tickled me a bit.

“Those who do not have a clue are still debating about the process.
Those who know, just do it. (56)”

When reading through the rest of the quotes on the page I find the following one more interesting though:

“If you want to be a great leader, stop trying to control.
Let go of fixed plans and concepts and the team will govern itself.
The more prohibitions you have, the less disciplined the team will be.
The more coercion you exert, the less secure the team will be.
The more external help you call, the less self-reliant the team will be. (57)”

I must confess, I’m no Taoist, nor (other than having read The Tao of Pooh, which is another story) do I know that much about it, particularly in the context of Software Development, but in the respect of what a manager can do to establish a well functioning team or department, I agree with a lot of the points above.

I’ve witnessed my fair share of change in what is a relatively short career, I’ve seen it instigated by managers and I’ve also observed it come from the people on the ground. Each approach has it’s relative merits in any given situation, in my opinion though, the act of facilitating change will tend to success more than a command and control structure.

Self organising teams need to be nurtured, they need to feel as though they are empowered to make change, furthermore and perhaps most importantly they need a clear vision of their remit as well as some parameters to operate within.

I think that it is relatively easy to define the vision and parameters for a development team; they should seek to deliver value, aggressively tackle waste and to do both of those continually.

One of the things that is starting to interest me more and more though is business transformation and how some of the agile techniques such as self organisation can be applied. I believe that self organisation can be used as a mechanism to deliver enterprise change however, I think it is even more important to ensure success that a clear vision is communicated and that some definite parameters even if these may change later, to work within are stated.

A friend of mine that I used to live with, who was working as a consultant at the time, once told me about a meeting that he was in (if I remember correctly.) where somebody had used the phrase “Let’s not confuse motion with progress”.

I’ve long been campaigning for a change to take place here and, during my absence last week, plans were put in to action to make some within the department and another department that we work closely with. I tend to think that change is a good thing (as long as it’s not change, for changes sake), certainly I’m an advocate of continual change or at least, continual improvement. It’s the latter part of that statement where the difference lies and the reason behind this post.

Continual Improvement would suggest that you are striving to understand the issues that you have and that when you change, you are looking to adapt to the learnings you have taken, or try new methods that will potentially afford better results (with a general acceptance that you’re only as good as your last mistake). Think Agile, think Inspect and Adapt or from a Lean perspective, Amplify Learning.

When change comes down from the top you have to question the sensibility of it, there’s no doubt that it will be informed but just how accurate is it? I likened the way in which the changes are taking place here yesterday to somebody to something I read in Mary Poppendieck’s book – Lean Software Development – An Agile Toolkit. Whereas the traditional armed services in the U.S. (Army, Navy and Air Force) plan everything and then pass down commands through the chain of command, their Marine Corps plan up to a certain point and then rely upon the people on the ground to use their training and more importantly, their understanding of the issues that they are faced with to make the right decisions. I’ve just finished reading The Wisdom of Crowds which also suggests that as long as you meet some conditions, the crowd (i.e. many people) are more likely to come up with the right solution than the few.

Change is good, even making the wrong change isn’t a bad thing, as long as you have a mechanism in place that allows you to accept that you’ve made a mistake and to (if necessary) make another change which may completely contradict the change you have just made.

I’ve decided to switch the feed from my del.icio.us account to this blog off, if you still want to receive the feed you can subscribe to it here.

I’ve been following Karl Seguin’s foundations of programming series and have been impressed, it’s a good starting point I think and covers a lot of the technologies that we use here. He’s recently posted them all, compiled as a PDF, you can go get it here.

I’ve had little involvement with development teams recently (which I’d like to suggest is the reason for the lack of posts but then, I have to be honest…), the involvement I have had though has been with two projects, one of which was already in flight and for one reason or another, was faltering somewhat and therefore going through a re-estimating process, the other in the early stages of initiation, which as per our process requires some documents to be created and an associated sets of estimates to be produced for the business to sign off on the spend.

In each of the cases above I sat in on a number of meetings to try and aid the team come to an understanding of the work that was remaining / involved. I understand that any project will have budgetary constraints and inevitably a time constraint too, be it an arbitrary delivery date or not, I still find it frustrating though that we’re not asking up front the question of ourselves, “what’s the smallest amount we can do to add value?”. I’ve not come to a conclusion on this as yet as to why, perhaps it’s because of our process, perhaps it’s because we’re an internally chargeable resource and that as such we’re incentivised to drum up as much business for ourselves as possible, perhaps its just a cultural thing?

Either way, I think we’re doing a disservice to our customers (which are in actual fact just members of our own company and therefore ultimately this affects profit margins, a point well made by this blog post.) by not pushing back. If you look at principles like YAGNI used by developers, perhaps we should consider how we could apply this with the requirements that we see from our customers. Equally though by attempting to deliver everything in an allotted time we’re not giving ourselves an opportunity to deliver quality which leads to higher cost of support and change in the long run.

I’ve been advocating a switch to new methods of software delivery for some time now and I still stand by that, maybe though the real change to be made is company wide starting with a process of education (informed by us), perhaps the change isn’t about Waterfall vs. Agile, perhaps it’s more about us engaging with our customers more to discuss how we can work better for them by them working better for us and for this to happen continually to ensure that we aren’t just a cost on their balance sheet that has to be justified, that in fact we’re adding value that is apparent for all to see.

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.