Beyond Brainstorming at Global Scrum Gathering Singapore 2017

Yesterday I spoke at Global Scrum Gathering Singapore 2017 giving a presentation on TRIZ.  TRIZ originated in the USSR, but it is gradually gaining worldwide exposure so it is still relatively unknown.

Brainstorming is the intellectual equivalent of grabbing whatever is to hand, throwing it at a target and seeing what hits and sticks.  Humans have evolved further than our dung-throwing simian cousins, and so too has our understanding of innovation.

Genrich Altshuller's Teoriya Resheniya Izobretatelskikh Zadach (TRIZ), or the theory of inventive problem solving, consists of a catalogue of 40 inventive principles, a matrix for resolving contradictions and numerous mental and practical tools that can be successfully employed by anyone to solve any problem innovatively.

TRIZ emerged from a systematic study of patents, other innovations and how innovative people produce innovative solutions.  Despite the inventive principles and contradictions leaning heavily towards the physical world, TRIZ is applicable to all domains including software, people and not just the invention of new physical products.

In this presentation I aimed to provide the audience with an introduction to a number of TRIZ tools that they would be able to apply immediately to any problem-solving scenario, not just when thinking of product backlog items or resolving impediments experienced by Scrum teams.\

At the end I had some positive feedback on the subject, and some suggestions for how to improve the talk for a future presentation.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/beyond-brainstorming-innovation-for-everyone-global-scrum-gathering-singapore-2017

Scrum: my first introduction

I was first introduced to Scrum when I saw it mentioned in some job adverts in early 2006 when I was rushing to jump ship from the stricken SS Idesta. So I undertook the usual brief look on the web, but I don’t remember being that excited – I was more concerned about blagging that we had been doing iterative and incremental delivery.

When I found my new employer and started as a Senior Developer in April 2006 I was told that we were starting using Scrum in my aviation-focussed web solutions development team.  Our implementation of Scrum consisted of:

• occasional morning meetings to say what we'd done previously and were doing today - these were help around a table in a meeting room rather than standing up in a circle.
  
  From the morning meetings we did discover that everyone working individually, but someone might know about a particular application so you would know they were there for advice.
• keeping a sprint backlog on a spreadsheet indicating how much effort was left for our tasks.
  
  There was some confusion over how to update the backlog spreadsheet, such as how to record remaining effort for a newly-discovered task that was discovered and completed on the same day - which column to should one update with remaining effort, should it be the column for  today or tomorrow?
• tasks were allocated by the Team Leader.
• having a sprint planning meeting where the proxy product owner would explain what was wanted.
• after the sprint planning meeting was over, individual developers would return to their desks to estimate the effort required to complete certain requirements.
  
  Occasionally the Team Leader would ask you to review someone else's estimates - but there was no common understanding of what work was required for development, such as testing, documentation, release preparation, etc.

This process carried on for many months, and I would occasionally deputise for the Team Leader: allocating tasks, chairing sprint planning meetings and ensuring that people estimated tasks.

I later became the Team Leader for the team and introduced some new things:

• Pre-planning meeting between myself (team lead) and product manager (as proxy product owner)
• requirements and tasks on PostIt notes stuck to a whiteboard
• list of up-coming issues on whiteboard

(Though my recollection is a little hazy around this period.)

The whole department then had a presentation from Jens Ostergaard, a Scrum Trainer.  I don't really remember much of the detail, but the key point was to pitch Scrum at various levels within the organisation in order to achieve buy-in from parties at all levels involved in the transformation.

A few weeks later the presentation on Scrum from Jens was followed up with the Scrum Master Training conducted by both Jens and Boris Gloger.  We were mostly Team Leaders, Product Managers and other managers from the various different website teams.

Before the training I had not thought a great deal about Scrum nor thought that great a deal of it.  However, the training was a revelation for me, transforming my thinking regarding Scrum and regarding it as the natural way in which software development - and other kinds of product development - should be done.  (That easy adoption would introduce challenges later on because I had not experienced the mental conversion necessary to help me convince others of the benefits of Scrum - to me it was obvious and required little further explanation.)

The hands-on training really got us all thinking and we returned with a new purpose.

Immediate transformations were:

• more whiteboards, and larger whiteboards than the previous ones
• daily morning Scrum stand-up meeting, every day
• whole team involved in estimating
• proper breakdown of requirements into tasks of no more than 1 day duration
• team-wide understanding of what tasks are required to provide a solution to a requirement
• smallest granularity started at half-day, went down to hour (and minutes) with practice
• all tasks on PostIt notes stuck on white-board
• list of support tasks written on whiteboard

The enthusiasm drove us to be more imaginative and experimented with new ideas

• pre-planning meeting including the whole team
• UAT column on the Scrum board for requirements in UAT
• Ready for Release column on the Scrum board for requirements passed UAT
• Other teams used different-coloured labels to indicate testing status

That was my first introduction to Scrum before I moved on to other organisations.  That was the start of my Scrum and Agile journey.

Agile Success

I'm always interested in project success, so I was drawn to this article in CIO.com: "5 Principles for Reducing IT Project Failure"

Rather than being IT-specific I would say that these are simply 5 principles for reducing project failure:

1. Communicate: If everyone involved in your IT project doesn’t know what they’re working on, when it’s due, how to get it done and who the audience is, how can you possibly expect your project to succeed?

The aim is to ensure that everyone in the project knows what is going on, what is expected, when it's expected, for whom it's expected, etc. Nobody is then treated like a mushroom kept in the dark and fed fertiliser.

2. Consolidate: We’re talking about information and tasks here.

If you can't find the right information for what you're working on, or it takes you a long time to find it, you are wasting time and effort that can be better spent working constructively towards your project goals. Reduce bureaucracy, cut through the red tape and put information within easy reach so everyone can do the job that they are supposed to be doing.

3. Prioritize: Issues come in, bugs are discovered, and new application features are conceived of every day.

Dropping everything to work on a just-reported bug, or to do a "quick job" for someone is probably not the best use of someone's time. The bug may be of lower priority than what you are currently working on. The "quick job" is a distraction where your time can be better spent working on something delivering higher value.

4. Requirements: In ALM and your SDLC, before you can do anything else, you need to identify, prioritize and agree on application (and project) requirements.

It is fundamental that you need to know what the requirements are before you work on something. Once requirements are elicited, they can be analysed and prioritised. Misunderstandings can be removed to ensure that the project team and stakeholders are of one view as to what the requirements are. Understood requirements mean that something can be designed and built. Understood requirements mean that a plan can be made to test them.

5. Manage Time: As management, it’s up to you to take the first step in setting reasonable deadlines and milestones for your team throughout the project.

Knowing where you are in a project, where you should be and how fast you are delivering are vital pieces of information in determining what will be delivered by when.

Alternatively, these are just, 5 Agile/Scrum principles.


1. Communicate

Scrum revolves around a cross-functional, self-organising Scrum Team that has a daily stand-up meeting where every team member communicates what he did the previous day, what he is committing to do today and if he has any blockages or impediments.

Developers, testers, DBAs, designers, BAs are all kept informed of what all the other members of the Scrum Team are doing.

Scrum also involves the whole Scrum Team being involved in the Sprint Planning.

The Scrum Board and Burndown Chart should be visible to all, so everybody can see what the Scrum Team is working on, and what their progress is - instant reporting!

2. Consolidate

Agility is about individuals and interactions being valued more than processes and tools, and about working code being valued more than comprehensive documentation. "Muda", one of the Toyota Principles, is focused on removing waste, where waste means wasted materials but also means wasted time and effort.

Agile practices refer to doing "just enough" or doing what is "sufficient and necessary". Agile teams commonly use wikis to document information, they record requirements on cards or Post It notes which are kept on the Scrum Board (or Kanban Board).

3. Prioritise

Scrum requires the Product Owner to prioritise work. The Scrum Team only works on what is currently the highest priority collection of requirements. Requirements should be prioritised so that the ones delivering the highest business value are delivered first. Also, those requirements which eliminate the most risk should also be prioritised highest.

Considering simply high and low business value and risk, the best order in which to prioritise requirements according to their business value and risk is:

1. High risk, High business value
2. Low risk, High business value
3. Low risk, Low business value
4. High risk, Low business value

The aim is to eliminate as much risk and deliver as much business value as early as possible, overall delivering a high ROI. Risk can also be categorised as uncertainty - the uncertainty that something is feasible.

Bugs, new requirements, existing requirements all go on the backlog and are prioritised accordingly.


4. Requirements

Scrum can not proceed without requirements.

The list of requirements is maintained in a Product Backlog, in priority order (c.f. Prioritise)


5. Manage Time

Scrum sets regular deadlines for the Scrum Team to commit itself to delivering working software satisfying the requirements.

Progress is visible on the Scrum Board - which presents a snapshot of progress in terms of what's Done, what the team are Doing and what's still To Do. Progress is also visible in the Burndown Chart which shows the rate of progress.

Requirements and tasks are estimated by the people who will do the work - acknowledged to be more accurate than estimates by people who do not do the work - and that knowledge is used to set realistic expectations.

Daily reporting in the Daily Scrum means that people are held accountable to the whole Scrum Team for the commitments they make each day.


So, 5 principles for reducing IT project failure are satisfied by Agile practices. Though I often remark that what are often regarded as Agile practices (coding standards, continuous integration, etc.) are just good engineering practices. So, Alistair Cockburn is right that Agile is the norm - it's just good practice.

Experience Counts for Less?

The Wall Street Journal article "Dangers of Clinging to Solutions of the Past" illustrates the value of challenging assumptions and the inspect-and-adapt cycle. Whilst the article boldly asserts that increased experience leads to increased project failures, this is attributed to an increased confidence on behalf of the project managers concerned.

I would like to add that it is of little use to know that a practice worked previously without knowing why it actually worked, and conversely one should also know why something did not work in a particular situation. By knowing the "why" one is able to apply the experience to the appropriate situation.

We can only discover the reasons by taking the time to ask ourselves what those reasons are. Scrum's retrospective meeting (a post-iteration review) generally poses 3 questions:

• What went well?
• What went wrong?
• What to do better, and how?

I would now say that the 3 questions should be posed as:

• What went well, and why?
• What went wrong, and why?
• What to do better, and how?

Lack of Ownership

To break the old way of thinking I kept hammering home the message with my team that:
"You do not own the product/requirements"

Unfortunately, this became interpreted as:
"You have no responsibility or stake"

By breaking down the old way of thinking, I had not replaced it with something else.

The team felt that they were just randomly picking tasks from the scrum board each morning.

(A clue should have been the fact that it was taking so long at each daily scrum for people to choose their tasks. This showed that people were un-prepared for deciding what they would do that day.)

How to Tell a Horse to Drink?

I had a very revealing and productive 1:1 meeting with one of my development team this afternoon. I'd set aside an hour at the end of the day instead of the usual half-hour slot for our monthly 1:1 meetings; instead, the meeting lasted two hours.

Ever since I arrived in my current position I told the team, in true Scrum fashion, that they were self-organising, with the mantra "let the team decide".

Unfortunately, the team had not really grasped what the true implications were.

This was a lack of communication on my part, and not devoting sufficient attention to coaching the team in how to think in agile ways and seeing how they interact.

There had been several misunderstandings over the concept of "ownership". Telling the team that they did not "own" the products left them feeling that they had little or no stake in them. In order to clarify things I had to say that the team does not own: the requirement for a feature, the prioritisation of a feature or the business value of a feature. However, the team does own: the responsibility for committing to, and delivering on, the solution to a requirement; the technical architecture of the solution to a requirement; and, the processes for delivering solutions to requirements.

My previous experience had been that the team would spontaneously self-organise in order to drive requirements to completion. In an Asian context, developers are not accustomed to being allowed to think for themselves: designs are handed-out, tasks are assigned, people do what they are told.

The team did not realise, despite them being told that they are self-organising, that they can have individuals in the team who drive forward the delivery of the solutions to requirements. Now I ensure that the "driver" for each requirement is identified at the end of a Sprint Planning Meeting - how a driver is identified is not prescribed: people can volunteer, I can make a suggestion, I can say that someone should be the driver. The difference is that with a named driver the team feels a greater sense of ownership of the delivery of the solution to a requirement. Maybe one day they will be a little more pro-active in terms of the self-organisation...

The principle of whole-team involvement was also taken too literally, and did not respect the capabilities of individuals. Each team member has his own strengths, weaknesses and aspirations. Whilst some are good at one thing, others are not so good at it - the team should be able to recognise that and act accordingly. The response can be to use the strengths of the individuals directly by them doing things themselves, or indirectly by them guiding or assisting someone else who wants to develop their strengths in that area. How the team had reacted was to assume that everybody was equal (which in some cases they are, such as when voting during estimation in Sprint Planning meetings, and being able to contribute to discussions) and that everybody was expected to do equal work. The emphasis on the removal of single-points-of-failure may have contributed to this attitude, though the drive to remove single-points-of-failure is still on-going.

In terms of agile design and delivery, despite repeated instructions to break large requirements down into iterations and to concentrate on designing the minimum amount in the beginning, and only designing in any kind of detail for immediate (highest priority) requirements, we still ended up tending towards a waterfall design approach.

More involvement in the design process to coach the team to think in iterative and agile ways seems to be putting them back on track - though there are still times when the team risks falling into paralysis by analysis rather than seeking clarification from outside the team.

After careful and persistent questioning, I also managed to get my developer to provide some feedback on me in the 1:1 meeting. So far, I've been inviting my team members to tell me their concerns and problems in our 1:1 meetings so that issues can then be resolved. The 1:1 meetings aim to be a two-way conversation where either party is free to say what they want. Instead, everybody has just been saying that everything is fine and that they are happy how things are going.

However, I'd learned that the team had expressed some misgivings about things to higher management.

So, with a little more humility than usual, a lot of in-depth questioning to get him to open-up more to me, and some straightforward asking of what he thought about me I managed to get some much more honest feedback.

To my surprise I learned that my team can consider me to be intimidating.

My sarcasm does not always travel well, and can be misinterpreted. I also do not like arguing for argument's sake, but will play the Devil's Advocate in order to help people probe their own arguments further, or I will argue my point if I hold by own contrary opinion - this can be interpreted as being aggressive. A constant stream of criticism, though well-intended as my continual drive to improve quality, can also be demoralising.

However, I am conscious that I had been praising good work.

My developer has now gone away with the message that honest feedback is welcomed, and that if anything is affecting communication then that is an impediment to the team achieving its goals of delivering well-designed, high-quality software in a timely fashion, and as an impediment it must be resolved.

Long Meetings

On Friday we spent a long time in our Sprint Retrospective meeting discussing the problem of spending far too much time in meetings. The irony was not lost on us.

The outcome was that we should not spend so long in meetings, keeping the meetings short and focussed. This means more investigation and analysis beforehand so that the team members are prepared for the meetings with sufficient information.