A bit more to IT

I’ve been meaning to write a bit about the 2009 report from Forrester Research mentioned in the title of this post for a while now because its a really excellent summary of many of the problems facing Agile at the moment. It covers much the same ground as my earlier blog post which asked whether the adoption of Lean Thinking could lead Agile toward a broader focus. Having worked in Agile for a few years now I can relate to what they are saying and I suspect many other folks who are interested will have the same viewpoint.

Forrester interviewed a number of tech industry professionals for this survey including those from QA, product management, support, consulting and sales & marketing. They were very careful to include people from all areas of the business and not just developers- which is where the traditional focus of Agile has been. Forrester suggest, that if the goal of Agile is to shorten the path between development and customer, Agile must evolve to become more than a set of development-centric guidelines. The positive message from their survey is that there is still time to achieve this because, for most organisations, Agile adoption is not in its mature phase. This is not to say that significant progress has been made it is only that this progress has been made in terms of development teams and people closest to them such as QA.

At this juncture one might ask the question how could improvements in the development team, and their interaction with those outside, be a bad thing? Development teams are certainly the core area of value creation in technology companies; to use the automotive analogy selected by Forrester they are the engine of the car. It is their contention, however, that Agile methods have tuned the engine without upgrading the other components of the car.   This conjures up a number of images in my mind including a one of a hot rod with terrible bodywork and a massive gleaming engine in a rusty engine compartment!

For many developers tuning the engine is enough.  Agile gives them a better way to work and removes some of the things that developers don’t like doing, such as writing documents.  These things are great for developers but they have limited benefits outside the development team.  By improving, or optimising, only one area organisations will not be able to achieve the bigger goals attainable by an Agile engagement which recognises that development relies heavily on many other areas.  For example there is no point in having frequent releases if other departments are not able to fully market, implement or support the technology.

A number of people have noticed the changes to the wider organisation that the adoption of Agile development brings. The problem is that the changes outside the development team, though positive, are by-and-large accidental and relatively poorly understood.  How then are we to effect the changes required to attain the goal of Agile engagement?  Some people have argued that it cannot be achieved within the traditional scope of Agile and that new inspiration is required.  A growing number of people believe that Lean thinking is the way forward though as yet we don’t have many examples to look at.  As for Forrester they leave that question for a future report.

Just a moment ago I did a Google search for Agile Development in Edinburgh and much to my surprise this blog came up first.  What a nice surprise!  Must start adding more posts because over the past few months I’ve not really been updating it.

Last week I attended a seminar at Edinburgh Napier University on IT governance and its relation to project management. It was presented by Shirin Sherkat-Khameneh, a management consultant with many years of experience in both the private and public sector. The presentation had two goals, the first being to identify symptoms of ineffective IT governance and the second was to identify what a project manager can do to change this situation. Shirin’s basic thesis is that project managers often get the blame for things which are in reality symptoms of underlying issues with IT governance. It is worth noting at this point that IT governance is defined as “the rules and regulations under which an IT department functions”. The relationship between projects, which can be short-lived, and longer term IT issues, is an interesting one and as such the subject of this seminar stimulated my interest. As it turns out the presentation highlighted some familiar problems and delivered some useful insights.

From a project management perspective there are a number of issues which point towards problems in IT governance. The 90% syndrome is an important sign of failures and comes about when the majority of a project’s work is done but the final 10% takes a disproportionately long time to complete primarily because of emergent requirements. The problems associated with emergent requirements have long been understood though unfortunately the way that agile can deal directly with this issue has not yet reached a very wide audience. Several other symptoms were highlighted including frequent fire fighting, projects stalling mid-stream, lack of effective lessons learned and an inability to manage the customer.

From a business perspective poor IT governance can reveal itself in a number of ways including an inability to manage the customer and unclear medium and long-term plans, a symptom which is often called a lack of strategic direction. One of the other things mentioned was that the delivered solution has insufficient functionality to meet business needs. This is notable in that it is the opposite situation from what is often reported. The delivered solution usually has too much functionality most of which is never used by the customer. Either way it speaks of an inability to manage requirements, something which, as I have already suggested, agile is particularly good at.

The lack of direction mentioned in the previous section on the business manifests itself in a feeling that there is no shared purpose and that everybody is pulling in different directions. One way that this can be displayed is lack of cooperation and friction between different functional areas. A silo mentality can develop within an organisation and this can have serious consequences for the flow of information with a risk that the same mistakes could be repeated over and over. Other factors mentioned include inefficient use of staff, unnecessary bureaucracy and improvement initiatives hitting a dead end. Together these can combine to make for a de-motivated workforce.

Managers’ ability to make decisions can also be impacted by poor IT governance. The first of the issues mentioned was the lack of timely and informative management data to inform the decision making perspective. When there is a willingness to make decisions, which is by no means always the case, there is a danger that they may be subject to reversal. Overall one could say that the whole decision making process lacks clarity with those having to make the decisions not feeling empowered. This whole situation speaks of a lack of a structured approach to decision making.

Now the organisations which were exhibiting these symptoms were not failing but the key issue was that they were not delivering their full potential. In order for organisations to cope with greater and greater customer expectations, smaller budgets and rapid changes in technology they need to deliver to their whole potential. What can project managers do to promote improvement in IT governance? One of the key suggestions that Shirin made was to recognise the symptoms and see the root cause of the problems. The creation of cross functional communication teams was also proposed as a solution as well as a project manager’s forum to discuss issues and promote some of the knowledge management issues which were already highlighted as missing. Two other main areas for improvement were highlighted the first being the importance of continuous feedback from staff and putting in place a mechanism to see that these are addressed. Second was a formal approach to capturing, sharing and reviewing project management process elements.

Overall I would say that this presentation was insightful and is relevant to everybody with an interest in IT project management. It was one in a series of presentations organised by Pritam Chita of Edinburgh Napier University. I look forward to future sessions.

The subject of value and how to measure it is becoming more and more popular among agilists. A very useful contribution on this subject comes from Ryan Shriver in an article called ‘Measurable Value with Agile’ which is published in the February 2009 issue of Overload. His contention is that many organisations have no real way to measure the value delivered by the features they develop and therefore by extension no real way of assessing whether the right software is being created. Shriver draws the distinction between delivering the right things and delivering things right, further noting that Agile has proved particularly good at the later. Others have made comments along the same lines including an excellent piece by Kent Beck called ‘Learning from Lean’, which states that software development often seems to occur in a purely technical context devoid of business or social purpose. Broadening the perspective of Agile past a purely technical focus is an area where we can certainly learn from lean.

The solution to this problem which Shriver advocates is the so called value delivery approach which is a combination of existing principles and practices from the groundbreaking EVO method developed by Tom Gilb. Three years ago we were fortunate enough to have a presentation from Tom at Agile Scotland so my interest in this article increased when I read that it was a new practical application of EVO, a method which is often eclipsed by more popular Agile approaches such as XP. The measurable value approach doesn’t use stories or tasks to measure value as these have proved to be too low level to be of real use. Another interesting thing about the value delivery approach as described here is that it can be used in conjunction with Scrum which is the most popular of all the Agile methods.

There are six steps to implement the value delivery approach beginning with identifying stakeholders, objectives and resources. Three key questions should be asked during this first step:

• Who are my stakeholders?
• What are their objectives?
• What resources are available?

The second step involves the quantification of objectives which is undertaken not for measuring or tracking but to help clarify requirements. As Gilb says “The main purpose of quantification is to force us to think deeply, and debate exactly what we mean”. The connection is not made explicitly here but this type of logic very similar to that used to justify writing acceptance tests prior to the development of features. Overall this must surely indicate the importance which people are attaching to clarifying requirements as early as possible and an understanding of the perils of not developing this thorough understanding.

The next step is to identify targets, constraints and benchmarks. Targets are the performance levels that the team is trying to achieve. These are not provided solely from the stakeholders but emerge as a result of a dialogue between developers and stakeholders. Constraints are the levels that should be avoided or the minimum standards necessary to ship the product. Benchmarks are the levels achieved today or whats been achieved in the past, they enable an understanding of the current state and assessing how close we are to achieving our goal. The EVO concept of Planguage is used here very effectively to help clarify the targets, constraints and benchmarks and make it easy to identify qualifiers and sources.

When the team has decided how it’s going to measure success they need to decide how they are going to achieve these objectives. They do this by brainstorming design ideas a process which involves the whole team rather than just executives and product manager in order to get a better shared vision.

The brainstorming exercise will very likely produce more than one idea and to help decide on the best one to pursue the value delivery approach advocates using impact estimation on three of the possibilities. The table created by this estimation allows the options to be easily compared and is a powerful tool for the job. The use of impact estimation is perhaps the strongest element of this whole article as it provides a simple yet powerful solution for a very real problem in many teams- namely how to decide on the best options.

Impact Estimation

The final step is Agile integration. The standard Scrum methods are used to make sure that things get built right but when value delivery approach is added in the team gets rewarded for delivering value not just developing features. If after the first few iterations there is not sufficient movement towards the goals then this option can be cancelled and another one of the options can be picked up.

The Scrum product backlog is integrated with value delivery in three ways:

• User stories should be priortised by business value
• Teams should prioritise quality requirements alongside functional requirements
• Both user stories and quality stories should use story point estimates

In addition to the normal end-of-sprint activities teams should also be reporting the progress on measurable value.

The value delivery approach has been used on a number of projects and a number of problems with adoption have been identified. Two problems stood out from this list.  The first is appreciating the concepts of measurable value where Scrum has been adopted bottom up. The developers in these teams are doubtless focussing on stories to the detriment of everything else which is a problem I have experienced at first hand in an XP context. The second major issue is that if there is no continual support from business for measurable value then the development team will not think that this is important. So in other words for this approach to work it needs to be supported from both sides. I can see the business side wholeheartedly adopting the value delivery approach but I think there may be more of a problem making developers shift focus from user stories.

In conclusion I would say that this is an excellent article which outlines several novel approaches to very real problems. Its great that EVO is being used as part of this solution and good for its chances of adoption that it can be combined with Scrum. As Shriver says this is just one of the attempts to combine Scrum with other methods to get better results.

The subject of user acceptance testing is pretty crucial for agile development teams.  Its certainly an issue which we have given quite a lot of thought to in our XP team in the past few months.  There are two points I want to make in regard to this, the first concerning our overall approach to UAT.

To break it down for those people who are not aware of the debates around automated UAT in agile there are basically two schools of thought.  One says that the developers and the customers should sit down before the coding starts for a particular feature and put the tests together for it.  The rationale behind this is that this will initiate a discussion between these two parties during which a better understanding of the requirements will emerge.  This ongoing discussion between developers and customers is particularly important in agile as there is no formal requirements spec adopted by most of the main methods.

The other way of thinking suggests that the tests should not be written way before the production code is done because, in that state, they are not actually doing what they are supposed to namely documenting the code.  This view is informed by a Lean perspective which says that we should cut down on artefacts which don’t contribute to our overall goal.  In other words tests which are not documenting code are ‘inventory’ and should be cut out.  This second approach is one of the ways in which Lean thinking is influencing the day-to-day approach to agile.  I think we can expect to see more and more of this in the near future, which, as I’ve recently written is a good thing.

Whichever approach is adopted for testing it still remains crucial for agile teams.  Given the increasing popularity of agile and the importance of UAT for it one would expect there to be many different frameworks to allow automation of the process.  Not quite.  The ones we have tried in our team all have problems and while we have settled on using Selenium we often speak of it as being the ‘best of a bad bunch’ rather than ‘best of breed’.  Now ours is a very small team and it got me wondering how larger teams cope with these flaky frameworks.  Do they use them at all or are they in fact more reliant on the manual variey of UAT.  I don’t know of any studies which investigate this issue but they would make for interesting reading.

Now I’ve written about one of my favourite Social Informatics thinkers on this blog before- Rob Kling.  I’m pleased to say that another Rob has re-entered the blogshpere after a bit of a break.  I’m talking  here about Rob Lally who has, until recently, been at J P Morgan.  Rob always has something interesting to say on a number of subjects in and around software development and I find its worth surfing over now and again to see what he’s been posting.  One of his recent contributions, which I liked a lot, tackled the question of whether Agile is a characteristic or a culture…

Getting sent random job adds from recuitment agencies is a bit of an occupational hazard of working as a developer. Most of it is effectively just spam, however, just occassionally there is something which is good for amusement value. My colleague just got sent a job add from an agency which contained the following:

“My client is currently looking for an experienced Java Developer to develop a redundant, high available,distributed solution that will enable them to deliver its value added strategy.”

Well whats that all about? Seems like the person in question has taken a list of requirments and converted it into a description without really understanding what is being said. Humerous though this may be it also quite worrying. How is the consultant going to find the best person for this job when they don’t even understand what their client is looking for. Sadly this is very much the norm in terms of IT recruitment and one is left wondering exactly what value the agencies are adding to this process.  In these difficult economic times can we afford to entertain this kind of thing?

Having worked in an industry for years which has no agencies I can confirm that one can survive without them if employers are willing to do a bit of work around hiring.  Unfortunately this is often not the case.

Well I best start off by saying that I didn’t win though I did end up really enjoying the evening.  My presentation worked out quite well as a 20min piece and I was very pleased with the response to my visuals.  I think what probably let me down was my presentation style.  It was not quite as polished as I would like, however, as they say practice makes perfect.  I really enjoy presenting things and am very keen on doing a bit more work on this aspect.  And what of the other two candidates?  Well the quality of both the other presentations was very high and both were very interesting subjects.  The eventual winner, Elizabeth Hutchison, delivered a really effective presentation which really impressed the judges.

The whole event was well organised by the APM committee and the choice of venue was excellent.  What I most enjoyed about the evening was the feedback from people about my ideas.  It seems that managers from other industries were able to grasp the context of what I was saying which is very heartening considering the importance of convincing people of the benefits of doing agile.

Thanks to everyone who has wished me well for this event.  Once again my special thanks to the agileScotlanders for making this research possible and to Napier University for giving me this opportunity in the first place.

The slides I used in the presentation are here.

I’m going to do my presentation “‘If you have programmer’s on two floors, forget it’: The challenge of distributed Agile” next Monday 2.2.09 at 7.30pm at Napier University.  I’m very excited about the prospect of talking to this group who were so key in getting this research done in the first place.  I’ll put the slides from this presentation up here shortly.

Publicity details for the talk are here.

After an amazingly quick turnaround of a couple of weeks Clarke Ching has announced that his excellent business parable Rocks into Gold is now published.  Clarke is to be congratulated on the speed at which he has managed to get these topical ideas out to a wider audience.

This tale, which shows how a bit of agile thinking can help software people keep their jobs during the credit crunch, is available in three different formats from this site.  Even those whose pockets have already been adversly affected by the credit crunch can partake of this 20 min read because one of the versions is free.  I think that I’m going to go for the paperback version, even though it costs £1 more, because its more tangible than the download version.  Roll on the publication of Clarke’s larger book where the ideas outlined in Rocks into Gold are expanded upon.