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:
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:
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.
Lean thinking has long been an influence on Agile but over the last couple of years we are seeing the links being made more often and by an increasing number of people. The fact that Scrum owes much to Lean thinking is pretty well known but I suspect that we will be hearing a lot about Lean Software Development and Kanban in the near future. I don’t really want to discuss Kanban here save to say that I’m interested in it though I have to confess that, as yet, I don’t know very much about it. The presentation that David J. Anderson gave to Agile Scotland at the end of 2007 about his experiences with Kanban was inspiring and marked it out in my mind as a good way forward.
While an increasing number of folks are investigating the potential of Lean for software development we don’t necessarily want to get into a situation where its Lean Vs Agile. Martin Fowler has written that the opposition Lean Vs Agile is a non-starter because the two are actually very deeply intertwined. In saying that, however, we shouldn’t lose sight of the fact that there is much that Agile can learn from Lean. Perhaps the most important thing to be gained from Lean is a proper appreciation of what Kent Beck calls the “social purpose of work”. It may be that Lean can help address the persistent criticism that “software development often seems to occur in a purely technical context devoid of business or social purpose”.
Richard Durnall, another ThoughtWorker, has suggested that there are four main contexts in which Lean can directly contribute to Agile. All of these are interesting but its the first and last ones which really ring true for me. His first idea is that Lean can be used as a metaphor for Agile when trying to explain the benefits to executives. The argument goes that it is all the easier to put forward an idea when one can compare its benefits with, for instance, the Toyota Production System. But its his final point that is most significant for my interests. Lean has a long history of successfully introducing large scale change into organisations and this is something which, Durnall points out, we could do with in IT. The wider and more holistic perspective which Lean brings is very often missing from Agile as it is practised by many teams, though this almost certainly doesn’t equate with what the originators of the methods or the signatories of the Agile Manifesto intended.
My main research interest has been distributed Agile and in this area we can see that a narrow focus on team and task that characterises some methods, and particularly XP, wouldn’t be appropriate. My research has shown how large and small teams are successfully adapting Agile practices and principles to suit their particular circumstances and levels of distribution. However, this adaptation only works where certain guiding principles are followed but unfortunately up to now there has been little direct guidance on what these core principles actually are. Experimentation and experience are being used to discover what these are in a process which owes a great deal to the philosopy of learning by doing. Could it be that Lean thinking is what is required to make this quite haphazard endeavour more systematic?