Comments for Valtech UK

Comment on Test driven development – problems when developers opt out 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 Software release management – 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 Test driven development – problems when developers opt out 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.

Comment on Using JIRA for Agile Project Management (without Green Hopper) by Mashooq Badar

Mashooq Badar — Wed, 13 Jan 2010 10:59:06 +0000

Hi Dafydd, I’m taking your comment to mean that you are advocating the use of story boards for both Iteration and Product Backlogs.
Physical Story boards are an effective way of representing your Iteration Backlog and work well with co-located teams. Arguably, they become unwieldy when dealing with a large Product Backlog and/or teams where all members are not co-located as we often find with our larger clients. And sometime (more often then you’d think) there is no physical space for a story board. In addition larger organisations may already have project reporting built around an existing tool and may dictate use of that tool.

The spirit of this post is to not provide a replacement for the story board but simply another alternative among many for representing your Product and Iteration backlogs. Also combining it with mylyn (integrated into your IDE) helps to alleviate the “electronic energy drain” you rightfully point out.

Regards

Comment on Using JIRA for Agile Project Management (without Green Hopper) by Dafydd Rees

Dafydd Rees — Tue, 12 Jan 2010 15:21:04 +0000

I really have to disagree. The physical storyboard with real, physical cards wins any day over greenhopper. The problem with technical people is that we’re too enthusiastic to adopt technical solutions.

The problem with electronic storyboards and tracking is that they become a huge, overcomplicated distraction. People end up spending more time on the tools than on the work the customer paid for. Those tools also tend to dictate the process – something that agile teams should be able to change freely and easily without having to fiddle with inflexible tools.

I really wouldn’t start worrying about electronic tools until you’ve got a mature, working team with real, live, successful software… otherwise there’s a serious risk of being swept into the electronic tool energy drain.

*8-)

Comment on Agile Risk Management by Harvard Business Review on Managing External Risk « husdal.com

Harvard Business Review on Managing External Risk « husdal.com — Wed, 09 Dec 2009 11:57:31 +0000

[...] While preparing this post and doing some background research I also discovered a new term: agile risk management, but I think I will leave that for a later post, so let’s have a closer look at the chapters [...]

Comment on Task boards and kanban boards by Alastair Brown

Alastair Brown — Wed, 02 Dec 2009 09:15:33 +0000

I’ve had an interesting experience recently coaching a team in Scrum where we were getting a build up of WIP, during planning. We made the space for “In Progress” cards on the board much smaller than before. Interestingly it has caused people to pause for thought as they try to move that ticket into busy “In Progress” space. Silly trick that seems to have a benefit!