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.

LinkedIn's Windows 8 Moment

(Also posted on LinkedIn: https://www.linkedin.com/pulse/linkedins-windows-8-moment-duncan-k-g-campbell)

If you’re reading this on LinkedIn’s website, then welcome to LinkedIn’s very own Windows 8.

LinkedIn’s new website is slow, it has less functionality than before and the remaining functionality is harder to use.

The LinkedIn app for mobile devices already offered me little in the way of functionality so the bulk of my interaction with LinkedIn was via the web site.  Now those two experiences are barely distinguishable, both being as equally useless as the app was before and remains so.

Why, you might ask, is my ire so raised?  Why the vitriol when praise aplenty has been heaped on the new web site design?  Why indeed.

Searching the web for comments on the new website design leaves me to wonder whether I’m living in some sort of parallel universe as there is nothing but complete praise for LinkedIn’s new look and level of functionality from the professional commentariat.  But take a look at the comments on those articles (where comments are allowed) and there is nothing but rejection of the new design – take Wired’s article for instance https://www.wired.com/2017/01/new-linkedin-looks-just-like-facebook-smart-move/.

(Shades of the media living in their echo chambers and not recognizing the forces leading to M5S, Marine Le Pen, Geert Wilders, Brexit and Trump?)

What in particular do I find so distasteful about the new website design?  What is the oh-so-precious functionality that I miss?

The greatest loss for me is the loss of chronological sorting of items in the “news” feed.  The writing for this has been on the wall for many months since the default order became LinkedIn’s own random sorting of items rather than sorting by date.  Is it so perverse of me to actually want to see things in order?  Is it so unusual for me to want to look through the updates of the people in my network in the order in which they happened?  Why would I only want to see what’s “top” based on some echo-chamber inducing ranking algorithm that changes periodically so if I browse down through that list I suddenly see items from weeks or months ago in amongst things from minutes or hours ago?

Knowing what’s “top” – however that’s determined – is occasionally of mild interest, but give people the choice!

LinkedIn claim that the loss of chronological sorting is only “temporary”, but is that “temporary” like emergency powers, or is it temporary like the dictatorship of Cincinnatus?  I have my own suspicions.

The Jobs section was already sorted according to some unknown ranking, which make it useless for anyone to discover a newly-listed job posting.

It’s slow.

No, I don’t have the figures to back up my assertion, but it is noticeably slower than with the previous design.

For my profile views I now know next to nothing.  The total number of views over the last 3 months is useless.  At least the old graph as well as being able to see one’s ranking for views within one’s network or organization was entertaining.  That even provided a little bit of gamification, but alas no more.

The website and the app are now barely distinguishable.  Yes, it’s great to be able to share code and present a familiar look between web and app versions, but the app is for use with a device that has limitations in its user interface – fingers.  A website is something that is expected to be accessible to people from someone using a screen reader to people using keyboards and mice or fingers.  On a website I expect to be able to open all links in new tabs, now some of the links are magic links that don’t work like that.  Popping up a window when hovering a cursor over a button allows one to glance at something without having to open a whole new page, but now one has to open a whole new page instead.  Did I mention that it’s also slower now?

There are many other areas with diminished levels of functionality with people complaining about the changes to searching within one’s network.  There are also too many other nit-picking details for me to bother with here.

As for features having been moved around, I’ve come to expect that.  I’ve even done it myself in products in order to group functionality in a more logical fashion.  But should Groups really be found under Business?  Seriously?

Sadly, we’re not members, for if we were then we would have a say in this “club”.  Instead we are users: users of a product that is our own data, for that is what one is in any social network even when that social network is for business and career networking and advancement rather than sharing cat videos and writing ungentlemanly abuse at strangers from behind the cloak of anonymity or pseudo anonymity. 

We Built It, They Didn't Come at Agile Tour Bangkok 2016

Yesterday I spoke at Agile Tour Bangkok 2016 presenting a post-mortem of a project I had worked on.  What was unusual about my presentation was that this was not a success story, it was the story of a failed project and an examination of how to prevent such failures in future.

To the casual observer it would have appeared that the project had in place what appeared to be all the trappings of a successful agile development project for at least most of its lifecycle:

• a product owner – who was really a project manager and not a domain expert, but he knew the product vision… and there were Subject Matter Experts to support the Product Owner
• a prioritised backlog – maintained by a product owner… though the product backlog was a bit of a secret for several months early in the lifetime of this project
• daily stand-up scrums
• a scrum board with Post-It notes
• a burn-down chart
• regular sprints – with sprint planning and estimation
• reviews – where the sprint’s results would be demonstrated; and sprint retrospectives where the scrum teams would reflect on what went wrong, what went right and how to do things better
• a scrum master, and
  
• an actual product – under development with Letters of Intent to purchase.

Despite those agile ingredients, the body of this project was riddled with diseases. Some of these diseases were known at the time. Other diseases only became apparent afterwards.

• an organisation inexperienced in software development – inexperienced in identifying good quality people to recruit
• poor quality staff – but they thought they were good; resistant to improvement, and resistance to removing them
• poor attention to quality – must go fast and ignore quality; lack of appreciation for what quality meant
• poor communication within the team – secret chats for requirements, etc; cliques (sub-groups) existed
• mismatched expectations – what the product could do vs what its people thought it could do; how good people were vs how they actually performed
• cancerous growth rate – particularly in the early part of the project there was rapid recruitment; rapid recruitment without establishing how to get good quality staff; rapid recruitment before working out how to manage the numbers; rapid recruitment while still “having to go fast and ignore quality”
• limited customer input – there were Subject Matter Experts, but no real-life customer who was actually using the product and giving in-depth feedback
• unverified customer input – proxy customer input from Subject Matter Experts was unchallenged and there was a divergence of opinions amongst the Subject Matter Experts

Meanwhile, there were no retained customers who would pay for the product.

A handful did pay some money and receive the product. Those customers were only interested in a small sub-set of the features and they were interested in having more features related to only the sub-set they were interested in. Relationships soured, and the customers did not stay for long, partly because of the poor quality of the product and the slower than expected/desired time to develop the requested features/enhancements.

Our highest objective is to satisfy the customer through early and continuous delivery of valuable software. (Manifesto for Agile Software Development)

The project team failed to observe the primary objectiveof commercial software development - not just to write software; not just to provide software to a customer but to provide a solution to a customer's problem.  Few potential customers saw the product vision as a valuable solution to their problems.

The product tried to provide a common solution for different customer segments.  Some features were only potentially valuable to certain potential customer segments, so other potential customers would question who the product was aimed at.  The product tried to solve a problem that either did not exist or was not sufficiently great a problem for people

Most importantly, the project team failed to react to this information - the project persisted in the face of this negative information.

The project failed to learn early and often, so in order to have stood a chance of succeeding it needed to have been learning early and learning often.  If you find that the product does not fit the market, either: find or create a better market, or create a different product.

How to identify if a product solves a problem worth solving?  Create a hypothesis and test it!  This is fundamental practice behind Lean Startup.

Asking people if they think something is a good idea is not enough.  Letters of Intent are worthless.  Software Requirements Specifications did nothing to tell the team if something was a good idea.  The Advisory Board did nothing to tell the team if something provided a solution to a sufficiently valuable problem.

The internal users cropped up in the story of this product, but they appeared late in the story, and then they were neglected – they were a captive market that was not exploited.  Subject Matter Experts provided guidance and conducted demonstrations, but did not use the product as part of their normal day-to-day work.  Input from SMEs and (later) beta testers was not structured/coordinated.

One needed to get detailed input from people actually using the product to find out how they used it and whether it helped them in their work...business analysis methods should have been used: observing users in action, deliberately questioning users on their actions, thoughts and attitudes.  Input from SMEs alone is not enough.

Finally, in the Q&A at the end Kiro Harada pointed out that the project had really died a long time ago.  The project had been kept "alive" by the project's sponsor, so in effect it was really a zombie project.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/we-built-it-they-didnt-come-67963609