My mind wonders…

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.

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.

My second bullet point in the Eyes On The Prize post that I made recently was Breaking the Shackles of the Brand. Perhaps this point is applicable more to the other areas of the business that I have worked in but then a derivative of it also exhibits itself elsewhere I think.

In my experience whilst working in the B2C facing division I thought that people were somewhat blinded by the brand that they were delivering, believing that that alone would be enough to generate traffic and to retain audiences. I tried to impress upon them that this was in fact stifling their ability to generate more traffic, that they should pay attention to the way in which products like flickr; facebook; any of the google or yahoo! offerings and many more are delivered, that it is in fact the feature sets that deliver the traffic to the sites and indeed generate new traffic.

In my own department, I think the observation is a lot more subtle. I think that the business units that we engage with are inclined to focus on how the proposed product looks rather than the requirements. However, in this instance, rather than trying to change that I think we need to understand it and embrace it understanding how we can elicit requirements through specifying how a screen will look for example.

Does it really matter? Well yes, I think so, I think that a Product is derived from a number of Projects but there are 2 other reasons why I think its important to distinguish between them.

Firstly, I think that the word Product serves to focus peoples minds on the fact that what is being delivered is expected to return something on its investment.

Secondly, and perhaps more importantly, I think it suggests that the software that is being delivered needs to compete with the offerings on the market not only in the short but the long term too. When pieces of work are in the initial stages of consideration here we take the opportunity on to indicate whether a buy versus build decision could be made. When considering the long term we should be considering any additional phases of work undertaken and whether they continue to improve the product and keep it ahead of its competitors.

It’s this last point that I think James Shore makes very well in his Do We Need Projects? post.

When I started reading books about Agile one of the things that I found difficult to comprehend was how it translated to the enterprise environment. They all spoke about delivering products, never project, the point is subtle but a mindset shift  that I think we need to make.

I’ve been very fortunate to work in a number of different areas of our organisation. Recently, I was given an opportunity to work with another department and business unit that deliver one of our biggest B2C sites.

In doing so I spoke on a regular basis with the business sponsor for the site reporting progress but also suggesting how they might deliver the site in the future.

In my conventional role, I work within a division that is focussed at delivering software to the other business units meaning that it is more B2B.

My role has been refocussed recently meaning that unfortunately I will no longer be able to work with people in the way that I have been but I wanted to offer my opinion on what I thought were some concepts that the area in question needed to understand to continue to develop.

I sent the following list to my boss and the director the other day with the intention of using them as points for conversation:

• Product vs. Project
• Breaking the shackles of the brand: Focusing on delivering features rather than the brand
• Amplifying learning = Removing the middle man = Aligning delivery teams with business units and business units with delivery teams
• Reducing Time To Live / Cost To Market / 80:20 rule
• Manufacturing vs. Engineering = Chemistry vs. Biology
• The long tail effect
• The wisdom of crowds / UGC.

A bit of a random list, I must confess, what I have realised in retrospect though is that the majority of the points above actually apply to the B2B area that I work in too.

I think in essence, what these points allude to is that, in my opinion, development teams exist to deliver value and that perhaps, some of the behaviour that I see when at work would suggest that we’ve lost sight of that.

I’ll use the next posts I make to elaborate on the points above, if for no other reason than to clarify things in my mind.

Edit:  It was brought to my attention that the content of this post was potentially offensive, in light of the readership base, I think these comments are fair. As such, I have altered the post, hopefully the sentiment won’t be lost as I think an important point is being made.

We’ve been trying to promote the use of Unit Testing for some time now but have only really seen a limited amount of success in my opinion. There’s a number of reasons for this I think, some is down to the lack of training and support that we provide the developers and some is down to the fact that we’ve never really enforced coding standards (something that we have identified and are now working to resolve.).

Where we have seen success it was either from our stronger developers, or from the contractors that have come in with previous experience in unit testing. Considering the amount of contractors that we have recently recruited and that during the recruitment process we have paid particular attention to ensure that they understand the principles too, I had hoped that reaching a critical amount of people that just did Unit Testing would start to bring the other members of the department along.

It was interesting then to see Ed Gibbs’ post the other day about the difficulties they’re having in promoting the use of TDD. We’re considering changing our approach to unit testing in that we will probably be mandating that no application with at least 75% coverage will be allowed to be released to our environments.

I also came across this post on Doug Seven’s blog which is similarly of interest. I’m actually in the middle of composing the mail that I will send out to both our developers and the Project Office to let them know about our thoughts on both Unit Testing and Continuous Integration.

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.