Steve's Blog on Rational Requirements and Design
with Tags: agile X
Have you ever been on a software project and asked yourself "where has all the time gone" ? Often the reason why a project is late, is because of all the time being spent on stuff that doesn't help get to the end goal of a deployed system. On an average project some 70-80% of the time could be classified as waste (waiting, hand offs, extra processes, extra features, defects, motion, partially done work). So although automating tasks is a great thing to do, in order to deliver software faster you have to work out how to reduce the waste. For most projects a 20% reduction in waste is easier to achieve than a 20% increase in automation, and has a much bigger impact on when the project is delivered. If you're interested in understanding more about how IBM's collaborative lifecycle management tools can help, then Paula White and I have just published an article looking at how the tools can help with the various forms of software development waste.
SteveArnold 270000T4JF Tags:  shoring continuous off agile outsourcing uml architecture delivery devoid 3,237 Visits
Well it's a new year, and what with the usual new year resolutions - getting fit, learning to play the guitar, and blogging regularly ! - I thought I'd also have a go at that other new year tradition - some technology predictions for 2013!!
As I'm a software engineer, they really come down to an optimistic, and somewhat biased view of some software development trends I've seen in 2012 that I hope will continue in 2013....so here they are:
Continuous deployment becomes common place - I think there is a perfect storm of desire to improve development-operations, improvements in virtualisation/cloud and in the software tools to enhance current build practices to make continuous deployment practical. So I'm looking forward to a year where this starts to become the norm rather than the exception.
Architecture comes back in fashion - a lot of organisations are struggling with agile, and in response to this I'm seeing a lot of teams turning back to doing more architecture and design. They are using the models in a very collaborative way - to communicate how the software works and seek improvements via colleagues' feedback, so that the software is as good as it can be. So 2013 will be the year when architecture cements itself into teams' agile practices.
Software development comes home - Is offshoring development really cheaper and faster? Well from what I've seen, a lot of organisations struggle to get a model that works - and they end up with a waterfall, highly contractual model, which doesn't deliver what they want in a timely fashion. So while there is definitely a place for global delivery and off shoring, it's not the panacea that some organisations thought. So in order to get better visibility, more agility I see more organisations reversing the off shoring trend and growing their software development capability in 2013.
SteveArnold 270000T4JF Tags:  collaboration uml agile modelling collaborative architecture 1,408 Visits
I'm an unashamed modelling fanatic - but in the last few years it's become a topic I'm almost afraid to mention. Why ? Well in the fad focused industry that is IT, modelling (with tools) has become deeply unfashionable. There has been a lot of misunderstanding about why modelling with tools is useful, not least because agile is often misinterpreted as anti-tool ( ofcourse it's not, you still use compilers, editors, src control, continuous integration tools etc). So where does modelling fit, in an iterative/agile world and why do I think it's starting to become popular again?
Well firstly, I tend to think of two broad uses of models -
Modelling for communication and collaboration, and modelling for specification (i.e. Code generation ). Now it's the former that is absolutely vital - even in agile/iterative development.
One of the benefits of agile is that you produce working software regularly - but while this guarantees that the code works, it's still the first version - like the draft of a document. So the question is how do you make the software as good as it can be - so that it delights users - rather than just satisfying a spec ? Well the answer, just like improving the first draft of a document , is that you need to communicate how the software will work, and then collaborate on that with your colleagues to improve it.
Obviously you could write the code, peer review it, and then change it - however this introduces rework and waste. So a better approach is to produce a high level model ( not a detailed specification )showing the key information, not too much detail, but enough information to enable someone to understand the high level approach and offer suggestions for improvement. This kind of modelling takes a few hours - so very possible in a short iteration project - yet still allows for others to comment and suggest improvements before the code is written - resulting in improved software that delights users.
"Im an agilist, and I do agile modelling on a whiteboard" I hear you cry. And if you're in a small colocated team this works perfectly, and exemplifies what I'm talking about. However in my experience, as teams scale and become distributed, they tend to forget about modelling altogether - rather than focusing on it more.
So why now ?? And why do I think modelling is coming back into fashion? Well according to Gartner agile is going though the valley of despair on the hype curve - and in my experience more and more organisations are starting to look at modelling as a possible approach to improve their software delivery.
Secondly the tools around modelling have improved significantly in recent years, transforming modelling tools from single user desktop tools, to collaborative team tools. This is vital as it simplifies modelling as a team, reviewing and commenting - making it possible for this to be very lean and to minimise waste.
So perhaps modelling isn't such an anachronism after all. And given the current trends towards distributing agile, then modelling for collaboration will, I think, become critical for successful projects.