"What happens to HR in an agile journey?"

I'm at another Agile Singapore meetup, this time in Titansoft's offices - ah the smell of freshly-decorated office, it's so... cephalagic.  Anyway, I'm in Titansoft's offices listening to Titansoft's HR & Operations manager talk about what happens to HR in an Agile journey and I'm taking notes with a Titansoft 3-colour pen I'd picked up at a conference a couple of years ago.  I'm not, however, wearing a Titansoft T-shirt, nor a T-shirt with Titansoft's name on there as one of the sponsors - basically, I'm not wearing a T-shirt.

This is a talk about a journey, so there are travellers on that journey who encounter obstacles and have to navigate twists and turns along the way.  Not everyone was ready for the journey, people were happy where they were, but then difficulties were found with their situation at the time, and there were voices in the distance indicating a new and different situation that might just be better.  Along the journey some people found particular paths to be hard-going, particularly when they were still carrying so much other baggage that made it harder to navigate those narrower paths.  The main path was quite wide and generally inviting, but it was mostly muddy - sticky and slippery, not the kind of ground you want when you're carrying that historical baggage.  Not everyone followed the same paths, but each group seemed to find what most suited them, or what they were most comfortable with, or rather what became their new comfortable situation.

What stuck out?

Kids today(*) want their work experience to include the following: autonomy, flexible working hours, learning opportunities and challenges, meaningful work, and frequent feedback.  I don't know why that list should be exceptional, they're all the kinds of things that I like to find in an employer, and I'm supposed to be a member of Generation X.

So much like Plato's reporting of Socrates' complaints against the youth of 2400 years ago, the comments about the kids of today would appear to be the same view of every generation.

There was one other desire that the younger workers want from their work experience: early promotion.  Though history is littered with stories of ambitious (and exceptional) young characters who found early promotion, the emphasis is on them being exceptional, which is also why there are stories about those characters in the first place.

This is something I have trouble with because it potentially sets up an unrealistic set of expectations for repeated promotions.  If so, then there are going to have to be many more rungs on the promotion ladders than there are now - you want to move up from Junior Assistant Junior Clerk to Assistant Junior Clerk and then on to Senior Assistant Junior Clerk?

Surely there was more about HR in general?

I was struck by some of the default mindsets that I'd deduced from the presentation.  (It was only an hour's presentation and I did not grill the speaker so I may be wrong in some of my assumptions.)

The focus was on the shift from performance appraisal to no performance appraisal and from fixed hours to flexible hours, which suggested to me that the default mindset of HR was very much one of command and control, that people are resources - hmm, the clue's in the term HR itself... - and not thinking of how one cultivates an environment for knowledge workers to thrive.

The HR manager was only recently introduced to Douglas McGregor's Theory X and Theory Y theories of motivation and management.  I would have expected an HR manager to be fully familiar with the various theories of motivation and management such as Maslow's Hierarchy of Needs, etc

Performance reviews were removed but the experience was that there was reduced feedback, which suggested to me that the managers were not conducting regular (and frequent) one-to-one meetings with their staff - something which I'd been taught in my first line management training course many years ago.

Flexible hours is something that I've come to expect over the years in non-customer facing roles, and that teams are well aware when one or more members are not pulling their weight.

It was also interesting that more developers were included in the recruitment process - after overcoming an HR concern that people were not qualified to conduct interviews.  (Which leaves me wondering what magical skills interviewers have or why one did not think about how people can learn how to conduct interviews.)  However, I understand that the recruitment process then reverted back to the previous framework because the developers had complained that recruitment work was getting in the way of their day-to-day development work.  My immediate reaction to that would have been to ensure that there was alignment in terms of expectations regarding the balance between the effort required for (the very important) recruitment activities and the effort for day-to-day activities.

What else?

Looking at the slide on the workforce demographics I was surprised to see that the age bands stopped at 45.  Hmmm.

What about the food?

This was an after work meetup, so how could I not have some comment on the food?  Well, there was no greasy pizza.  In fact, there was no pizza at all, but there were plenty of doughnuts.  I decided to give the doughnuts a miss.

(*) So-called Millennials, Generation Y, Generation Whine, the (latest) Me Generation, etc

Innovation for Transformation at Agile Vietnam Conference 2017

Yesterday I spoke at Agile Vietnam Conference 2017 giving an updated presentation on TRIZ.  I'd taken the feedback from my previous presentation on TRIZ at Global Scrum Gathering Singapore 2017 and produced something with a bit more focus.  Rather than spending so much time on Genrich Altshuller's story and on the 40 inventive principles I instead focused more on the various tools for inventive thinking.

The end result certainly held together better.  This time I could go into more depth with the tools for inventive thinking and start to apply them to software development scenarios rather than spending half the time introducing the background then spending the rest of the time dancing around the subject and expressing my amazement at the marvellous discoveries.

Then next step is probably to develop some workshops to apply the tools in a group setting.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/innovation-for-transformation-agile-vietnam-conference-2017 

Some other highlights from the conference:

• Guillaume Duquesnay talked about Extreme Estimation - a key take-away was to remember that people are much better at comparing things than putting a number to something, which makes relative estimation faster and more accurate (or less inaccurate)
• Silvana Wasitova talked about High Performing Teams with reference to the McCarthys' 12 Core Protocols - I'm still not sure about the Check In with a statement of one's feelings...
• Kiro Harada gave his continually evolving Kaizen talk and introduced the Manifesto for Lazy Product Development; his mention of Muri (overload), Mura (uneven) and Muda (waste) struck a chord, particularly dealing with Muri before one can then deal with Mura and then Muda.

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.

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