Monday, 13 November 2017

Textual description of firstImageUrl

A Principled Approach to Innovation

One of the greatest unspoken benefits of networking and attending conferences is the sharing of book recommendations. The books that have had the greatest impact on my professional development or direction are often recommendations from peers that have been made during conversations at conferences. In fact I've literally today bought a book that was recommended to me over a pint at the EuroStar conference last week.

It was just such a situation earlier this year when I had the pleasure of John Stevenson's company for some time at the Romanian Testing Conference. He recommended a very easy reading book on innovation and creativity called 'The Myths of Creativity ' by David Burkus. It turned out to be a very useful recommendation indeed, as not only was it a great read, but soon after I found myself taking on the responsibility of running a group promoting innovation across my company.

Progress with Caution

During the summer a lot of the discussion on my work internal social network was around the need to involve more people (specifically across the development teams) in innovation activities. As can often happen when we are foolish enough to take holidays, in my absence the CEO volunteered me to run a group to drive innovation across the company. Whilst it was something of a surprise to come back to, I was very happy to take on this challenge.

At the same time I was wary of creating such a group. In my post on 'The Innovation Silo' I explain many of the challenges that I've seen companies face if innovation is owned by one individual or group at the expense of getting others in the company involved. If not approached carefully then setting up an innovation group in the company would result in just such a silo risking consequences of de-motivation for those not involved. So it was with a mixture of excitement and trepidation that I scheduled the first session of the River Innovation Group (aka "the RIG") and asked for volunteers.

'I'm not a creative type'

During the week before I ran the first session, I was involved in an internal workshop and one of the participants mentioned how she was nervous of volunteering for the innovation group as she wasn't a 'creative type'. This was someone with a wealth of customer experience and a positive approach that I felt would make a great contribution to the invitation group, so this reluctance worried me.

As luck would have it I'd not long before finished reading Burkus's 'Myths of Creativity' based on John's recommendation. I asked if the individual would consider still joining, and recommended the book as one that might give her some reassurance that her contribution would be really valuable. I explained that, in the book, Burkus attacks some of our preconceived ideas around innovation and creativity such as 'creative types' and 'lone innovators' that were the basis of her fears. I was pleased when she agreed to come along.

The conversation got me thinking about the need to establish an understanding, both within the Innovation Group and the wider organisation, about the purpose and nature of the group to avoid misunderstandings around why the group was set up. I decided to use the book as the basis to structure the first session. 'Debunking' some of the myths around innovation would be the perfect way to set the scene for our group and give confidence amongst all the attendees in their ability to make a difference.

The Myths of Creativity

In his book Burkus identifies and challenges ten myths that people often believe when attributing the factors of success in innovations. I suggest reading the book to get a detailed perspective on the 10 myths, however I will try to summarise them here :

  1. Eureka myth. Genuine flashes of inspiration rarely happen. Research has shown that what appear to be 'flashes of insight' are actually the culmination of periods of research followed by stepping back from the problem allowing 'incubation' of the problem and the subconscious mind to make connections.

  2. Breed myth: There is no such thing as a genetically creative person, both personality traits and genetic links have shown no correlation with creativity. The creative label often comes with a role, however we are all able to think creatively around problems.

  3. Originality myth: Innovations are rarely entirely new ideas - more often they are the novel application of existing ideas to new contexts, or the combination of ideas in new ways.

  4. Expert myth: It is not just the experienced experts in a domain that drive innovation. New perspectives and ideas can come as easily from a novel viewpoint.

  5. Incentive myth: Incentives to innovate are extrinsic motivators, whereas it is an intrinsic motivation to solve a problem that yields better results when it comes to innovation.

  6. Lone Creator myth: Edison didn't work alone on the light bulb, he had an entire research company to back him. We often associate the most famous individual with inventions that actually are the result of brilliant team efforts.

  7. Brainstorming myth: Throwing people in a room with post-its and white boards does not provide a good source of creativity. Brainstorming can be effective if it involves the bringing togther of people who have had a chance to think about a subject beforehand, such that the brainstorming brings together their ideas.

  8. Cohesive myth: We can't all get along. Sometimes a healthy level of conflict and disagreement is needed to promote genuine progress on solving problems.

  9. Constraints myth: Constraints don't stifle innovation , actually as long as they are not too restrictive they can promote it as we look to innovate to solve problems within the constraints that we have. Would Tesla's cars be as efficiently designed if Musk had a full production line at his disposal?

  10. Mousetrap myth: Just creating a good product does not guarantee success. The world will not 'beat a path to your door' - you still need to put a huge amount of work into making that idea successful.

In the kickoff session for the RIG I stepped through each myth in turn, and went on to explain what Burkus presents as the true foundations for organisational innovation * An engaged team with a desire to innovate * A culture that is accepting of change * Strong expertise and domain knowledge * A defined creativity methodology or set of work practices

I explained how I felt that River had the first three of these in abundance. We are an incredibly engaged organisation with expertise in both business and technology domains, that promotes agility and acceptance of change across the business. Where I suggested the group could focus was on the methodology aspect - promoting processes and practices to support innovation that would allow us to harness the engagement, expertise and desire to change that we already possessed.

10 Types of Innovation

To examine the areas that we can consider as a target for innovation I referenced a second book - the "10 types of innovation" (confusingly - why is it that these things always come in tens?). In this book the authors present a model of innovation that goes beyond just product innovation to cover other areas where companies can be innovative and disruptive

  • Profit Model
  • Network
  • Structure
  • Process
  • Product Performance
  • Product System
  • Service
  • Channel
  • Brand
  • Customer Engagement

This model was very useful to set the scene that we weren't just looking at software innovations but any areas of the business where we could add value through adopting new mindsets and approaches.

Establishing the Principles of Innovation

When setting up any new team or group I find it a very useful exercise to establish a set of principles for the group. Working together as a team to identify the principles helps to break barriers and bond the team. Creating principles also helps to flush out any differences of opinion about the purpose and activity of the group and gets us all on the same page. As new people join the group the principles then provide an excellent basis for introducing them to the way that the team operates, and we can refer back to them in situations where we feel that we might be straying off our original purpose.

The first task that I set for us as a group was therefore to establish a set of principles for the RIG. Given my experiences with innovation silos though, I'll admit that I did provide the first principle to start things off:

  • The RIG does not own innovation at River, we are here to promote innovation across the organisation

Everyone input something and we pulled the results together into the following:

RIG PRINCIPLES

  1. The RIG does not own all of the innovation, we aim to foster a culture of innovation across the whole of River

  2. The RIG is an open community and encourages participation from people across the business

  3. We encourage cross-functional knowledge and thinking and look for opportunities to innovate in all areas, not just products

  4. We aim to continuously improve and question and innovate on our existing ideas as much as new ones

  5. We don't dismiss any ideas and celebrate any failures as opportunities to learn

  6. We aim to empower and encourage people to be confident in owning their ideas seeing them through

I was very pleased with the result. The group were keen to keep the membership fresh and encourage new members to come regularly so that we avoided becoming a silo. We established an approach of having different people run the session each time and to suggest and vote on topics to avoid making the group to just one person's agenda.

We've since already had session two and identified some great new approaches to adopt to identify the challenges we face (which furnish great opportunities for innovation), to constantly question what we're doing, and to focus ourselves so as not to spread our opportunities too thinly.

Accepting Change

One of Burkus's key foundations for innovation is an acceptance of change. I've rarely seen a company change as rapidly as I've seen here in the last 18 months, and empowering people across the business to be part of innovation is going to be key to people having a positive perception of that change. As I hand over the reins of running our next RIG session to another member it is my hope and belief that we have something that is genuinely going to make a difference, not just in the group but across the business, and not just now but for a long time to come. Oh, and if you are wondering about the individual who was reluctant to join - it almost doesn't need saying that she has made a fantastic contribution to the group and it's a much better group for having her there.

References

Sunday, 1 October 2017

Textual description of firstImageUrl

Software Development - A Sisyphean Task?

It's rarely a pleasurable event returning from holiday. No matter how much you might enjoy your job it's still a sad event when that family time is over and you have to return to the more mundane routine of home, work and school. On arriving back you're never quite sure what emails are sat in your inbox or what post has landed on your doormat.

(I sincerely hope that you take the opportunity to take time away from emails on holiday - it's a holiday for a reason and the extra productivity from a genuine break far outweighs the apparent benefits of 'keeping on top of things' whilst away)

My return from holiday this year was markedly more pleasurable this year than previous years thanks to :

  1. My inadvertently buying double the amount I intended of a wine I'd never tasted at a spanish wine merchant and subsequently finding it to be quite delicious
  2. My finding a copy of Gojko Adzics new book 'Humans vs Computers' on the doormat as I arrived through my front door.

It's rapidly becoming one of my favourite books on software.The basis of the book is a series of lessons on the common pitfalls in software with strong and amusing anecdotes of projects that have suffered them.

  • Individuals getting charged tens of thousands of pounds for hotel rooms and car rentals because of decimal point position bugs
  • Computer systems refusing to initialise on 29th February as they didn't recognise it as a date
  • UK Post-codes failing to match because of inconsistency in how they handle the space between the incoming and outgoing postcode sections
  • US drivers being assigned huge numbers of fines due to inadvertently selecting number plate sequences matching the default text that traffic officers would enter in forms for a non-readable plate.

Whilst the stories that Gojko shares are amusing and eye-opening in equal measure, there is a more worrying aspect to them. The reason behind many such anecdotes being amusing is the fact that they strike a chord of familiarity with so many of us. The fact that so many people that have worked in software development, particularly testing, can identify with the calamities that can occur when working with leap years shouldn't really be trivialised as a subject for amusement. The problems with decimals that, as Gojko points out, cause so many embarrassing and costly mistakes, really aren't a laughing matter. I've spent my entire working life working with computer software and yet we still don't seem to be able to match addresses between different IT systems. We do seem doomed to making and discovering the same mistakes over and over again.

A sisyphean task?

I was chatting to a group of testing enthusiasts including Rob Lambert a while ago about the current state and future of testing. Rob in his eloquent way went on something of a diatribe about the fact that we won't be able to truly progress until we find ways to solve these same issues that come up again and again. I couldn't agree more.

When I started this blog it was with this post suggesting that software testing might be perceived as akin to the task of Sisyphus - forever destined to repeat the same activity. I wonder whether in actuality it is software development as a whole that on too many occasions is more like a Sisyphean task. Despite the availability of open source code repositories, shared libraries, Nuget Packages, development frameworks and ever more functional programming languages, we do still seem to have a habit repeatedly striving and struggling to solve the same issues that have been plaguing software development teams since the days of the BBC Micro.

Even casting my mind back over the last year or so I can recall examples of problems that I have encountered in exactly the 'classic' areas that provide such a rich supply of anecdotes for Gojkos' book.

  • Last year I was forced to implement a manual backup to an automated validation process for people using one of my systems as it was not possible to reliably check a match between postal addresses algorithmically between two separate systems
  • On a related system I was forced to prioritise a change to the UK postcode processing of an interface as an associated website provided postcodes without a space whereas our own system utilised and expected spaces.
  • A couple of years ago a system I supported encountered an issue where the 2015 leap second resulted in massive unexplained CPU usage requiring a server reboot to correct
  • In the last couple of weeks I've had to revisit discussions on calculation of performance figures in a customer dashboard as the example figures we were given demonstrated rounding up to the nearest integer whereas to maintain consistency with other systems we actually needed to always round down to one decimal place.

It's not all bad news

In a weekly publication I read there is a section "It wasn't all bad news" where they present some more light hearted stories from the week to stop the reader from being too depressed at the state of the world.

In a similar vein I'll leave with this sentiment. It may be easy to rue the apparent lack of progress in avoiding issues in software development, however at the same time there are still many reasons to be glad:-

  • Software testing as a craft is still very much needed.
  • Testing Heuristics have far greater longevity than expected and so our fantastic testing resources such as Hendrickson, Emery and Lyndsay's Test Heuristics Cheat Sheet are still valid and relevant.
  • We can enjoy great stories around software issues, such as those that Gojko has collected together in his book, relate to them and continue to share them even years later.

So I suggest taking some time to have a read of "Humans vs Computers" and maybe feel better about things the next time you can't match a postcode, or your software stops working on February 29th.

Sunday, 13 August 2017

Textual description of firstImageUrl

The Big Bang

In the last month two significant things happened in my work.

  • Firstly we completed a major release for a high profile client.
  • Secondly I got the opportunity to work in the new River office for the first time.

This is an exciting time in my current company as we strive to move not just to taking an agile approach in our software development, but to embracing agility across the organisation by working flexibly and incrementally, always looking to add value and regularly review priorities. Working in an agile way on internal projects is one thing, taking an incremental approach with customers is not always as straightforward, particularly with customers who have a large set of requirements, a target date when I they want these to be delivered by and an expectation of getting it all delivered in one 'Big Bang'.


New Office

I worked in the new River office for the first time recently. In a mildly surreal experience a colleague and I were initially sat at desks in the middle of a nearly empty room.

I then I had to move to the corner of the room as the chap who was using an industrial cleaner to deep clean the carpets needed me to move. I wasn't bothered by this, or the noise of the cleaner, or lack of tea making facilities. I had a desk in an isolated space where I could get my head down on a task that required some careful attention. There was a lot of value in that office space for me.

Typically you would think of a move to a new office as a classic big bang operation with everyone packing boxes and piling in as part of a large scale coordinated event. Right now in typical fashion for my company, we're taking things incrementally and getting a lot of value even before the whole thing is ready. People started having meetings over there and some folks went over just to get some quiet 'heads down' time. Then slowly teams started to move in as and when they could be supported and at this stage about half of the company are now based in the new site.

Old School

By way of a contrast, in recent weeks I've been involved in a major release of software to support a customer engagement programme. As this was a replacement for an existing site the customer was keen to get as many of the features in place ready for a big launch as possible. The release was also the first to be based on a set of core capabilities that we were investing in ourselves that needed building from the ground up to support not only the bespoke needs of the programme in question but also other similar programmes in the future. This magnified our uncertainty around the development, and therefore the risk, significantly.

When working with new customers and trying to convince them off the benefits of an iterative approach, one of my favourite images to reference is one from Henrik Kniberg

It gives a very simple representation of why delivering incrementally can provide a safer option, particularly in projects with large scope or many deliverables. Not everyone is familiar or convinced by such an approach and many still insist on rolling the scope, and risk, up into a major release - as was the case in my latest project.

Did it work?

I have to say that in terms of big bang customer releases my most recent one was one of the smoother ones that I've been involved in. There was a lot of effort put in and some longer hours as we approached the release, however we did release within 2 hours of the target time with the majority of the features in place and a generally happy customer. If I was to attribute this success to anything I would highlight two factors

  • We ran a number of user testing sessions during development to demonstrate and get feedback on the features delivered to that point, essentially embedding a level of incremental delivery into the larger project
  • We did manage to negotiate a number of features out of scope of the initial release thanks to a very reasonable customer and some open conversations.

As we approached the release the customer could not have been more reasonable about things that were/were not going to be included. Nevertheless there was still a degree of pressure around the delivery that resulted in some anxiety, not least on my part, around getting the release out on time. I was painfully aware of the potential for a sense of frustration around having to compromise on some of the features that would be available from day one.

It is hard to over-state the sense of satisfaction and relief that comes in getting software released. The difference in anxiety level in a team that has successfully delivered working software and is adding to it, as compared to one that is in the process of accumulating a large inventory of unproven software, is tangible. From a personal perspective, the discomfort I felt in having a fixed scope of work and a fixed release date to deliver led to some very stressful moments.

What has happened since has also not been plain sailing. Despite efforts to maintain our standards around our core capabilities, we still accumulated a small degree of technical debt leading up to the release such that we consequently struggled to deliver the follow up work to the time-scales expected by the customer. We simply weren't in a position to progress them as quickly as we thought due to the final push to deliver the release.

In a riff on a Benjamin Franklng quote, I once read that 'the smell of poor quality lingers for long after the champagne bubbles of an on time release have gone flat'. I can relate to the sentiment. I'm pleased that we made the right decisions to maintain quality under pressure in most decisions, but not all. Despite the apparent success - the retrospective that we held post-release exposed the discomfort felt by some of the team in the days leading up to the release due to having to increase the pace of development.

A Confession

At this point I should make a confession. The fact is that for 9 years in my previous company all we did were big bang releases. Our customers didn't want new versions of the software every 2-4 weeks so we'd typically roll up new functionality into 6 month releases. Over this whole time we consistently delivered on time and with the target major feature set. In my more moribund days at that company (I am prone to a high level of self criticism) my VP would repeatedly remind me what a fantastic achievement it was to repeatedly release on time over such a period of years.

In order to achieve this we tailored our approach so that they were very well suited to tackling Big Bang releases successfully:

  • We worked constantly with the same team on the same product so had highly predictable velocity
  • We generally operated to product roadmap deadlines rather than customer deadlines, whereas other big bang releases I've worked on were based around when the customer wanted to release rather than a practical target appropriate for the software in question.
  • We had the ability to negotiate scope from the beginning and remove items from the release that were unachievable, or became unachievable due to emergent priorities
  • We had the time to focus on a continuous integration and testing structure that allowed us to maintain a constant level of quality.

It wasn't that we had the luxury of working slowly - the pace and predictability of the work delivered was impressive. It was the case that we had the maturity of process to know what was possible and predict early what was not. We also had the rigour and stability in our continuous integration and testing processes to know that we were never far away from a releasable product.

Big Bang or Hard Sell?

When working in a commercial capacity it is easy to plump for the big bang approach. In simple terms - it is easier to sell.

As an example I was recently asked to scope/cost a response to an RFP (Request For Proposal) from a company wanting an intranet and engagement programme. On examining the RFP it was clear that the scope had been established more on the basis of a big list of features desired by a number of stakeholders than a clear understanding on what value the program was intended to deliver. The list of technical requirements was huge, yet each sufficiently ambiguous to present a high level of uncertainty and risk in attempting to deliver. Even so the customer was expecting a fixed cost fixed time-scale based response to the delivery.

We took a brave approach to the response and actually offered a fully iterative delivery. We suggested working with the customer to establish their highest priority goals and target initially the delivery of features that supported those incrementally. We fully expected this to be a challenging approach and our expectations proved correct. The customer's response was along the lines of :

"Why would we take that approach when we can work with another supplier who promises to deliver this whole list in a fixed time for a fixed budget?"

I'll admit it is a harder sell. Customers are always going to prefer the illusion of certainty over the honesty of unpredictability. I've included some useful links in the references below on approaches to try to sell an agile approach to project delivery from others facing this same challenge. My strong belief is that, any supplier who did promise such a delivery would need to renegotiate once clearer details of the true requirements became clear.

On a more optimistic note - for some companies that we work with the understanding that agile deliveries can present a lower risk to both parties is starting to take hold. We are encountering more organisations who not only understand but expect an incremental delivery. Given how ubiquitous agile understanding is in development communities if can be hard to believe how alien the concept is in other fields. yet the common perception is still that the setting of arbitrary deadlines for large scope projects will deliver software of equivalent value as delivery through a process of incremental release, review and refinement. Hopefully as stories of the successes of more incremental projects become more readily available this will change, so to help this process along...

Despite the project I've described above being a 'big bang', we still approached the work in an agile way. We delivered completed features through the process and exposed these to the user community for feedback and refinement as we went. Because of this, despite the fact that not all of the scoped features were available on day one, we still released on the target day, with what is proving to be a very popular and well liked application (one of the users this week wrote a poem in celebration of the new system!) and a solid set of core capabilities that have the quality and exten sibility to use in other implementations. So I'll leave you with another of my favourite Kniberg images, to help in deciding whether the project was successful or not.

References

Image: https://image.slidesharecdn.com/what-is-agilehenrikknibergaugust202013-130828212836-phpapp02/95/what-isagile-henrik-kniberg-august-20-2013-19-638.jpg?cb=1377725694 http://blog.crisp.se/wp-content/uploads/2014/03/what-is-success1.png

ShareThis

Recommended