Comments for Valtech UK

Comment on Global Day of Code Retreat 2011 – London, UK by Valtech Labs » Global Day of Coderetreat – retrospektiv

Valtech Labs » Global Day of Coderetreat – retrospektiv — Sun, 18 Dec 2011 21:16:58 +0000

[...] blogposter om dagen: Hardy Ferentschik Valtech UK Visst har de snyggt tema på sin blog? [...]

Comment on Does Agile work in UK Government IT projects? by Kevin Murray

Kevin Murray — Wed, 20 Jul 2011 15:07:43 +0000

Hi Grant,

Thanks for your comments. I do agree with you that desired outputs can be identified up-front, with Agile Inceptions as one way of achieving this.

In my argument I was focusing on the Alastair’s possibly ambiguous phrase ‘clear specification of outputs up-front’, which I can see as challenging irrespective of methodology.

regards

Kev.

Comment on Does Agile work in UK Government IT projects? by Grant (PG) Rule

Grant (PG) Rule — Mon, 18 Jul 2011 19:19:01 +0000

Hi Kevin,

Well said. A good reply to an ill-informed article.

I agree with all your points, except that I’d say that customer & supplier can achieve a clear (and quantified) agreement of the *desired outcome* up-front (irrespective of whether you adopt a lean-agile or a batch-&-queue approach to the work).

Note that I wrote ‘outcome’. While the desired outcome can be agreed and quantified, I’m not suggesting that it is possible to specify the *outputs* in detail. This is an impossibility. But you can agree to deliver a quantity of functionality (with particular, desireable quality characteristics) very early on, then explore the detail requirements incrementally to achieve the stakeholders’ all-important outcome.

Best regards,
Grant (PG) Rule

Comment on Does Agile work in UK Government IT projects? by links for 2011-07-18 :: Blog :: Headshift

links for 2011-07-18 :: Blog :: Headshift — Mon, 18 Jul 2011 16:40:15 +0000

[...] Does Agile work in UK Government IT projects | Valtech UK (tags: agile government it) [...]

Comment on Bad Code: The Invisible Threat by Ricardo

Ricardo — Fri, 08 Oct 2010 07:53:41 +0000

Excelent post! Well done.

Comment on Concrete problems when developers opt out of TDD by Andrew Rendell

Andrew Rendell — Tue, 06 Apr 2010 12:45:05 +0000

All of the applications on this programme use the Spring container. These applications fall into one of three classes:
- MVC based web applications (using Spring MVC);
- components which deliver some sort of service to other applications or clients running on mobile devices (RESTful webserices exposed using Jersey and implemented using Java POJOs);
- event orientated applications, again implemented using POJOs.

You are familiar with Spring (I had a look at your site) so wont go into an exhaustive description of what it does but the main benefits for this particular client were:
It is very easy to understand with a shallow learning curve compared to some of other container technologies that they had used (J2EE in particular).
The Dependency Injection pattern coupled with TDD pattern encourages cohesive class structures and good encapsulation.
It is lightweight in its operational, development and runtime cost.

There is the additional benefit now that most Java developers are very familiar with Spring these days and the patterns it encourages. This was not the case when I originally introduced the client to Spring several years ago.

Your question was quite broad so if my answer doesn’t help, please shout!

Andrew.

Comment on Anti-pattern: The release vehicle. by Dean Warren

Dean Warren — Fri, 19 Mar 2010 10:16:58 +0000

I agree with you general thrust. However, how do we address the organisation issues? I can see ways around the budgeting problem, but the waterfall/ milestone based attitude, coupled with a general risk aversion – especially to things we don’t understand, like “change” and “technology” – is a difficult nut to crack.
I think that waterfall makes people feel like they are in control of the process: they have time to understand what’s going on. I, personally, find this approach distracting, because it brings focus on what is being built rather than the benefits it will deliver (outputs verses outcomes – management should be interested in the outcomes). Agile, of course, can be used to deliver measurable benefits in an incremental manner, therefore you think it would be embraced by programme managers and business leaders alike.
The move to a more agile approach and your vision of almost continuous release requires a more “empowered” environment – a threat to some managers. I would argue for a more goal/ objective based approach with devolved budgets based on longer term goals rather than discrete projects. Based on these goals, the product backlog can be fed based on individual departmental objectives – hopefully getting around the problems of convincing a marketing executive that your “invisible” technical change is actually important to the organisation.
While we are cracking this nut, there might be some pain – someone has to have the vision to lead an organisation through that, and if the people at the top can only see as far as the next quarterly and annual results that might be a difficult vision to sell.
Thanks – your article made me think about this… perhaps you or one of your colleagues has come comment to make on the broader business culture change aspect of this – I’d be interested to read about Valtech’s experience with this.

Comment on Concrete problems when developers opt out of TDD by Dafydd Rees

Dafydd Rees — Thu, 04 Mar 2010 21:40:15 +0000

“Unit tests which typically target a single class and are executed without instantiating a Spring container. ”

It sounds as though you use Spring in all projects – or at least assume that people do.

On what kinds of things do you use Spring?

Do you use it on all projects?

What reasons do you have to use Spring?

Just wondering…

Comment on Prioritising stories within a sprint? by David Draper

David Draper — Fri, 19 Feb 2010 09:48:12 +0000

I see a risk of us violently agreeing

First of all, “Priority:Must” as you put it is not helpful, for me prioritisation is simply this one first. This is a distinct conversation from scope i.e. must vs. won’t.

As with any guideline there are exceptions – I don’t propose for a moment that we replace common sense with prioritisation.

The focus of the post was in response to common advice given to Scrum teams. Limiting WiP (in terms of stories) in this context is achieved by the sprint. The question posed was “should we prioritise stories within a sprint?”. My response was yes, this could be combined with task level WiP limits though this is not common.

Comment on Prioritising stories within a sprint? by Ruud Rietveld

Ruud Rietveld — Thu, 18 Feb 2010 12:06:17 +0000

You say you recommend using prioritisation in a sprint. I think I want to achieve the same result, but I would not call it prioritisation.
You say prioritisation helps because:
* The team is challenged to find ways to move stories to Done faster
* The team is encouraged to collaborate and help each other out in favour of picking new tasks
* We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
* Where a sprint commitment is missed we loose 1 story rather than a bit from each story.

I do not see how prioritisation helps in that. You only need to say that you want to limit WiP. “Priority: Must” has never incentised people to work harder.
Prioritisation can also work against you: If there is time left at the end of the sprint for only the smaller bottom unstarted story, and not time enough for a higher-up unstarted story, you have to start the higher-up one, and will end the sprint with two unfinished stories instead of one.