scrum (68)

Mis-badged and misunderstood

So many talk in terms “Agile/Scrum”, that Scrum became the reluctant flagship of Agile, largely as it was easily implemented on high level. And I have to admit, I was one of those lazy contributing to the lazy mash-up.

Don’t disappear in your own life

We get so comfortable with our life that we don’t venture out – so we disappear.

Scrum & Testing

In fact, a Scrum team need not have a manager at all. In Scrum, the team is ‘self-organizing’. To as large a degree as possible, they manage themselves.

R & D

Research and development – less of a specialised area, more normality.  Of course there is a lot of “keeping up with the Jones’s” marketing around a lot of newer technologies and techniques emerging. You can end up like a pinball, bouncing between different things, that are actually the same. If you alter the way to see coding, it can help.  A lot of the practices advocated in Agile and others, is Iterative and Incremental, i.e. the practice of shorter release cycles, and incremental releases within those cycles.  The ultimate aim is to produce a continuum of development, integration tested at source.  At at the end of each short release, the software should be demonstrable.

To achieve this not only takes applied effort to make the process work, but flexibility and adaptability. These are not two fashion words, they are important in Iterative and Incremental development, enforced with a Thor hammer with Lean development.  The Incremental part demands effective Continuous Integration, i.e.  the regular (usually daily) check-in of all code work and a set of automated tests run (usually overnight).  It leads to a better ongoing development and testing process, that can be sustained.  And avoid pointless stress. Burning out project team members is still ridiculously common, and it is not wonder developers and testers lean more to contracting.

In a truly communicative team, it is surprisingly how many changes can be made mid-stream.  In fact, if this voicing-up is encouraged, you can prevent things slipping further down a bad path.  If that isn’t encouraged  or an atmosphere of blame-culture exists, you are stuffed because problems can slip far down the line, to give you a step-down type bite on the behind.  There was a reason step-down approach to development is costly on modern IT projects.  There was an area of risk that never could be accounted for, until point of testing.  And even then, a more obscure issue could pop up on live system.

This is really to hammer home the reduction of risk, when adopting an R&D approach to development. It takes effective management and someone who has acute gift for time and resource management.  R&D doesn’t have to be limited to development, testers have long been using the open source world, or even their own programming skills, to assist the QA effort.  Sometimes a requirement only becomes apparent once a project is in movement. A project can learn from others of course, but will also have it’s own demands.

The best way to spread knowledge across multiple projects is not weekly meetings in the canteen or Starbucks. It is sharing resources around effectively (this is where Kanban can help). You don’t have to latch onto a methodology or set your store in clunky all-in-one “Agile” software. But taking ones more specific to your needs is a sensible approach.  You don’t find the methodology, it finds you – so to speak. And commit to the damn thing – I have seen so much weak Scrum-mastering over the last decade, it almost makes me weep for the fine methodology it is.  But even that approach seems slow now – the march of time!

Whilst it’s important to keep up with the IT world, its also important not to become a slave to it.  Development is evolving in great directions – more programming language agnostic directions, to help bridge gaps between requirements and code.  Testers are required to program these days, whether Selenium scripting or being able to debug code.  There is no escaping developers and testers have to adapt faster now, and project management even more so. Its a good time to dump the labels, and get to the core of a project which is the management of development. You can argue that R&D is a fashion label, and you are probably right.  Maybe it’s is better to say it’s right, if you have justification to use it – not just using the word!

Throwing out more proverbial babies

I knew it wouldn’t be long before Scrum came under scrutiny , and hence, in the firing line.  Scrum is far from perfect, but provided some kind of transition form palatable to both business and development.